User talk:Jorm (WMF)
Contents |
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
- 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)
[edit] 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:
- Pick an image to add
- Change the search words and look again
- 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)