User talk:Jorm (WMF)

WikiLove

Hi, maybe this comes a little bit late, but recently I explained another user (in German) why her picture of a plate full of strawberries had about 45 hits lately. So I would suggest next time on other occasions or maybe now although it is a bit late tell the photographers that their pictures are appreciated and used for this kind of tool. Thank you. :) Regards Catfisheye 16:50, 11 August 2011 (UTC)

Local uploads

Jorm, you seem to be uploading a lot of files locally that are already on the Commons. I'm wondering what the reasoning for this is, as, as they stand, they would be speedy deletion candidates under Meta's Speedy deletion policy. Courcelles 17:42, 16 August 2011 (UTC)

They are nominated for deletion on commons. Since the design was/is originally held on mediawiki.org, I moved them there. However, meta has links to the files as well, which will disappear once commons finishes talking and deletes them.

Since they are used in the Image Filter Referendum, they are kind of important, and since you can't transclude images from mediawiki.org to here, they have to be uploaded locally.--Jorm (WMF) 17:48, 16 August 2011 (UTC)

Aaah, makes sense. We need enwp's {{go away}} here so no one thinks to zap them here... --Courcelles 17:52, 16 August 2011 (UTC)

Just a friendly OTRS notice…

… that a vigilant reader has spotted a typo on your page here:

'In the "Where your donation goes" sidebar image. In the "People" bullet, it says "invesment" rather than "invesTment".'

Asav 01:17, 10 September 2011 (UTC)

Image filter proposal

Hi Brandon, a question has been asked about potential performance implications of the image filter proposal here. Could you give it a look over and comment? --JN466 14:44, 22 November 2011 (UTC)

Developers' veto

I was wondering if you had any more information on the "developers' veto" that seemed to have been exercised on bug 30208, such as how common this practice is. I've recently returned to editing after an absence due to real-life issues, and was very disappointed to see how this was handled. It wouldn't seem to me correct for developers to veto community decisions on philosophical grounds (vetoing or expressing concern on technical grounds would be a different story, but I saw no technical concerns in the bug ticket). Rather, if the devs disagree, it would seem to me they should participate in the discussion and oppose it, but accept consensus if still against them, just like we all must do. Just because I have the technical ability as an admin to "veto" community consensus on what should or should not be deleted, doesn't mean it's actually acceptable for me to do that. Similarly, I don't think that just because the devs have technical control of the systems, that they should use that as a chokepoint to veto actions they just happen not to agree with when those actions would require developer assistance.

It also seemed to me that the WMF staff in that ticket were saying "Ehh, you just haven't thought this through, and besides we have data...", while putting forth some data that was tangentially relevant at best. A trial with a hard end date (which was all that was proposed) would've enabled the gathering of real data. If it turned out not to significantly improve editor retention, fine, the trial is a failure and we'd never have approved doing it permanently. If it worked, we have a working solution, all the better. Only one way to get those metrics. The possible consequences were thoroughly discussed and carefully thought through, and part of the consensus was that this would improve the new-editor experience.

Not figuring any of this will change your mind, of course, nor that at this point the decision stands any real chance of being reversed. But I still think it was handled badly, that we threw away an opportunity to gain data on a solution we can implement quickly, and that many of the people who participated in that discussion quite rightly feel alienated and angry. And I don't think it's made any better by resources being put toward a solution we didn't ask for. By all means, developing a better interface is an excellent idea, especially for new users. But that should happen concurrently with, not instead of, the change the community agreed on. Seraphimblade 20:32, 28 December 2011 (UTC)

Howdy!

There exists a page here on meta (Limits to configuration changes) that has a pretty good history that shows how often something like a "developer veto" has been enacted. There are two instances of "outright rejection" that override community consensus: the ACTRIAL instance you mention and one that requested the deletion of unused user names. There are two other "partial" rejections (changing the values of "autoconfirmed" status and denying anonymous edits on the Indonesian Wikipedia). There may be more instances than this but those are the ones documented.

I am not in a position to speak deeply about the politics of this situation. I think we can all agree that there were communication problems and I wish that there hadn't been.

If you'd like to join the discussion about possible future iterations of article creation workflows and projects, we'd love to hear you thoughts. Our working page is set up on MediaWiki.org at Article creation workflow.--Jorm (WMF) 00:13, 29 December 2011 (UTC)

Thanks for letting me know of that page, I'd no idea it existed. I guess it's good to see that at least this happens relatively rarely. Though, since you did seem to have an appreciation for blunt speech, I'll be blunt: I don't think the problem on the bug ticket was bad communication, I think the problem was a bad decision that wouldn't have been helped by even the best communication.

That being said, I saw the abuse you were getting on the edit to this page right before I posted here. Given that I'm also a developer with long hair (and occasionally get some hell for it, as well as people thinking development is "not a real job", let them try staying up most of the night for a week or two straight after a release and tell me that), I do have great respect for what the Mediawiki devs have accomplished, and I hope nothing I've said has come across as belittling that. I also quite liked what you had to say in your appeal—I've been there, although my work now is for a startup that provides a business-to-business webapp and really does offer significant value to the clients, so at least I don't have that nagging feeling that I'm deceiving someone. I've had to write code that I personally thought was a bad idea. Sometimes I was wrong. Often, I was right, and I find the more often that happens and I'm told to "do it anyway", I get listened to more closely the next time around. Seraphimblade 04:48, 29 December 2011 (UTC)

Spelling, grammar, orthography!

"Please note: in fewer than..." Fifelfoo 01:34, 17 January 2012 (UTC)

Heh. I'm not writing the banner, but I'm told to send you here.--Jorm (WMF) 01:39, 17 January 2012 (UTC)

En.wikipedia is currently locked. Please don't do non-urgent edits on it.

Dear Jorm. As you may know, The English Wikipedia is currently locked up for 24 hours as a protest against SOPA and PIPA, so ordinary (non-steward) users cannot do any edits. It seems you have done an edit on w:LSU Tigers football‎ during this time. Even if the software allows you because you are a steward, please refrain from doing "normal" editing work on en.wikipedia during the blockout. Thanks, – b_jonas 14:02, 18 January 2012 (UTC)

As I'm generating a table of inappropriate steward edits during the blackout and will be noting it to en.'s administrators' noticeboard (as a completed oversighting action of steward edits) you may like to note here any explanation for the edit. A number of other steward users have noted that their edits were made by honest mistake, etc. etc. which closed the matters to my mind as we all make mistakes. Fifelfoo 00:36, 19 January 2012 (UTC)

It was a vandalism that was snuck in just beneath the wire. I reverted it because I was asked to. Feel free to revert my reversion as needed.--Jorm (WMF) 01:51, 19 January 2012 (UTC)

Many thanks for explaining. Happy editing once the blackout lifts! Fifelfoo 01:56, 19 January 2012 (UTC)

routes in for new editors

Hi Brandon, In an IRC office hour a week or so back you expressed an interest in easier routes in for new editors. I'd like to bounce an idea by you.

I'm assuming that we are looking for an edit that doesn't need to be referenced, has an immediate effect of improving an article, is highly unlikely to be reverted, many tens of thousands of these edits are needed, and they can be made by anyone who has mastered a mouse.

I think that [en.wikipedia.org/w/index.php?title=Milstead&diff=prev&oldid=494350113 this sort of thing] is the answer. Currently the difficulty is that adding an image to a Wikipedia article requires mastering the art of curly brackets, pipe symbols, navigating between Commons and Wikipedia and knowing how to find articles which don't have photographs but for which we probably have a plethora of potential images on Commons. But all of that should be possible to code.

I'd like to see a GUI or app that prompted people with images that don't have a picture, and suggested possible images from commons. Giving people the options:

1. Pick an image to add
2. Change the search words and look again
3. Skip this article and try another

When they pick an image it would do the fiddly stuff of inserting it into templates, and default to top right and thumb sized. All the editor should decide is the caption and how you would describe this image to a blind person. Do you think this could be coded? I think we got part way there by having something on the toolserver that predicts articles that need an image, but it isn't newbie friendly. WereSpielChequers (talk) 22:51, 25 May 2012 (UTC)

Congrats!

Nice watch! Drmies (talk) 14:46, 12 July 2012 (UTC)

Article Creation Flow and Athena

Am I right in thinking that perhaps the delay in developing Article Creation Flow is somewhat connected with the proposals for an entirely new interface design? If so, I can understand, but it would be great if development of ACF - at least its basic architecture without the final skin - could take place concurrently in order to save time. As you know, I personally consider user retention to be a high priority, and of course it goes hand-in-hand with the excellent NewPagesFeed. --Kudpung (talk) 03:37, 25 July 2012 (UTC)

No, they aren't really connected at all. The article creation workflow technology is mostly implemented; it's the actual workflow itself that needs work. Delays on it (at this point) come from the fact that the only designer who knows anything about how articles get created (the community-blessed processes and the like) is me, and we're unable to ramp another one up onto it. My time is (and has been) split among several projects, and I've been having to do additional "fill" work due to unplanned events.

The Athena/Agora work actually comes from a different time "budget" and has actually been in the works for some time.--Jorm (WMF) (talk) 05:12, 25 July 2012 (UTC)

Many thanks for the update Brandon, I realise you are busy. Shame we didn't get time to have a chat in the US last week. --Kudpung (talk) 08:49, 25 July 2012 (UTC)

Changes to the www portals

Hi. There are two notes on the editing screen of every www portal explaining that you should update the /temp subpage and synchronize instead of directly editing live pages. You seem to have ignored this and I'm not sure why.

Regarding the changes themselves, can you explain why a read-only portal would need links to a terms of use and a privacy policy? I'm inclined to revert all of your edits as being out-of-process, unnecessary, and aesthetically displeasing. --MZMcBride (talk) 00:52, 23 March 2013 (UTC)

The privacy policy notice is legally required by the state of California. Legal requested Brandon make the edits so that we could come into compliance. --LVilla (WMF) (talk) 01:01, 23 March 2013 (UTC)

Sorry, can you be more specific? Legally required how? There are plenty of pages being served out of the various Wikimedia domains with no mention of the terms of use or privacy policy. --MZMcBride (talk) 01:03, 23 March 2013 (UTC)

The presence of the privacy policy is required by the attorney general's interpretation of Online Privacy Protection Act. If you see pages on English WM project domains that don't have a link to the privacy policy, please feel free to drop us a note. (Terms of use are not actually required, but they are good form.) --LVilla (WMF) (talk) 01:17, 23 March 2013 (UTC)

Thanks for the link. Online Privacy Protection Act seems to mention commercial sites twice. Are Wikimedia sites considered commercial for the purposes of this act? And the act seems to apply to sites that collect personally identifiable information (which the article lists as Social Security numbers, names, addresses, etc.), none of which is relevant to Wikimedia wikis. I'm still sure how I see the applicability.

https://en.wikipedia.org/w/api.php would probably be the most prominent example of a read and write entry point with no mention of any terms of use or privacy policy. --MZMcBride (talk) 01:24, 23 March 2013 (UTC)

I created Advertisement of the privacy policy. It may end up linked from privacy policy and privacy policy. In my mind, the only thing worse than the approach being taken here (no notification or note anywhere, not following process, etc.) would be also not having an explicit policy and instead relying on some pseudo-policy. So I'm working to fix that with the new page. If I've overlooked some notification or announcement somewhere, please let me know. I checked the blog and wikimedia-l and some other places. --MZMcBride (talk) 03:52, 23 March 2013 (UTC)

CSS details

You may find this useful - a while back, someone pointed me to the Classic stylesheet. I copied it into my common.css; it didn't work right, but it has information which you may find useful.

http://en.wikipedia.org/w/index.php?title=User:DragonflySixtyseven/common.css&action=history

Thanks. DS (talk) 16:36, 14 April 2013 (UTC)

Flow portals

Just a quick note, and this is something that trips up nearly every editor at some point (myself included, of course): when copying page content that anyone besides you to contributed to, you have to provide a chain of attribution. An edit summary is sufficient. For example, this edit appears to contain content that came from others (if not, apologies, but I'm fairly sure...). If so, you'll just want to use an edit summary like "content derived from w:en:Wikipedia:Flow" or "content derived from https://en.wikipedia.org/w/index.php?title=Wikipedia:Flow&oldid=555448189" or "content derived from w:en:Special:Permalink/555448189" when setting up a Flow portal (I assume there will be more in the future). Without the pointer, it makes it really difficult (sometimes impossible) to trace contributions to a work.

I wonder if we have a good page here describing this... if not, maybe I can work on that. --MZMcBride (talk) 19:16, 18 May 2013 (UTC)

Page Curation

Hi Brandon. Problems are creeping in with the Page Curation software which are making it apparently largely unusable for some eitors. Bugs have been reported but there is little or no action at Buzilla. Perhaps you could cast an eye at en:Wikipedia talk:Page Curation and see if anything can be done. Regards, Kudpung (talk) 02:12, 28 August 2013 (UTC)