Re: [Wikimedia-l] how global.js works? (was: Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you)
Hoi, The big question is not so much where and when things happen, the big question is who supports all the muck. There have been enough instances where changes to for instance common.js brought down servers. This is not a zero sum game. It is not as if there are no consequences. I am certain that the community will not be happy when Wikipedia goes black for them or because of them. So when the totality goes down, who to blame and who is to fix it .. the community?? Will it blame itself or will it shrug it off like always? Or will it blame the WMF because it feels entitled?? Thanks, GerardM On 14 August 2014 00:54, svetlana svetl...@fastmail.com.au wrote: On Thu, 14 Aug 2014, at 07:32, Erik Moeller wrote: On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth petefors...@gmail.com wrote: In favor of the Media Viewer software is a bunch of inquiry and analysis Restoring the default state of the software to the state that worked for the last decade is a clear precondition for healthier discussion of a positive path forward. Dear Pete, [...] If we're being honest, at the end of the day, a lot of this is about establishing clear governing principles for the MediaWiki: namespace. This is indeed true. Why does a global.js or whatever edit override user preference in the first place? I would expect user preferences to run after global.js, and set the onClick event back to what it should be (such as, something meaningful where a user has MV enabled). svetlana ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] how global.js works? (was: Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you)
On Thu, Aug 14, 2014 at 1:41 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, The big question is not so much where and when things happen, the big question is who supports all the muck. There have been enough instances where changes to for instance common.js brought down servers. Out of interest, when was the last time that a common.js change brought down the servers? -- John Vandenberg ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
Erik On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller e...@wikimedia.org wrote: This is why on all major sites, you see a gradual ramp-up of a new feature, and continued improvement once it's widely used. Often there's an opt-in and then an opt-out to ease users into the change. But once a change is launched, it very rarely gets rolled back unless it's just clearly not doing what it's supposed to. Are you are familiar with the Flickr experience in the last 12 months by any chance? I think that is a very pertinent and prominent example of what goes against what you say. The Flickr attitude was much the same as the WMF's. That ended up in a revolt, much like the WMF is seeing against it. In the end, they ended up doing what Erik? Also, the other day I received a Flickr email from someone wishing to use an image which I had not taken, but which I had uploaded to Commons. They mentioned that they saw the photo on Commons. When I told them that I am not the author, and that they would need to contact Joe Bloggs, their response: I'm sorry, this is SO confusing to me. I put that down to MediaViewer and its adding irrelevant information, and also the fact that file information is more difficult to find. Russavia ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] how global.js works? (was: Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you)
Ah, I believe when the Italian (?) Wikipedia started using my JS-based also-search-on-wikidata tool. A dependency JS file was hosted on Tools Labs, effectively DDOSing it to a halt. Moved file to en.wp, cache can handle it easily now. So, not technically a Wikipedia server, but a Wikimedia server with lots'o'tools got unresponsive for a while. Last one I can think of. Cheers, Magnus On Thu, Aug 14, 2014 at 7:55 AM, John Mark Vandenberg jay...@gmail.com wrote: On Thu, Aug 14, 2014 at 1:41 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, The big question is not so much where and when things happen, the big question is who supports all the muck. There have been enough instances where changes to for instance common.js brought down servers. Out of interest, when was the last time that a common.js change brought down the servers? -- John Vandenberg ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
FYI, Lila had chosen to engage in discussion on her meta talk page. Numerous editors are commenting there. Discussion also continues on the meta RFC and on the English Wikipedia arbitration workshop page. Pine On Aug 14, 2014 12:03 AM, Russavia russavia.wikipe...@gmail.com wrote: Erik On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller e...@wikimedia.org wrote: This is why on all major sites, you see a gradual ramp-up of a new feature, and continued improvement once it's widely used. Often there's an opt-in and then an opt-out to ease users into the change. But once a change is launched, it very rarely gets rolled back unless it's just clearly not doing what it's supposed to. Are you are familiar with the Flickr experience in the last 12 months by any chance? I think that is a very pertinent and prominent example of what goes against what you say. The Flickr attitude was much the same as the WMF's. That ended up in a revolt, much like the WMF is seeing against it. In the end, they ended up doing what Erik? Also, the other day I received a Flickr email from someone wishing to use an image which I had not taken, but which I had uploaded to Commons. They mentioned that they saw the photo on Commons. When I told them that I am not the author, and that they would need to contact Joe Bloggs, their response: I'm sorry, this is SO confusing to me. I put that down to MediaViewer and its adding irrelevant information, and also the fact that file information is more difficult to find. Russavia ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Clarification by Lila Tretikov about MediaViewer
The community too is asking for kindness and consideration. Riding roughshod over community consensus does not equate to kindness, or even wisdom, unless it it that of Niccolò Machiavelli! The Mission Statement of the Foundation says *The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license https://en.wikipedia.org/wiki/en:free_content or in the public domain, and to disseminate it effectively and globally.* If the WMF would remember the word empower we would not get these issues. The Foundation needs to empower the community to disseminate content not dictate to the community how content will be disseminated. All the best, Rich Farmbrough. On 13 August 2014 13:01, Thehelpfulone thehelpfulonew...@gmail.com wrote: Forwarding on request. -- Thehelpfulone https://meta.wikimedia.org/wiki/User:Thehelpfulone Begin forwarded message: From: Ad Huikeshoven a...@wikimedia.nl Date: 13 August 2014 12:40:14 BST To: wikimedia-l-ow...@lists.wikimedia.org Subject: Clarification by Lila Tretikov about MediaViewer Dear fellow Wikipedians and Wikimedians, Your work in creating the awesome thing Wikipedia is very much appreciated and you're all recognized for contributing towards it's success. Last weekend I have been to Wikimania. I really enjoyed the presentation by Fabrice Florin about A Culture of Kindness [1]. One of the slide contains a picture of Jimmy Wales holding a sheet of paper on which he has written 'be kind to everyone, including the annoying ones'. There have been multiple threads on this list with many postings about actions on the German Wikipedia with respect to MediaViewer. On meta Lila Tretikov has posted several remarks including an additional clarification [2], which I copy below: quote * Our overall communication, design, prioritization, testing, roll-out mechanisms and general product development practices are insufficient and must be brought on-par with our user’s expectations. We are not planning any new major deployments until some of those basic improvements are put into place. This will be done in the open; it is fundamental and urgent. I've touched on it at Wikimania. * We are not removing MV. It has been in production for months. Its removal will cause more problems and confusion for our users. We will hold ourselves accountable to getting it to the level of quality that is expected of the top site. * We are working to post next steps to clarify development and deployment process including rights and responsibilities; you can expect more information in coming days. * I encourage you to help us improve our process as a whole as well as this specific feature by offering your time, advice, and collaboration. We will be engaging you on it. Please refrain from making unassisted changes to the feature’s configuration. /quote What Fabrice and Jimmy ask for is to be kind. What I would like to express is that many of the postings about MediaViewer do annoy me, and some are very annoying. What I do ask of my fellow Wikipedians is to continue to contribute to Wikipedia in a kind way, to pay attention to what Lila has posted on meta and which I copied above. Some of you might be curious to learn to know the ideas of Lila. She made a presentation at Wikimania, which can be viewed on line [3]. Please collaborate in the development of processes in a kind way. Thank you. --- [1] https://wikimania2014.wikimedia.org/wiki/Submissions/A_Culture_of_Kindness [2] https://meta.wikimedia.org/w/index.php?title=User_talk%3ALilaTretikovdiff=9501584oldid=9501543 [3] http://new.livestream.com/wikimania/saturday2014 -- Ad Huikeshoven Bestuurslid / Board member Wikimedia Nederland Internationaal / International Affairs Educatieprogramma / Education Program tel.(+31) (0)70 3608510 mob. (+31) (0)6 40293574 Steun vrije kennis! Kijk op wikimedia.nl Postadres: Bezoekadres: Postbus 167Mariaplaats 3 3500 AD Utrecht Utrecht ABNAMRO NL33 ABNA 0497164833 - Kamer van Koophandel 17189036 ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe -- Landline (UK) 01780 757 250 Mobile (UK) 0798 1995 792 ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
Re: [Wikimedia-l] A bunch of nobodies
Hoi, Because you can.. Thanks, GerardM Op 13 aug. 2014 23:41 schreef Michael Peel em...@mikepeel.net: Why? On 13 Aug 2014, at 22:40, David Gerard dger...@gmail.com wrote: Add evidence of your insignificance here! https://meta.wikimedia.org/wiki/A_bunch_of_nobodies - d. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] A bunch of nobodies
Let's not encourage using meta like it was Facebook. However, meh, looking at the important names listing themselves, I can't get very excited about pursuing the point. I'd rather not get even more black listed than I already am. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] A bunch of nobodies
Hoi Fae, For me you added a positive notch at Wikimania to your reputation. It was good to see you and you were involved and having fun.. Thanks, GerardM On 14 August 2014 11:07, Fæ fae...@gmail.com wrote: Let's not encourage using meta like it was Facebook. However, meh, looking at the important names listing themselves, I can't get very excited about pursuing the point. I'd rather not get even more black listed than I already am. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride z...@mzmcbride.com wrote: Is there anything that the German Wikipedia could do to convince you to disable MediaViewer there? Some percentage of active users showing up to say so? Some percentage of users (logged-in or otherwise) disabling the feature? (Presumably we can get stats of some kind.) We are very open to continuing the discussion about how the feature should be configured, how it should be improved, and how it should be integrated in the site experience. Ideally we'd like to minimize inconsistencies between wikis (because for readers who speak more than one language, it's just a single site), so changes that help alleviate conflict or disagreement should ideally also be of the kind that in general are welcomed and wanted. On the subject of opt-out numbers, you can see them here: http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-graphs-tab As you can see, the recent drama has contributed to a significant increase in opt-out events. Pre-vote, about 17% of very active (100 edit/month) users had disabled MMV. This is about the same number of people who ultimately voted no, BTW, about 200. Post-vote it was 20%. Since then it has climbed to 23%. In contrast, about 30% of that same user group still use Monobook. I think those numbers can and should reasonably inform the default for logged in users, for sure. I don't think they should be used to determine the default for readers. In general, though, let's talk. The overarching principle we're not going to budge on is that this process is really not acceptable: 1) The UI changes 2) A subset of users is upset and organizes a poll/vote 3) The poll/vote closes with a request to undo said UI Change and a request is filed 4) WMF offers compromise or says no 5) A local hack is used to undo said UI change That's no way to develop software, and that's no way to work together. If you want a WMF that slavishly implements RFCs or votes to disable features upon request, you'll need to petition to replace more than just one person. In fact, you should petition to reduce the staff dramatically, find an administrative ED who has no opinion on what to do, and exclusively focus on platform-level improvements and requests that clearly have community backing. This is not the org we want to be. I am hopeful and optimistic that there are enough admins and regular editors who believe in a vision of improving the user experience iteratively, and working together through conflict, that we can in future entirely rely on local admins to prevent the kind of JS hacks we've seen here, working towards a proper code review and deployment mechanism that further alleviates the risk of escalations. Mind you, we made it very clear in this case ahead of time that JS hacks were unacceptable, we attempted a revert and a very explicit warning. None of us love drama. We've been punting on this issue for a long time, living with ambiguity that we knew was going to bite us sooner or later. When DaB. removed the link to Beta Features on de.wp in November, calling it clutter, we ignored it and hoped that another sensible admin would step in and restore it, because we didn't want to trigger precisely this kind of conflict over minutiae. (It was only restored a couple of days ago.) In other cases we've made simple reverts to MediaWiki: edits and hoped they would stick. Can you imagine how frustrating this is for developers and UX designers who are paid using donor funds to improve the user experience? We need rules of engagement for these types of changes, and they need to acknowlege that WMF is a partner in them. The problem with the sequence above is that there's no venue for negotiating compromises, evaluating options, and establishing final agreements about what should happen. That puts WMF in a position where we get to say yes, WONTFIX or here's a random compromise, hope you like it. We need better ways to discuss and negotiate when we disagree. Please give us some time to outline some compromise options consistent with the above. However, please don't expect us to endorse the idea of If WMF doesn't do what we want, we'll just enforce it by means of a local hack. That is simply not workable, and no Wikimedia Foundation that at all resembles the one we have today will accept it. -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you
On 12.08.2014 21:41, Magnus Manske wrote: On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann h.schlottm...@gmx.net wrote: This is serious. WMF really needs to appreciate the expertise of the author community and accept their experience a important and valid. If authors tell the WMF and particularly the devs, that a particular function is necessary, then the devs really, really need to think. I do agree with this. Visual Editor (which works much better these days) and MediaViewer are not aimed at the experienced editor. They aim to make the reader more comfortable, and try to ease the first steps into editing. Winning new editors has been deemed a priority, somewhat at the expense of WMF-made support for the power user. This is a judgement call the Foundation has to make. I do not undersign that dichotomy between readers and authors. And I certainly do not accept any claim, that the MWF know all about what readers need to become authors, while the authors are ignorant about that. The results of the millions of dollars, the WMF put into their understanding of readers interest are less than sterling in this regard. A formal RfD must not be taken lightly, overruling it by creating a whole new user class, and crippling the elected admins is inpermissible. WMF has broken trust again and this time in a unprecedented way. As Erik pointed out, WMF had made it quite clear that they reserve the right to overrule the community in that specific matter, before the Meinungsbild was done. WMF then acted as announced, and refused to be hacked out of their own servers. An unfortunate escalation on both sides, but since they never promised to accept the Meinungsbild (quite the opposite!), it was not a breach of trust. Frankly: I don't care the least, what Eric says. Of course the Meinungsbild (RfD) at deWP was a vote of noconfidence after the previous events at enWP. But the reaction by WMF was unprecedented and it was a mistake. A serious one. It damaged the relation between the Community and the WMF, it killed Jan's job and it made Rachel's job very difficult if not untenable. To describe Eric's action I am tempted to use a metaphor that includes black uniforms and heavy boots. But that would not be appropriately written by a German to a German. Until this event, I thought the dev process to be broken, not just the communication around devs. But now I believe the conflict runs deeper. It points out an issue we (community and WMF) should discuss, in a more general sense. What should the decision process be for technical changes? When does the Foundation get precendence, and when should the community have the last word? What weight should small-scale votes of editors have? Should random polls be done, and included in such votes? Etc. The MediaViewer affair itself gets blown out of proportion IMO. I agree that this is not just about the MediaViewer but about a general pattern of behavior perceived by the community. The WMF's decision making regarding software and skin development is broken. Its targets are flawed, it is not properly communicated with the community, the actual development processes result in incredibly crappy software that gets rolled out non the less in pre-alpha states. Do I have to list all the broken projects? Liquid feedback, article feedback tool, image filter, visual editor, flow, the new thumb layout. How do you explain that to donors by the way? All of them show that the devs and the management level do not understand the features of the existing solutions, particularly the well established tools and sometimes work arounds, authors created over the years to deal with the very basic MediaWiki. But understanding the actual use of MediaWiki is paramount to improving it. Ciao Henning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you
Henning, To describe Eric's action I am tempted to use a metaphor that includes black uniforms and heavy boots. But that would not be appropriately written by a German to a German. You may find yourself very smart with this kind of wording. Let me tell you from a North German to a North German: Dat bisse nich. Ziko 2014-08-14 12:13 GMT+02:00 Henning Schlottmann h.schlottm...@gmx.net: On 12.08.2014 21:41, Magnus Manske wrote: On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann h.schlottm...@gmx.net wrote: This is serious. WMF really needs to appreciate the expertise of the author community and accept their experience a important and valid. If authors tell the WMF and particularly the devs, that a particular function is necessary, then the devs really, really need to think. I do agree with this. Visual Editor (which works much better these days) and MediaViewer are not aimed at the experienced editor. They aim to make the reader more comfortable, and try to ease the first steps into editing. Winning new editors has been deemed a priority, somewhat at the expense of WMF-made support for the power user. This is a judgement call the Foundation has to make. I do not undersign that dichotomy between readers and authors. And I certainly do not accept any claim, that the MWF know all about what readers need to become authors, while the authors are ignorant about that. The results of the millions of dollars, the WMF put into their understanding of readers interest are less than sterling in this regard. A formal RfD must not be taken lightly, overruling it by creating a whole new user class, and crippling the elected admins is inpermissible. WMF has broken trust again and this time in a unprecedented way. As Erik pointed out, WMF had made it quite clear that they reserve the right to overrule the community in that specific matter, before the Meinungsbild was done. WMF then acted as announced, and refused to be hacked out of their own servers. An unfortunate escalation on both sides, but since they never promised to accept the Meinungsbild (quite the opposite!), it was not a breach of trust. Frankly: I don't care the least, what Eric says. Of course the Meinungsbild (RfD) at deWP was a vote of noconfidence after the previous events at enWP. But the reaction by WMF was unprecedented and it was a mistake. A serious one. It damaged the relation between the Community and the WMF, it killed Jan's job and it made Rachel's job very difficult if not untenable. To describe Eric's action I am tempted to use a metaphor that includes black uniforms and heavy boots. But that would not be appropriately written by a German to a German. Until this event, I thought the dev process to be broken, not just the communication around devs. But now I believe the conflict runs deeper. It points out an issue we (community and WMF) should discuss, in a more general sense. What should the decision process be for technical changes? When does the Foundation get precendence, and when should the community have the last word? What weight should small-scale votes of editors have? Should random polls be done, and included in such votes? Etc. The MediaViewer affair itself gets blown out of proportion IMO. I agree that this is not just about the MediaViewer but about a general pattern of behavior perceived by the community. The WMF's decision making regarding software and skin development is broken. Its targets are flawed, it is not properly communicated with the community, the actual development processes result in incredibly crappy software that gets rolled out non the less in pre-alpha states. Do I have to list all the broken projects? Liquid feedback, article feedback tool, image filter, visual editor, flow, the new thumb layout. How do you explain that to donors by the way? All of them show that the devs and the management level do not understand the features of the existing solutions, particularly the well established tools and sometimes work arounds, authors created over the years to deal with the very basic MediaWiki. But understanding the actual use of MediaWiki is paramount to improving it. Ciao Henning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
Erik, I'm impartial about the mediaviewer, but I have the feeling that this is a recurring a pattern: 1) contributors ask for some change to improve their experience or the reader's experience 2) their request is ignored because either it doesn't fit in the big picture, or there is no mechanism for them to voice a request other than to fill a bugzilla or start a rfc that will be gathering dust till the end of the days 3) the changes are implemented anyhow in a hackish way, or not implemented at all 4) technical debt builds up until there is the need to find a stable solution 5) the wmf steps in with a good technical solution, or comes up with some unrequested neat feature, but without gathering grassroots support 6) some editors are presented the tool, nobody complains because it is a feature still in development 7) the feature is rolled out hoping it will be accepted - if it is not - conflict It would be more sensible to let contributors participate in the tech roadmap in more formal and empowered way than now, because without that early participation there is no possibility for later consensus. After the experience with the Wikisource Community User Group, I can say that with some effort promoting dialogue at international level, it is possible for the community to come up with a set of priorities and that builds up legitimacy. However that is all for nothing if that consensus has no impact in the development plan. Besides there seems to be a communication barrier between the contributors and the wmf that shouldn't be there, and I don't think the best way to remove it is to add more privileges or constraints, because that makes the barrier higher, not lower. TBH, I hope that the compromise options that you are drafting stop this drama, but it is also important to learn from how it came to be, so it doesn't repeat again. Cheers, Micru On Thu, Aug 14, 2014 at 11:57 AM, Erik Moeller e...@wikimedia.org wrote: On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride z...@mzmcbride.com wrote: Is there anything that the German Wikipedia could do to convince you to disable MediaViewer there? Some percentage of active users showing up to say so? Some percentage of users (logged-in or otherwise) disabling the feature? (Presumably we can get stats of some kind.) We are very open to continuing the discussion about how the feature should be configured, how it should be improved, and how it should be integrated in the site experience. Ideally we'd like to minimize inconsistencies between wikis (because for readers who speak more than one language, it's just a single site), so changes that help alleviate conflict or disagreement should ideally also be of the kind that in general are welcomed and wanted. On the subject of opt-out numbers, you can see them here: http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-graphs-tab As you can see, the recent drama has contributed to a significant increase in opt-out events. Pre-vote, about 17% of very active (100 edit/month) users had disabled MMV. This is about the same number of people who ultimately voted no, BTW, about 200. Post-vote it was 20%. Since then it has climbed to 23%. In contrast, about 30% of that same user group still use Monobook. I think those numbers can and should reasonably inform the default for logged in users, for sure. I don't think they should be used to determine the default for readers. In general, though, let's talk. The overarching principle we're not going to budge on is that this process is really not acceptable: 1) The UI changes 2) A subset of users is upset and organizes a poll/vote 3) The poll/vote closes with a request to undo said UI Change and a request is filed 4) WMF offers compromise or says no 5) A local hack is used to undo said UI change That's no way to develop software, and that's no way to work together. If you want a WMF that slavishly implements RFCs or votes to disable features upon request, you'll need to petition to replace more than just one person. In fact, you should petition to reduce the staff dramatically, find an administrative ED who has no opinion on what to do, and exclusively focus on platform-level improvements and requests that clearly have community backing. This is not the org we want to be. I am hopeful and optimistic that there are enough admins and regular editors who believe in a vision of improving the user experience iteratively, and working together through conflict, that we can in future entirely rely on local admins to prevent the kind of JS hacks we've seen here, working towards a proper code review and deployment mechanism that further alleviates the risk of escalations. Mind you, we made it very clear in this case ahead of time that JS hacks were unacceptable, we attempted a revert and a very explicit warning. None of us love drama. We've been punting on this issue for a long time, living with ambiguity that we knew
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On 14 August 2014 13:56, David Cuenca dacu...@gmail.com wrote: It would be more sensible to let contributors participate in the tech roadmap in more formal and empowered way than now, because without that early participation there is no possibility for later consensus. A pattern we see over and over is that the developers talk at length about what they're working on in several venues, then it's released and people claiming to speak for the community claim they were not adequately consulted. Pretty much no matter what steps were taken to do so, and what new steps are taken to do so. Because there's always someone who claims their own lack of interest is someone else's fault. - d. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Board statement on the Media Viewer roll out
Hi all, Some of you have asked the Board and its individual members for feedback. Some of us are already in conversation with you or are planning to answer on different pages. This is our general common statement: The Board supports the decision to protect the Media Viewer roll out. Our platform powers a top-5 website. We need operational protocols that are consistent with this position. This includes making improvements, rather than a tendency towards reverting to the status quo. At the Board meeting before Wikimania, Lila laid out her strategy to put in place best practices for product development. We will communicate sooner, we will prioritize smarter, we will test more, and we will achieve better outcomes. Her vision is to involve the community at each step of product development, including more structured feedback stages and reviews. We endorse this vision. We realize that there is concern about the superprotect user right and how it affects power balance and influence on content and administration. We recognize the concern that we need to explain and introduce our measures better. However, stability of the platform is necessary as we seek to improve our sites, and, for that reason, we support the creation of this tool. We also understand that with more robust rollout plans and better staged community feedback - as Lila envisions - the tool should rarely be used. We urge you to focus on specific improvements you'd like to see in the Media Viewer and the roll-out process. Lila intends to incorporate that feedback as she plans to improve Media Viewer and the process for future product roll outs. The Wikimedia Foundation needs to be in a position to make software and configuration changes for which it is responsible. We expect restrictions of MediaWiki code-level editing to be a temporary step to enable us to move forward with improvements. As we say, Media Viewer should be improved; our procedures to date have not yet met the high standards we want to set for ourselves. Lila wants to address both now, and we need to give her the space to do so. She has our full support and confidence as she tackles this tough challenge. On behalf of the Wikimedia Board of Trustees Jan-Bart de Vreede Chair Board of Trustees Wikimedia Foundation ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] We have an awesome Translation Tools....made for English speakers first
Dear all, I would like to draw your attention on the Translation Extension for Mediawiki, since 2 years now, community members ask to improve this extension by adding the possibility to select the original language. https://bugzilla.wikimedia.org/show_bug.cgi?id=35489 We are in a movement where the knowledge exchange is a primary concern, we have a really good tools to facilitate the translation of the documentation, but today we are still obliged to first translate manually in English before being able to use the Translate extension. I’m not a Tech guy, I try to read the bug's page linked before, and the only message I can get from is « you, non English speakers, are not our priority ». The ability to translate in multiple language the documentation created by non English speakers is a major challenge, we need to make it happen more often. Everyday I heard French speaker saying that they do not belong to the Wikimedia Community because it’s all in English/all for English, I do not pretend that improving the Translate extension will solve this issue, but it could be a little step forward. thank for your attention Charles ___ Charles ANDRES, Chief Science Officer Wikimedia CH – Association for the advancement of free knowledge – www.wikimedia.ch Office +41 (0)21 340 66 21 Mobile +41 (0)78 910 00 97 Skype: charles.andres.wmch IRC://irc.freenode.net/wikimedia-ch http://prezi.com/user/Andrescharles/ ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Aug 14, 2014 3:58 AM, Erik Moeller e...@wikimedia.org wrote: On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride z...@mzmcbride.com wrote: Is there anything that the German Wikipedia could do to convince you to disable MediaViewer there? Some percentage of active users showing up to say so? Some percentage of users (logged-in or otherwise) disabling the feature? (Presumably we can get stats of some kind.) We are very open to continuing the discussion about how the feature should be configured, how it should be improved, and how it should be integrated in the site experience. Ideally we'd like to minimize inconsistencies between wikis (because for readers who speak more than one language, it's just a single site), so changes that help alleviate conflict or disagreement should ideally also be of the kind that in general are welcomed and wanted. Provided they're what you would have done anyway. Otherwise, they're welcomed with WONTFIX and superprotection. On the subject of opt-out numbers, you can see them here: http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-graphs-tab As you can see, the recent drama has contributed to a significant increase in opt-out events. Pre-vote, about 17% of very active (100 edit/month) users had disabled MMV. This is about the same number of people who ultimately voted no, BTW, about 200. Post-vote it was 20%. Since then it has climbed to 23%. In contrast, about 30% of that same user group still use Monobook. I'm glad you know why people choose to opt out. I don't see that in the data you cited, how was that data gathered? I think those numbers can and should reasonably inform the default for logged in users, for sure. I don't think they should be used to determine the default for readers. What should inform the default for readers are the communities who care enough about those readers to volunteer millions of hours per month generating, curating, and protecting the world's largest ever educational work for the benefit of those very same readers. Yet WMF dismisses and belittles those volunteers as power users who couldn't care less, but hey, WE know best, now get out of our way or else! Then, of all things, the next question is Gee, why can't we retain good editors and attract new ones? In general, though, let's talk. The overarching principle we're not going to budge on is that this process is really not acceptable: 1) The UI changes 2) A subset of users is upset and organizes a poll/vote 3) The poll/vote closes with a request to undo said UI Change and a request is filed 4) WMF offers compromise or says no 5) A local hack is used to undo said UI change Nor is this: 1) The UI changes 2) A given project rejects or requests modification to the change 3) WMF crams it right down their throat regardless. 4) Local admins do what they can to implement the consensus, as they are selected by the community to do. 5) WMF throws a fit and threatens those admins or gives itself super authority. In your scenario, it's unacceptable that we ever reach step 5. The community, not the WMF, must be the final authority on each project. That's no way to develop software, and that's no way to work together. If you want a WMF that slavishly implements RFCs or votes to disable features upon request, you'll need to petition to replace more than just one person. In fact, you should petition to reduce the staff dramatically, find an administrative ED who has no opinion on what to do, and exclusively focus on platform-level improvements and requests that clearly have community backing. If there were a mechanism for a vote of no confidence, I think you'd see exactly that take place right now. But yes, if the current WMF will not back down from this position, we need a better one, and one with far less power to provide a temptation for abuse. That is not a desirable outcome, but it seems a necessary one more each day. Except in cases where legal issues are at play, WMF must not overrule local communities. This is not the org we want to be. That's unfortunate. We have always operated as a community centered and consensus driven project, and that has worked not only well but stunningly well. I am hopeful and optimistic that there are enough admins and regular editors who believe in a vision of improving the user experience iteratively, and working together through conflict, that we can in future entirely rely on local admins to prevent the kind of JS hacks we've seen here, working towards a proper code review and deployment mechanism that further alleviates the risk of escalations. Mind you, we made it very clear in this case ahead of time that JS hacks were unacceptable, we attempted a revert and a very explicit warning. And we made it clear ignoring the results was unacceptable. If you want to stop escalations, don't handwave away the people who day to day run the projects. There isn't a way you can overrule
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Thu, Aug 14, 2014 at 3:35 PM, David Gerard dger...@gmail.com wrote: A pattern we see over and over is that the developers talk at length about what they're working on in several venues, then it's released and people claiming to speak for the community claim they were not adequately consulted. Pretty much no matter what steps were taken to do so, and what new steps are taken to do so. Because there's always someone who claims their own lack of interest is someone else's fault. Talking in several venues about what one is doing cannot be considered consensus building. Actually it is the opposite, because it is an extrinsic change and as such it cannot be appropriated by any ad-hoc community. Even worse, it gives developers the wrong impression that they are working under general approval, when actually they might be communicating only with the people that normally would accept their project, but not the ones that normally would reject it. It is of course impossible to involve everyone, but the more voices are included the better represented will be the interests of the ones that are not present. Cheers, Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Board statement on the Media Viewer roll out
Hi Jan-Bart, thanks for this statement. Thanks to all on the board and Lila working on this, the improvement of our website and trying to recover the trust of our community. /Manuel Am 14.08.2014 15:42, schrieb Jan-Bart de Vreede: Some of you have asked the Board and its individual members for feedback. Some of us are already in conversation with you or are planning to answer on different pages. This is our general common statement: [...] -- Wikimedia CH - Verein zur Förderung Freien Wissens Lausanne, +41 (21) 34066-22 - www.wikimedia.ch ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] We have an awesome Translation Tools....made for English speakers first
It is weird that, for example, chapters' pages on Meta should be written in English and then translated into native language -- according to current logic. I agree with Charles, this change would be a step forward. Sure, translators-l will also agree. *Vira Motorko* Help save natural resources - please think twice before printing this e-mail or any attachments. 2014-08-14 16:43 GMT+03:00 Charles Andrès charles.andres.w...@gmail.com: Dear all, I would like to draw your attention on the Translation Extension for Mediawiki, since 2 years now, community members ask to improve this extension by adding the possibility to select the original language. https://bugzilla.wikimedia.org/show_bug.cgi?id=35489 We are in a movement where the knowledge exchange is a primary concern, we have a really good tools to facilitate the translation of the documentation, but today we are still obliged to first translate manually in English before being able to use the Translate extension. I'm not a Tech guy, I try to read the bug's page linked before, and the only message I can get from is you, non English speakers, are not our priority . The ability to translate in multiple language the documentation created by non English speakers is a major challenge, we need to make it happen more often. Everyday I heard French speaker saying that they do not belong to the Wikimedia Community because it's all in English/all for English, I do not pretend that improving the Translate extension will solve this issue, but it could be a little step forward. thank for your attention Charles ___ Charles ANDRES, Chief Science Officer Wikimedia CH - Association for the advancement of free knowledge - www.wikimedia.ch Office +41 (0)21 340 66 21 Mobile +41 (0)78 910 00 97 Skype: charles.andres.wmch IRC://irc.freenode.net/wikimedia-ch http://prezi.com/user/Andrescharles/ ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Mexico facts about Wikipedia
Hi folks, For any interested, today appear in the blog Codigo Espagueti[1] a survey about the trust in Wikipedia and the use both in Mexico and the United States. Some facts: - 60% of people with internet access in Mexico has heard about Wikipedia. - 82% are very or somewhat confident. In contrast, only 16% have little or no credibility. - In Mexico 59% use this site to learn about different topics and 53% in USA. The blog post does not indicate the method of the survey, but is a interesting exercise. Cheers. [1] http://codigoespagueti.com/noticias/wikipedia-mexico-encuesta/ -- *Atentamente:Iván MartínezPresidenteWikimedia México A.C.wikimedia.mx http://wikimedia.mxImagina un mundo en donde cada persona del planeta pueda tener acceso libre a la suma total del conocimiento humano. Eso es lo que estamos haciendo http://es.wikipedia.org. * ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Board statement on the Media Viewer roll out
The Board did not even consider to apologize for the rushed interference of WMF staff on de:MediaWiki:Common.js which caused so much trouble in the last days? No empathy for German Wikimedians who feel completely overruled and locked out from maintaining its display and implementing community consensus, a long established procedure btw.? No urge on WMF staff to implement policies on who should use superprotect and when in order to maintain our display the best, together? By just telling us that they did what they had to do and would even repeat it identically (without warnings, discussions, or anything) just in order to remove some bad JavaScript code which was not covered by community consensus either and hence would have been removed by local administrators anyway, you most likely will lose much more trust there and globally which cannot be the goal you wanted to achieve. Personally, I know that superprotect can be helpful in certain circumstances because I had to deal with JavaScript abuse on Common.js'es as a Wikimedia steward from time to time. That is why I support creating a tool which prevents inexperienced admins from maintaining our display. But does that necessarily be rushed which will leave an impression of attacking the community by interfering in their originated responsibilities although this was not intended? Without any idea which groups from now on will maintain the display (crats? stewards? on consensus? on WMF instruction), or does WMF staff wants to maintain all Commons.js, Vector.js, Monobook.js, etc. on all 900 wikis alone? Some clarifications are needed in order to solve this problem together. And that should be our goal: working together to make Wikimedia projects are more welcome place for readers, authors, and anyone. Cheers, Martin 2014-08-14 15:42 GMT+02:00 Jan-Bart de Vreede jdevre...@wikimedia.org: Hi all, Some of you have asked the Board and its individual members for feedback. Some of us are already in conversation with you or are planning to answer on different pages. This is our general common statement: The Board supports the decision to protect the Media Viewer roll out. Our platform powers a top-5 website. We need operational protocols that are consistent with this position. This includes making improvements, rather than a tendency towards reverting to the status quo. At the Board meeting before Wikimania, Lila laid out her strategy to put in place best practices for product development. We will communicate sooner, we will prioritize smarter, we will test more, and we will achieve better outcomes. Her vision is to involve the community at each step of product development, including more structured feedback stages and reviews. We endorse this vision. We realize that there is concern about the superprotect user right and how it affects power balance and influence on content and administration. We recognize the concern that we need to explain and introduce our measures better. However, stability of the platform is necessary as we seek to improve our sites, and, for that reason, we support the creation of this tool. We also understand that with more robust rollout plans and better staged community feedback - as Lila envisions - the tool should rarely be used. We urge you to focus on specific improvements you'd like to see in the Media Viewer and the roll-out process. Lila intends to incorporate that feedback as she plans to improve Media Viewer and the process for future product roll outs. The Wikimedia Foundation needs to be in a position to make software and configuration changes for which it is responsible. We expect restrictions of MediaWiki code-level editing to be a temporary step to enable us to move forward with improvements. As we say, Media Viewer should be improved; our procedures to date have not yet met the high standards we want to set for ourselves. Lila wants to address both now, and we need to give her the space to do so. She has our full support and confidence as she tackles this tough challenge. On behalf of the Wikimedia Board of Trustees Jan-Bart de Vreede Chair Board of Trustees Wikimedia Foundation ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Mexico facts about Wikipedia
Thanks Ivan for sharing the interesting survey. After Britain, the survey in Mexico and US unveils that Wikipedia is still a major online platform for learning and majority of people have faith on it. Regards, Tanweer On Thu, Aug 14, 2014 at 8:16 PM, Ivan Martínez gala...@gmail.com wrote: Hi folks, For any interested, today appear in the blog Codigo Espagueti[1] a survey about the trust in Wikipedia and the use both in Mexico and the United States. Some facts: - 60% of people with internet access in Mexico has heard about Wikipedia. - 82% are very or somewhat confident. In contrast, only 16% have little or no credibility. - In Mexico 59% use this site to learn about different topics and 53% in USA. The blog post does not indicate the method of the survey, but is a interesting exercise. Cheers. [1] http://codigoespagueti.com/noticias/wikipedia-mexico-encuesta/ -- *Atentamente:Iván MartínezPresidenteWikimedia México A.C.wikimedia.mx http://wikimedia.mxImagina un mundo en donde cada persona del planeta pueda tener acceso libre a la suma total del conocimiento humano. Eso es lo que estamos haciendo http://es.wikipedia.org. * ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe -- Regards - Tanweer Morshed ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] How to change the world
This is a talk from Rick Falkvinge, founder of the Swedish Pirate Party, at the TEDx in Oslo last year. I thought it was worth sharing with you all: http://tedxtalks.ted.com/video/Changing-the-world-through-swar It would be really interesting to apply these methods within Chapters and the overall Wikimedia community :-) Hope to see you soon again, always great to be at Wikimania. Aubrey Wikimedia Italia ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Superprotect user right, Coming to a wiki near you
Re: Erik Möller's remark: In general, though, let's talk. The overarching principle we're not going to budge on is that this process is really not acceptable: 1) The UI changes 2) A subset of users is upset and organizes a poll/vote 3) The poll/vote closes with a request to undo said UI Change and a request is filed 4) WMF offers compromise or says no 5) A local hack is used to undo said UI change That's no way to develop software, and that's no way to work together = I could spend 10,000 words on this. I'll try to keep it (comparatively) short. The reason this dysfunctional situation develops, Erik, is because there are no steps A, B, C, D, E, F, and G preceding #1 on the list. As things currently stand, this is the way the software development process at WMF seems to me to work: * Engineers collecting paychecks obviously need something to do. * Someone comes up with a bright idea that sounds good on paper. * Engineers decide to make that idea a reality and start work. * Inadequately tested software, sometimes of dubious utility, is unilaterally imposed on volunteers. * If new software is problematic enough, volunteers revolt by any means necessary. * WMF forces changes down throat of volunteers by any means necessary. This is truly no way to develop software and no way to work together. - Here is the way the process SHOULD begin: * WMF staffers, plural, identify by user names/IP addresses the 10,000 or so very active volunteers across all projects and database them. * WMF staffers further divide this group into coherent types: content writers, gnome-type copy editors, structural adapters (template people, bot operators, etc.), quality control workers (NPP, AfD), vandal fighters, behavioral administrators (ArbCom, Ani, the various Admin pages), and drone bees who do nothing but Facebook-style drama mongering. Multiple categories may apply to single individuals and this list is not necessarily exhaustive. * Once identified, WMF staffers frequently and regularly poll very active users in each category about WHAT THEY NEED. Different surveys for different volunteer types. * Software development starts ONLY when a real need is identified. * Software should be introduced on En-WP, De-WP, or Commons ONLY when it is Alpha-grade, debugged and ready to roll. (Test things on the smaller Wikis first). - Moreover, there should be some polling mechanism to summarize and analyze what the 500 million or whatever readers worldwide feel that they like and feel they are missing. User experience changes with primary impact on readers rather than volunteers (such as MediaViewer) should be made with them in mind first and foremost; editing and structural tools should be made to actually assist the active volunteers, not created on a whim. Sometimes the needs of the Readers and the needs of the Volunteers are different, let us frankly say. In no case should WMF assume the views and criticism of the latter are insignificant or wrong simply because 500,000,000 10,000. Remember this because according to the same logic: 10,000 240. - We all agree that we need a bigger pool of very active volunteers. Most readers are never going to be very active volunteers, nor do we want them to be, since we need specialized skill sets. Most people using the editing software are only going to make one or a very few changes a year and they are never going to even see the backstage world of Wikipedia. That is normal and fine. We do need expert contributors on esoteric topics and we need solid contributors from the developing world and we need to replenish the people doing copy editing and quality control work. We don't need tools that nobody asked for and nobody wants shoved down our throats just because engineers needed something to do. 240 Paid Staff + 10,000 Serious Volunteers + 500,000,000 Readers and occasional minor contributors Three groups with differing needs. Tim Davenport /// Carrite on WP /// Randy from Boise on WPO Corvallis, OR ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you
Henning writes: To describe Eric's action I am tempted to use a metaphor that includes black uniforms and heavy boots. But that would not be appropriately written by a German to a German. My experience over the last quarter century suggests that this metaphor rarely works out well. --Mike Godwin ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you
On Thu, Aug 14, 2014 at 5:37 PM, Mike Godwin mnemo...@gmail.com wrote: Henning writes: To describe Eric's action I am tempted to use a metaphor that includes black uniforms and heavy boots. But that would not be appropriately written by a German to a German. My experience over the last quarter century suggests that this metaphor rarely works out well. COMPLETELY OTI'm sorry, can I say LOL?/OT Cheers, Aubrey --Mike Godwin ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On 08/14/2014 02:36 PM, David Gerard wrote: So locally-editable site JavaScript, for locally-important gadgets and so forth, is in fact something that's needed. That seems reasonable, but it's less clear to me that this should be bundled with / part of the 'editinterface' right, at least as it is currently managed (the ability to be able to change wording of system message is only related to being able to change javascript/CSS by way of hysterical raisins). Regardless of which process, in the end, is adopted to make management of sitewide customization to javascript etc, separating that from normal editinterface seems to me to be prerequisite. -- Marc ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] [Wikimedia Announcements] This Month in GLAM: July 2014
*This Month in GLAM* is a monthly newsletter documenting recent happenings within the GLAM project, such as content donations, residencies, events and more. GLAM is an acronym of *G*alleries, *L*ibraries, *A*rchives and *M*useums. You can find more information on the project at glamwiki.org. *This Month in GLAM – Issue VII, Volume IV – July 2014* -- France report: Mass-upload http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/France_report Germany report: Exhibition photography http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Germany_report Italy report: Reaching museums' national associations http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Italy_report Netherlands report: Expedition Wikipedia content donations and course; Naturalis; GLAMwiki Toolset Workshop http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Netherlands_report Sweden report: Slow summer in Sweden http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Sweden_report UK report: Skye boat song, tanks, feminist film, surgery for skeptics and survey results http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/UK_report USA report: New York City Report http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/USA_report Open Access report: JATS 4 Reuse; Automated import into Wikisource and Commons http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Open_Access_report Calendar: August's GLAM events http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Contents/Events -- Single page view http://outreach.wikimedia.org/wiki/GLAM/Newsletter/July_2014/Single Twitter http://twitter.com/ThisMonthinGLAM Add your story / Work on the next edition http://outreach.wikimedia.org/wiki/GLAM/Newsletter/Newsroom -- The *This Month in GLAM* team http://outreach.wikimedia.org/wiki/GLAM/Newsletter ___ Please note: all replies sent to this mailing list will be immediately directed to Wikimedia-l, the public mailing list of the Wikimedia community. For more information about Wikimedia-l: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l ___ WikimediaAnnounce-l mailing list wikimediaannounc...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On 14 Aug 2014 14:50, David Cuenca dacu...@gmail.com wrote: On Thu, Aug 14, 2014 at 3:35 PM, David Gerard dger...@gmail.com wrote: A pattern we see over and over is that the developers talk at length about what they're working on in several venues, then it's released and people claiming to speak for the community claim they were not adequately consulted. Pretty much no matter what steps were taken to do so, and what new steps are taken to do so. Because there's always someone who claims their own lack of interest is someone else's fault. Talking in several venues about what one is doing cannot be considered consensus building. Actually it is the opposite, because it is an extrinsic change and as such it cannot be appropriated by any ad-hoc community. Even worse, it gives developers the wrong impression that they are working under general approval, when actually they might be communicating only with the people that normally would accept their project, but not the ones that normally would reject it. how should this be solved? To me it's saying that no matter who is informed, the WMF can never expect that their work won't be overruled. That is problematic (regardless of who has the final authority) Cheers, Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Deployment targets and preferences (was: Superprotect user right, Comming to a wiki near you)
Hi, I propose some constructive ideas to improve the deployment of new features: * granular deployments: create user profiles where the users can choose if they want an overall appearance: * never ever change my interface: some experienced authors do not like when one change every month their workflow if they are happy with it, * experienced editor: some experienced editors want new features or see what the newbies see, * newbie: the newbies/editors-to-be could expect an editing environment possibly different than the reader environment, * reader: the readers have their own expectations for easy reading, * etc. The features could be deployed only for some groups, giving more flexibility to deploy reader features for readers, etc. Obviously there are preferences, but the newbies have no experience about it, and the experienced editors have to be discover new preferences on a case-by-case basis, making it difficult to everybody to track the preferences. * implement global preferences (and the possibility to change locally or globally, like in Mailman) [bug 14950][] * when a new feature is introduced, propose to users (not in never ever change my interface) if they want the new feature, locally or globally, possibly using the Notifications bar, or with some message in the prefs page and highlighting it on the prefs page * work on a better organisation of the preferences, e.g. add an exhaustive preference panel similarly to Firefox’s about:config to permit the developers to add more preferences and hence offering more customisation possibilities for advanced users, by nullifying the argument the preferences page is too complicated for new users * as it was proposed, add a review process for the gadgets+JS pages to avoid performance, security, usability issues, possibly with the help of the tech staff, and possibly with the general MediaWiki code review (gerrit/Phabricator) with some gateway between it and the MediaWiki websites [bug 69445][] [bug 20153][] In other words, improve the deployment targets and give easy choices to users to opt-in/opt-out/etc the new features depending on their willingness to change their environment. And although I’m neither a loudly people neither the community, I vote to remove the superprotect right and any other enforcement of this type in the future. It’s like an edit war where one party has the power to silence the other, and like all edit wars there are at least two wrong versions. [bug 69445]: https://bugzilla.wikimedia.org/show_bug.cgi?id=69445 [bug 14950]: https://bugzilla.wikimedia.org/show_bug.cgi?id=14950 [bug 20153]: https://bugzilla.wikimedia.org/show_bug.cgi?id=20153 ~ Seb35 ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On 14/08/14 16:07, Yaroslav M. Blanter wrote: This is actually not correct. Take pending changes on the English Wikipedia as an example - people used to complain a lot on how RfC's were closed, but this is the business of the community. I have never heard anybody complaining that the trial sucked, or that PC itself does not work properly. There was a discussion, there was a trial, everything was properly announced, and everything from the developers's side was done perfectly or close to perfectly. Take Phase I Wikidata - this is smth I was actively participating in and watched it from the close distance. Everything went smoothly, with the Hungarian Wikipedia trial starting first, the Italian Wikipedia a bit later, when feedback was taken into account, and then other Wikipedias followed. Again, no problem with the developers whatsoever. Now compare this with VE, AFT, Mediaviewer, and Flow will be probably the next disaster of a comprable scale - despite the fact that WMF is pretty open about Flow, and there are many people answering questions basically in real time. Cheers Yaroslav It may be that specific teams, not just legal and whatnot but also including within engineering itself, are better at handling this sort of thing than others. Have there been any patterns with how well things go depending on who is involved? If so, perhaps the others could learn from them... -I ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Thu, 14 Aug 2014, at 23:35, David Gerard wrote: On 14 August 2014 13:56, David Cuenca dacu...@gmail.com wrote: It would be more sensible to let contributors participate in the tech roadmap in more formal and empowered way than now, because without that early participation there is no possibility for later consensus. A pattern we see over and over is that the developers talk at length about what they're working on in several venues, then it's released and people claiming to speak for the community claim they were not adequately consulted. Pretty much no matter what steps were taken to do so, and what new steps are taken to do so. Because there's always someone who claims their own lack of interest is someone else's fault. - d. How could presence of interest help people to fix media viewer? From its early beta testing, I wrote numerous feedback about how going fullscreen is a misleading redundant step. It was not implemented. What more interest could I have? It's not like I care about this too much, but I'm curious as to what you expect me to be able to do to display my interest. svetlana ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Fri, 15 Aug 2014, at 09:47, svetlana wrote: On Thu, 14 Aug 2014, at 23:35, David Gerard wrote: On 14 August 2014 13:56, David Cuenca dacu...@gmail.com wrote: It would be more sensible to let contributors participate in the tech roadmap in more formal and empowered way than now, because without that early participation there is no possibility for later consensus. A pattern we see over and over is that the developers talk at length about what they're working on in several venues, then it's released and people claiming to speak for the community claim they were not adequately consulted. Pretty much no matter what steps were taken to do so, and what new steps are taken to do so. Because there's always someone who claims their own lack of interest is someone else's fault. - d. How could presence of interest help people to fix media viewer? From its early beta testing, I wrote numerous feedback about how going fullscreen is a misleading redundant step. confusing wording; i mean: they still coded it to go fullscreen nomatter what i wanted them to have a dialog of sorts instead It was not implemented. What more interest could I have? It's not like I care about this too much, but I'm curious as to what you expect me to be able to do to display my interest. svetlana ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Mexico facts about Wikipedia
Great news Ivan! On Thu, Aug 14, 2014 at 8:50 PM, Tanweer Morshed wiki.tanw...@gmail.com wrote: Thanks Ivan for sharing the interesting survey. After Britain, the survey in Mexico and US unveils that Wikipedia is still a major online platform for learning and majority of people have faith on it. Regards, Tanweer On Thu, Aug 14, 2014 at 8:16 PM, Ivan Martínez gala...@gmail.com wrote: Hi folks, For any interested, today appear in the blog Codigo Espagueti[1] a survey about the trust in Wikipedia and the use both in Mexico and the United States. Some facts: - 60% of people with internet access in Mexico has heard about Wikipedia. - 82% are very or somewhat confident. In contrast, only 16% have little or no credibility. - In Mexico 59% use this site to learn about different topics and 53% in USA. The blog post does not indicate the method of the survey, but is a interesting exercise. Cheers. [1] http://codigoespagueti.com/noticias/wikipedia-mexico-encuesta/ -- *Atentamente:Iván MartínezPresidenteWikimedia México A.C.wikimedia.mx http://wikimedia.mxImagina un mundo en donde cada persona del planeta pueda tener acceso libre a la suma total del conocimiento humano. Eso es lo que estamos haciendo http://es.wikipedia.org. * ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe -- Regards - Tanweer Morshed ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe -- *Nurunnaby Chowdhury Hasive* Administrator | Bengali Wikipedia http://bn.wikipedia.org/wiki/user:nhasive Member | IEG Committee, Wikimedia Foundation https://meta.wikimedia.org/wiki/Grants:IdeaLab/People Social Media Interaction Moderator | The Daily Prothom-Alo http://www.prothom-alo.com Bangladesh Ambassador | Open Knowledge Foundation Network http://www.okfn.org Treasurer | Bangladesh Open Source Network (BdOSN) http://www.bdosn.org Task Force Member | Mozilla Bangladesh http://www.mozillabd.org fb.com/nhasive | @nhasive http://www.twitter.com/nhasive | Skype: nhasive | www.nhasive.com ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On 8/14/14, 3:35 PM, David Gerard wrote: On 14 August 2014 13:56, David Cuenca dacu...@gmail.com wrote: It would be more sensible to let contributors participate in the tech roadmap in more formal and empowered way than now, because without that early participation there is no possibility for later consensus. A pattern we see over and over is that the developers talk at length about what they're working on in several venues, then it's released and people claiming to speak for the community claim they were not adequately consulted. Pretty much no matter what steps were taken to do so, and what new steps are taken to do so. Because there's always someone who claims their own lack of interest is someone else's fault. I actually have not found the beta feature feedback pages to be very responsive. Is that what you had in mind? I've made an attempt to be on top of these things and discuss them before the rollout, lest I come to the party late and unhelpfully. But the beta-feature talk pages are full of people with questions and problems and no responses or solutions, or really any signs of life from anyone in a position to do anything. On the plus side, I was driven by this frustration to figure out what git and gerrit are. A simple bug in December rendered the beta Nearby feature completely unusable for weeks. There were many comments on the Talk page for that feature complaining that it had semi-recently become completely broken. But nobody seemed to be acknowledging, explaining, or making any effort to fix it. I eventually dug into the matter and discovered that the recently introduced problem was obvious and the fix was literally a 2-line patch. Then I spent about 1000x more time than it took to author the 2-line patch to figure out how to submit these two lines through git/gerrit bureaucracy. But being sufficiently annoyed, I did manage to submit a patch, which was eventually applied, and after some delay that fixed the brokenness. But that experience led me to believe that nobody is really paying attention to beta feedback! -Mark ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Special:PageLanguage (was: [Translators-l] We have an awesome Translation Tools....made for English speakers first)
On Fri, 15 Aug 2014, at 00:52, Niklas Laxström wrote: Translate extension has supported for a long time having any language as the source language. There just has not been an interface in MediaWiki to set the source language of a page. The good news is that Kunal Grover, a GSoC student has created Special:PageLanguage to do just that. [1] I expect it will be available quite soon. [...] [1] https://www.mediawiki.org/wiki/User:Kunalgrover05/Progress_Report On Fri, 15 Aug 2014, at 01:50, Philippe Verdy wrote: This is good development, but I don't see why we need a special page to define what is metadata of the page itself. [...] Yes, I have same question. On Fri, 15 Aug 2014, at 01:50, Philippe Verdy wrote: May be it will be accessible from the VisualEditor; like we edit categories, but such metadata is a general need for lots of other applications. The general need would be to be able to associate metadata with a symbolic type to any page: just a few metadata is currently handled in MediaWiki: categories, default sortkeys, interwiki links, plus a few other flags inserted by using magic words (like __NOINDEX__). There are also external metadata stored in Wikidata for some wiki projects. More are needed (e.g. for different typing sort keys). Any way I expect to see soon a reliable way to detect the page language including for translated pages; but more importantly for sources of translations without having to assume they are in English, or create thme in another language and creating a pseudo-translation to the original language by copying keys, then modifying the English source again but keeping the original text. At least, when we mark a new page for translation, we should immediately have an option asking in which language is the source; if it's not specifid by the new experimental Special:PageLanguage page (which is not necessarily needed). And once a source page has been marked for translation, the Translate tool should have a simple API to query its language or the language used in the generated translations, And ideally, we should be able to swithc from one source language to another (for example some projects start in English, but are later managed in German or Chinese, or a local Chapter initially creates documents in its own local language such as French, Hindi or Spanish, and will not use English as the reference (this is important for pages reporting local projects mostly done in other languages, outside countries or regions with a majority of native English-speakers, i.e: most countries of the world, including Europe (and even North America where French and Spanish are very present too ; Spanish and Chinese are also growing fast in US, and here there are aslo local communities that would like to promote their own local projects in their native non-English tongue : do you remember that US does not have any official language ?). Kunal Grover, could you please fill in about that? svetlana ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Statement on CIS-A2K's FDC proposal discussion
Dear Wikimedians, We have put out a statement on the CIS-A2K's FDC proposal discussion here [1]. As you will note the statement reflects on some of the critical points of feedback that we received and outlines the steps that we have taken and plan to take. On behalf of everyone at CIS, we thank the Wikimedians, WMIN EC, FDC Staff, FDC Members and the WMF Board who actively engaged with our FDC proposal. We have learnt some useful lessons because of the FDC discussions and assure you that we will continue to improve upon our programmatic efficiency, efficacy, accountability and transparency. Apologies, that this mail is coming at least a couple of weeks late. Best, Vishnu [[User:Visdaviva]] Program Director (A2K) CIS, India [1] http://bit.ly/1m0fQn0 ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
