Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating chriskeatingw...@gmail.com wrote: 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) A first step would be to abide to the principles of Open Process http://meatballwiki.org/wiki/OpenProcess Namely: - Transparency - all communications and decisions are public and archived, so anyone interested may get all information - No time constraints - all decisions (democratic or not) are suggested or announced a reasonable timespan before they become effective. So there is still time for discussion and even last minute intervention. - Participation - in principle (this opens the chance for restrictions in case of problems) anyone is welcome to participate (discussions, decisions *and* work) - * Reflection and reversibility - any decision may be reversed if the results are not as expected. * - Tolerance - any system or process should have the flexibility in the application of its - necessary - rules - Sharing and collaborating on visible and accessible goals and resources Then a second step would be to engage the community, not only as something that has to be managed, but as an equal partner that has to take up responsibilities and who is able to affect decisions. This of course means a paradigm shift moving away from community liaisons and into the realm of helping contributors to constitute themselves enabling them to take up a shared ownership role without the need of a formal organization. I don't think the wmf is entirely responsible for making this happen, there is also have to be a general will to embody such a spirit without resorting to staff, hierarchies, or votes. The problem is that most of us live in a world that doesn't work this way, and the attached structural flaws are imported, when there is no need to. Anyhow, that should be something to speak about when the tensions have been defused. 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] [Wikitech-l] Superprotect user right, Comming to a wiki near you
Hoi, David, who is the community and how do you get members of the community recognise and respect the decisions it does not like that are taken on their behalf by its representatives. We do not have one community, we have many. The interests people aim for are diverse and all too often contradictory.. Really, in the past one part of the community insisted that it ALWAYS requires to be able to have the deciding influence for its project.. That clearly pains the picture for me. Thanks, GerardM On 15 August 2014 10:17, David Cuenca dacu...@gmail.com wrote: On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating chriskeatingw...@gmail.com wrote: 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) A first step would be to abide to the principles of Open Process http://meatballwiki.org/wiki/OpenProcess Namely: - Transparency - all communications and decisions are public and archived, so anyone interested may get all information - No time constraints - all decisions (democratic or not) are suggested or announced a reasonable timespan before they become effective. So there is still time for discussion and even last minute intervention. - Participation - in principle (this opens the chance for restrictions in case of problems) anyone is welcome to participate (discussions, decisions *and* work) - * Reflection and reversibility - any decision may be reversed if the results are not as expected. * - Tolerance - any system or process should have the flexibility in the application of its - necessary - rules - Sharing and collaborating on visible and accessible goals and resources Then a second step would be to engage the community, not only as something that has to be managed, but as an equal partner that has to take up responsibilities and who is able to affect decisions. This of course means a paradigm shift moving away from community liaisons and into the realm of helping contributors to constitute themselves enabling them to take up a shared ownership role without the need of a formal organization. I don't think the wmf is entirely responsible for making this happen, there is also have to be a general will to embody such a spirit without resorting to staff, hierarchies, or votes. The problem is that most of us live in a world that doesn't work this way, and the attached structural flaws are imported, when there is no need to. Anyhow, that should be something to speak about when the tensions have been defused. 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
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] [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] [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] [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
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] [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
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
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] [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
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On 13.08.2014 02:48, svetlana wrote: On Wed, 13 Aug 2014, at 10:46, svetlana wrote: this community thinks that its power structures allow to tromp onto other people sysops aren't even held accountable they are elected once for an infinite term nobody reviews their contribution in position in power ever this would surely be solved by making them elected on a 2-year term then re-elect svetlana Sounds exactly like an indeffed former contributor to the Russian Wikipedia. I do not think we should discuss the administrator elections on this list. Anyway, there are projects where administrators only get elected for a finite period. Cheers Yaroslav ___ 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 13.08.2014 05:57, Pine W wrote: Two points I have heard off list are that 1. While it may be that disabling MV by default for logged-in users can be done, disabling it for those not logged-in is effectively another major UI change which a study shows likely will make some of them leave and not return; 2. German Wikimedians are going inactive in protest. Can someone confirm that both of those points are true? Point 2 is essentially impossible to confirm. People are coming, leaving and sometimes coming back (when I left the Russian Wikipedia in 2011, most of my opponents just said they are sure I was playing games and would be back soon). You never know why they leave, and even if they have left a clear message you never know how serious it is. It is quite unlikely that on a short term a significant share of active users will leave or has left - the German Wikipedia is not the Acehnese Wikipedia, and even if a dozen of users would leave at the same time, it can not be detected by the editing statistics. The long-time consequences and trends can of course be detected but then you would need to reach the active users who really have left and asked them why they left - it is unlikely anybody would successfully perform such study. Cheers Yaroslav ___ 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 Wed, 13 Aug 2014, at 12:01, Romaine Wiki wrote: 2014-08-13 2:46 GMT+02:00 svetlana svetl...@fastmail.com.au: [..] [...] instead of talking properly then the superprotect wouldn't exist at all you seeing the problem there? whose problem is it? desire to act out of the blue instead of collaborating they didn't collaborate at all they added the js hack as if it was something urgent, that needs saving people from i would only do this if someone added a virus into mv by mistake this community thinks that its power structures allow to tromp onto other people I do not think the community thinks that way. It doesn't think so inherently, but it lacks some useful habits. Members of the community can make mistake and staff members of WMF can make mistakes, I think that both that community and WMF are grown up enough to correct mistakes if they arise. Certainly inside the community are many critical people who watch these kind of things carefully and do correct those things when a mistake is made. The German community did collaborate, did communicate. Having a voting is a desperate way of getting the attention of the big problems WMF has too little insight in apparently. The community does not think in power structures, WMF does. Writing an RFC is a complicated process. You don't ask people whether they want to go backwards, for one; they almost always do, but it is not always a good thing. 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 Wed, Aug 13, 2014 at 3:27 AM, svetlana svetl...@fastmail.com.au wrote: On Wed, 13 Aug 2014, at 10:53, Pete Forsyth wrote: On Tue, Aug 12, 2014 at 5:46 PM, svetlana svetl...@fastmail.com.au wrote: On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote: That the community reacts the way it does now, is because they care very much about the site and they notice something is terrible going wrong on WMF side and too less is done to fix those problems/issues! if the community was not so willing to use force (ie a js hack) against the other party [...] You talk about admin accountability, Svetlana -- but what about accountability for the WMF, when it makes sweeping changes that (among other things) remove any suggestion of an edit functionality from the encyclopedia anyone can edit from millions and millions of pages? Pete [[User:Peteforsyth]] Surely this issue can be solved by talking without force: if you don't think so, you get force applied to YOU; you started a fight, and lost it. I have advocated using force? Where?! Please don't answer -- I am done with this thread, it has no basis in reality. Because you went and did something contradicting user preferences; WMF did not. You'd think it's better because it's unchanged compared to what it was X months ago, and that justifies your thing? No, it does not. I don't even know what you're talking about here. But again -- let's let it go. Pete ___ 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/13/2014 01:31 PM, Trillium Corsage wrote: [...] that he has affronted the community. I've spent no small amount of years involved in the various layers of administrative/governance/meta aspects of the English Wikipedia and from this I learned one lesson: Whenever someone says 'the community' without qualifying this to an enumerable set of users means the assertion is definitely false. There is no such thing as the community; we have a huge collection of communities joined loosely over a number of ambigously shared principles that often - but not always - move in more or less the same direction. Anyone who claims to speak for the community is - put simply - full of shit. -- 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
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier m...@uberbox.org wrote: There is no such thing as the community; we have a huge collection of communities joined loosely over a number of ambigously shared principles that often - but not always - move in more or less the same direction. Anyone who claims to speak for the community is - put simply - full of shit. So very true! All of the arguments that claim knowledge of what the community wants, or what the readers want, need to be regarded with a strong dose of skepticism, or put aside entirely. What we are left with is a question: which version is *acceptable*, as an interim measure, while a more careful decision -- involving things like research and better executed community consultation -- is made? In favor of the standard MediaWiki image interface is this: it has been part of a collection of features that, over a 13 year period, has led to Wikimedia sites becoming a top 5 web property, and is familiar to all the millions of people who have interacted with it (in that capacity, and on other MediaWiki-based sites) in that 13 year period. That is not to say it's perfect or anything close to it, but we do know that it is good enough. In favor of the Media Viewer software is a bunch of inquiry and analysis done by the WMF's Multimedia Team. The methodology has been widely criticized, and the results point in various directions. (For example, as I pointed out here https://en.wikipedia.org/wiki/Wikipedia:Arbitration/Requests/Case/Media_Viewer_RfC/Evidence#Evidence_presented_by_Pete_Forsyth, none of the 3 readers consulted by WMF in a User Experience study, although they were all technically proficient Internet users, were able to find the Details page on Commons using the MV software.) 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. This is not me drawing a line in the sand, but me observing what has become readily apparent. I am pretty sure this condition is outside of anybody's influence at this point -- it is simply the natural result of a poorly planned and executed product launch. Pete [[User:Peteforsyth]] ___ 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
13.08.2014, 01:46, svetlana svetl...@fastmail.com.au: if the community was not so willing to use force (ie a js hack) against the other party instead of talking properly then the superprotect wouldn't exist at all you seeing the problem there? whose problem is it? desire to act out of the blue instead of collaborating they didn't collaborate at all they added the js hack as if it was something urgent, that needs saving people from i would only do this if someone added a virus into mv by mistake this community thinks that its power structures allow to tromp onto other people I agree with your thinking here Svetlana, but would disagree with your terminology that the vocal complainers about superprotect should be shorthanded as the community. That is what they like to think of themselves, but they are really a minority of the community. They are the administrative culture. They are not really the editors, not really the readers, both of those groups dwarf the administrators and administrative participants. The community is all the readers, all the editors, and after them in size the vocal and visible administrative set. So Mr. Moeller shouldn't feel intimidated, and clearly doesn't, when a bunch of very loud people writes volumes of complaining text on discussion pages insisting that he has affronted the community. Trillium Corsage ___ 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 13 Aug 2014, at 21:12, Pete Forsyth petefors...@gmail.com wrote:
On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier m...@uberbox.org
wrote:
There is no such thing as the community; we have a huge collection of
communities joined loosely over a number of ambigously shared principles
that often - but not always - move in more or less the same direction.
Anyone who claims to speak for the community is - put simply - full of
shit.
So very true! All of the arguments that claim knowledge of what the
community wants, or what the readers want, need to be regarded with a
strong dose of skepticism, or put aside entirely.
{{citation needed}}
There are some community members who spend a lot of time thinking about what
the community and the readers may want, who actually have a good
understanding of what is needed to support those stakeholders. There are others
that say that their views represent the community/readers when they don't. A
distinction needs to be made there - don't confuse the former with the latter.
Additionally: there is no guarantee that what has worked well in the past will
continue to work well in the future. The internet is always changing and
improving, and a lot of organisations that dominated a decade ago now only
exist in historical record. Wikimedia really needs to match the current state
of the art, otherwise it will likely also cease to exist. I'd like to see the
Wikimedia community leading the way with the internet's development, but right
now it feels like it's lagging by about a decade, and the WMF is having to play
a leading role to keep it relevant. If the Wikimedia community can catch up
with the current state of the internet, that would be great, but if it can't
then supporting the WMF while it does so would make a lot of sense.
Thanks,
Mike
___
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 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, You speak as if there is no cost to disabling and re-enabling an interface. That is not the case. As you say, millions of readers use the site. And just like editors, introducing a new, very different viewing experience - like MV - takes some time to adjust to. We saw this in survey responses improving over time where they were initially negative, and we also saw it in some comments of the type I am getting used to it now and I like it. (We also got plenty of I love this, this is great type comments.) To the extent that there are discoverability issues in the current UI, they are just that: discoverability issues. That doesn't mean if the same user keeps using the same inteface, they will never click a button - it means it's harder to figure out than it needs to be. Some of this was already fixed in production. For example, adding a label to the Use this file button more than doubled its usage. This is how this stuff works: You instrument, you change, you learn. Other changes are underway. Turning off the UI completely means readers who have gotten used to it or who have always enjoyed it will have to re-learn the old UI, then re-learn the new UI when some (undetermined) set of conditions are met. That's jarring, confusing, and avoidable. 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. Yes, we can all agree that we need to continually raise the bar for how we build software (without getting into analysis paralysis) -- but that doesn't mean that reverting (here or in other cases) once there's an ad hoc vote (or two, or three) is the right thing to do. No other significantly sized organization follows the development methodology you're proposing WMF should follow. Certainly, WMF is an unusual organization, and we have every desire to take concerns seriously, engage with people, scrutinize data honestly, and work iteratively to make things better for everyone. What we can't and won't accept is the idea that admin-reverts of features are an OK way to try to enforce the outcome of an ad hoc poll or vote. We can - and should, and do - talk to figure things out. We can - and should, and do - work out compromises. (And we did indeed agree to implement a compromise solution for Commons.) But the idea that WMF always must slavishly execute the result of a poll or vote is neither rational nor sustainable, nor has it ever been practice --- much less controversially so in situations where WMF's decisions cannot be overriden by admins employing JavaScript hacks. 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. The fact that WMF doesn't implement every vote and indeed has in the past even been somewhat capricious at times when it did not (especially when such decisions were made just by a single dev applying their own best judgment) is not in question. From a communications perspective, we handled WP:ACTRIAL much more poorly than we did this (we responded way too late), for example. But you can't implement WP:ACTRIAL in JavaScript. But there is no governing principle - documented clearly - that says you can't disable a feature using the MW: namespace. WMF is saying it now, and people perceive that (understandably) as a power grab. Fair enough - it is the explicit extension of existing authority into a novel domain. Such a change is always contentious and controversial, but I don't think it was avoidable. If we are to work together effectively, we need to define areas of competency and responsibility clearly. Erik -- 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] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Wed, Aug 13, 2014 at 2:32 PM, Erik Moeller e...@wikimedia.org wrote: But the idea that WMF always must slavishly execute the result of a poll or vote is neither rational nor sustainable, While there may be some who suggest that WMF should do so, I am not one of them -- and nor are many of my colleagues. The RfCs are merely one data point. I would like to remind you (though I am getting tired of repeating my arguments, while you reflect back to me arguments that are substantially weaker than my own, and attack straw men) that mere reader preference is a ridiculous measurement to regard as final and binding, for a project that exists to fulfill a mission, and that developed a clear strategic plan to fulfill that mission. Where in the strategic plan does it say that if we feel that the readers are trending toward accepting something, then it is good? What if their ultimate acceptance of that makes them LESS likely to participate in the community, and MORE likely to merely consume information -- to have ACCESS to information, rather than to SHARE in our vision? I do not ask these questions because I want them answered now; I suggest that they should have been asked and explored long ago. For instance, when I brought them up in February.[1] They're still worthwhile to explore carefully now, but as long as the software remains enabled by default, in defiance of the thoughtful opinions of a majority of Wikipedians who have weighed in on 3 projects, I predict that it will be difficult to do so. -Pete [1] https://www.mediawiki.org/w/index.php?diff=907392 ___ 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 00:50, Pete Forsyth wrote: On Wed, Aug 13, 2014 at 3:27 AM, svetlana svetl...@fastmail.com.au wrote: [...] Surely this issue can be solved by talking without force: if you don't think so, you get force applied to YOU; you started a fight, and lost it. I have advocated using force? Where?! Please don't answer -- I am done with this thread, it has no basis in reality. I am being generic. The you refers to whoever made the edit which was reverted by WMF and super-protected. ___ 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 Moeller 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. Yes, we can all agree that we need to continually raise the bar for how we build software (without getting into analysis paralysis) -- but that doesn't mean that reverting (here or in other cases) once there's an ad hoc vote (or two, or three) is the right thing to do. No other significantly sized organization follows the development methodology you're proposing WMF should follow. Certainly, WMF is an unusual organization, and we have every desire to take concerns seriously, engage with people, scrutinize data honestly, and work iteratively to make things better for everyone. What we can't and won't accept is the idea that admin-reverts of features are an OK way to try to enforce the outcome of an ad hoc poll or vote. 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.) I'm curious what it would take for you to change course here. We should note that your behavior on the German Wikipedia has resulted in you being blocked there for a month. I get the sense that many people on the German Wikipedia feel as though there's no way you'll ever be convinced to disable MediaViewer. And from the comments I've been reading, this incident, along with others, has done significant damage to both your reputation and the reputation of the Wikimedia Foundation. We can - and should, and do - talk to figure things out. We can - and should, and do - work out compromises. (And we did indeed agree to implement a compromise solution for Commons.) But the idea that WMF always must slavishly execute the result of a poll or vote is neither rational nor sustainable, nor has it ever been practice --- much less controversially so in situations where WMF's decisions cannot be overriden by admins employing JavaScript hacks. You've not established an overriding interest here. If this issue related to online harassment or child protection or biographies of living people or the ability of users to edit or copyright or something else that matters, it might make sense for you to step in. But we're discussing an entirely supplementary feature. A few wikis (three by my count) have tried MediaViewer and have decided that they'd rather not have it be opt-out on their wiki. Instead they'd prefer that MediaViewer be opt-in for now. These communities have politely requested a configuration change, which should be within the purview of Wikimedia stewards, but MediaWiki doesn't yet have a graphical configuration user interface. Why deny these seemingly reasonable requests? MZMcBride ___ 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'll be writing a longer post on the Meta RFC later, but can you confirm whether the idea is to superprotect key interface pages like [[Mediawiki:common.js]] on a permanent basis, or will this feature only be used to lock pages temporarily in the case of wheel warring or other circumstances like what happened on de.wp? Thanks, Craig Franklin On 10 August 2014 23:27, Erik Moeller e...@wikimedia.org wrote: Hi folks, Admins are currently given broad leeway to customize the user experience for all users, including addition of site-wide JS, CSS, etc. These are important capabilities of the wiki that have been used for many clearly beneficial purposes. In the long run, we will want to apply a code review process to these changes as with any other deployed code, but for now the system works as it is and we have no intent to remove this capability. However, we've clarified in a number of venues that use of the MediaWiki: namespace to disable site features is unacceptable. If such a conflict arises, we're prepared to revoke permissions if required. This protection level provides an additional path to manage these situations by preventing edits to the relevant pages (we're happy to help apply any urgent edits) until a particular situation has calmed down. Thanks, Erik -- 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 ___ 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
Straniu, Jimbo's comments in his keynote about forking concerned encouraging competent editors who can't work cooperatively with other people to fork in a way that would be better for everyone in the long run. I don't believe this disappointing confrontation between the WMF and volunteers were what Jimbo had in mind. Pine On Aug 12, 2014 1:44 AM, Strainu strain...@gmail.com wrote: Hi Gerard, Some answers (in a random order). 2014-08-11 12:20 GMT+03:00 Gerard Meijssen gerard.meijs...@gmail.com: You know our projects, you know our licenses. If you, the communitydo not like what you have, you can fork. At Wikimania forking and leaving the community was very much discussed. Watch Jimbo's presentation for instance, he may be aghast that I quote him here but in his state of the Wiki he made it abundantly clear that it is your option to stay or go. I gave up watching Jimbo's keynotes a few years ago, as I would invariably get pissed off. So, should we understand that the vast ammounts of money and resources spent on editor retention are a waste of our money? I sincerely hope this is a heat-of-the-moment argument, just like the one about closing de.wp. Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything. Agreed. How about letting the WMF decide for anonymous users and the community decide for logged-in users? Presumably, the logged-in users have access to a large panel of options and can make up their own mind if they disagree with the consensus. Of course, discussions should not disappear because of such a separation, but even become more active and hopefully less aggressive. When you are in those conversations you realise that many complications are considered; it is not easy nor obvious. NB there is not one community, there are many with often completely diverging opinions. Technically it is not possible to always keep backward compatibility / functionality. We are not backward we need to stay contemporary. As a software engineer in a publicly traded company, I understand the reasoning behind more than 90% of the decisions made by the Engineering staff - and this worries me terribly, because they *don't* work for a company. Their objectives and approaches should be different. There are three main wiki-use-cases that should receive similar levels of attention: * reading * basic editing * advanced editing The first two receive a lot of love, but the third one not so much, it's even hindered by initiatives designed for the first two. I'm not saying that we should keep backwards compatibility forever, but since the WMF wants to deploy stuff early in order to get feedback, it should begin by offering it as a beta (they do that now), then, when reaching a decent level of stability, deploy it for anonymous users and opt-in users and only when it reaches feature-parity with the feature being replaced should it be pushed for everybody (keeping an opt-out feature for some time - months or a couple of years). Take for instance the media viewer: the current version is useless for editors, as it has basically no controls visible by default (without scrolling). The future version, presented at Wikimania, has a lot more stuff visible on the first screen, making it much easier to use for editing. I believe that the media viewer should have been kept as opt-in for logged in users until this future version arrives. Strainu ___ Wikitech-l mailing list wikitec...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-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 Tue, Aug 12, 2014 at 10:19 AM, Craig Franklin cfrank...@halonetwork.net wrote: I'll be writing a longer post on the Meta RFC later, but can you confirm whether the idea is to superprotect key interface pages like [[Mediawiki:common.js]] on a permanent basis, or will this feature only be used to lock pages temporarily in the case of wheel warring or other circumstances like what happened on de.wp? Dear Craig, Thank you for the question. Definitely the latter. In general, as I mentioned in my original note, we intend to bring on-wiki functionality that directly relates to the UI and code (i.e. chiefly the MediaWiki: namespace, which is a highly unusual software feature to begin with) in closer alignment with off-wiki software development, review and deployment practices, including permission levels (e.g. actually make it easier for anyone to submit changes, but gate changes that impact all users). Lila and I will post more thoughts on the larger issues within the coming days. We deeply regret the disruptive impact this discussion is having on Wikimedia's mission and our work together. At the same time, working through these questions has long been overdue, and my hope is that we can come out of this with greater clarity regarding how we partner on issues that are often likely to be contentious, which includes user experience changes. Sincerely, Erik -- 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] [Wikitech-l] Superprotect user right, Comming to a wiki near you
Has it ever come to the mind that something is going wrong on how the community is approached? Has it ever come to the mind that some software implementations have gone to hastily with negative effects? That the community reacts the way it does now, is because they care very much about the site and they notice something is terrible going wrong on WMF side and too less is done to fix those problems/issues! Apparently nothing (or not enough) has been learned from the VE 2013 fiasco. Romaine 2014-08-10 15:27 GMT+02:00 Erik Moeller e...@wikimedia.org: Hi folks, Admins are currently given broad leeway to customize the user experience for all users, including addition of site-wide JS, CSS, etc. These are important capabilities of the wiki that have been used for many clearly beneficial purposes. In the long run, we will want to apply a code review process to these changes as with any other deployed code, but for now the system works as it is and we have no intent to remove this capability. However, we've clarified in a number of venues that use of the MediaWiki: namespace to disable site features is unacceptable. If such a conflict arises, we're prepared to revoke permissions if required. This protection level provides an additional path to manage these situations by preventing edits to the relevant pages (we're happy to help apply any urgent edits) until a particular situation has calmed down. Thanks, Erik -- 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 ___ 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 Mon, Aug 11, 2014 at 6:54 PM, John Mark Vandenberg jay...@gmail.com wrote: On Tue, Aug 12, 2014 at 3:49 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jay...@gmail.com wrote: Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page. This is false. Care to explain? https://www.mediawiki.org/w/index.php?title=Manual:$wgRestrictionLevelsdiff=519048oldid=451673 shows that protection levels that prevent sysops from editing were considered as far back as 3 April 2012, for example. Most of what MZMcBride posted there has nothing to do with actually breaking superprotection. Editing a page that isn't superprotected isn't a break in the protection feature itself, for example. Of course it is. It isnt a 'feature' until it actually works at the released product level. You appear to be confusing superprotection with something else, likely the much larger concept of preventing JS hacks to disable MediaViewer. -- Brad Jorsch (Anomie) Software Engineer 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] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote: That the community reacts the way it does now, is because they care very much about the site and they notice something is terrible going wrong on WMF side and too less is done to fix those problems/issues! if the community was not so willing to use force (ie a js hack) against the other party instead of talking properly then the superprotect wouldn't exist at all you seeing the problem there? whose problem is it? desire to act out of the blue instead of collaborating they didn't collaborate at all they added the js hack as if it was something urgent, that needs saving people from i would only do this if someone added a virus into mv by mistake this community thinks that its power structures allow to tromp onto other people ___ 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 Wed, 13 Aug 2014, at 10:46, svetlana wrote: On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote: That the community reacts the way it does now, is because they care very much about the site and they notice something is terrible going wrong on WMF side and too less is done to fix those problems/issues! if the community was not so willing to use force (ie a js hack) against the other party instead of talking properly then the superprotect wouldn't exist at all you seeing the problem there? whose problem is it? desire to act out of the blue instead of collaborating they didn't collaborate at all they added the js hack as if it was something urgent, that needs saving people from i would only do this if someone added a virus into mv by mistake this community thinks that its power structures allow to tromp onto other people sysops aren't even held accountable they are elected once for an infinite term nobody reviews their contribution in position in power ever this would surely be solved by making them elected on a 2-year term then re-elect 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 Tue, Aug 12, 2014 at 5:46 PM, svetlana svetl...@fastmail.com.au wrote: On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote: That the community reacts the way it does now, is because they care very much about the site and they notice something is terrible going wrong on WMF side and too less is done to fix those problems/issues! if the community was not so willing to use force (ie a js hack) against the other party Using force could equally well apply to implementing a feature without sufficient buy-in, and then refusing to roll it back when so requested. The WMF's basis for concluding that readers are better served with the MV than without it is riddled with holes, as exhaustively explained elsewhere. You talk about admin accountability, Svetlana -- but what about accountability for the WMF, when it makes sweeping changes that (among other things) remove any suggestion of an edit functionality from the encyclopedia anyone can edit from millions and millions of pages? Pete [[User:Peteforsyth]] ___ 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
If the WF wasn't so willing to use force (i.e. pushing unwanted changes) against the other party instead of talking properly then the superprotect wouldn't exist at all you seeing the problem there? whose problem is it? desire to act out of the blue instead of collaborating they didn't collaborate at all they added Media Viewer as if it was something urgent, that will save people this WMF thinks that its power structures allow it to tromp onto other people Works perfectly the other way too, doesn't it? On Tue, Aug 12, 2014 at 6:46 PM, svetlana svetl...@fastmail.com.au wrote: On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote: That the community reacts the way it does now, is because they care very much about the site and they notice something is terrible going wrong on WMF side and too less is done to fix those problems/issues! if the community was not so willing to use force (ie a js hack) against the other party instead of talking properly then the superprotect wouldn't exist at all you seeing the problem there? whose problem is it? desire to act out of the blue instead of collaborating they didn't collaborate at all they added the js hack as if it was something urgent, that needs saving people from i would only do this if someone added a virus into mv by mistake this community thinks that its power structures allow to tromp onto other people ___ 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
2014-08-13 2:46 GMT+02:00 svetlana svetl...@fastmail.com.au: On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote: That the community reacts the way it does now, is because they care very much about the site and they notice something is terrible going wrong on WMF side and too less is done to fix those problems/issues! if the community was not so willing to use force (ie a js hack) against the other party You miss a very important thing here: the community does not want to use such measure at all, but is forced to this by the inappropriate behaviour of some WMF staff. The community gets the feeling that it isn't listened to, while it has serious points and considerations which are stepped over too lightly. And as I said before, we are all on the same ship. Sure a captain must make decisions, but if parts have serious comments, issues, and critics, such should not be ignored. instead of talking properly then the superprotect wouldn't exist at all you seeing the problem there? whose problem is it? desire to act out of the blue instead of collaborating they didn't collaborate at all they added the js hack as if it was something urgent, that needs saving people from i would only do this if someone added a virus into mv by mistake this community thinks that its power structures allow to tromp onto other people I do not think the community thinks that way. Members of the community can make mistake and staff members of WMF can make mistakes, I think that both that community and WMF are grown up enough to correct mistakes if they arise. Certainly inside the community are many critical people who watch these kind of things carefully and do correct those things when a mistake is made. The German community did collaborate, did communicate. Having a voting is a desperate way of getting the attention of the big problems WMF has too little insight in apparently. The community does not think in power structures, WMF does. Just as in 2013, again the problems start inside WMF and not in the community, and the community reacts on it. Romaine ___ 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 Mon, 11 Aug 2014, at 08:42, Tomasz W. Kozłowski wrote: Someone is definitely forgetting that Wikimedia wikis are not the Foundation's personal playground. It is becoming one for a long time now. 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
Erik, I wonder, did you have discussion with other staff and moreso, the technical staff before you went ahead and implemented this and also something most of us are wondering, just because dewiki did not accept your enforcement of MediaViewer, did you abuse your authority and force the technical staff to create this new permission (superprotect) so that you can override a community's decision..a permission which currently only the staff have access to? Seems a bit dictator-like... your comments above is just not reasonable enough.. On 8/11/14, svetlana svetl...@fastmail.com.au wrote: On Mon, 11 Aug 2014, at 08:42, Tomasz W. Kozłowski wrote: Someone is definitely forgetting that Wikimedia wikis are not the Foundation's personal playground. It is becoming one for a long time now. 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 -- Cometstyles ___ 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 Tue, Aug 12, 2014 at 12:18 AM, Brian Wolff bawo...@gmail.com wrote: Now, having observed that not only user Eloquence (aka Erik Moeller) himself engaged in the enforcement of superprotect right on de.wp [1] but soon after a workaround was published a change was deployed [2, 3] as counter measurement to block any possible interference can no longer be interpret as acting in good faith but rather strikes me as a form of oppression (or worst as censorship). [Putting the purely mw dev hat on] It was a bug in mediawiki, and thus it should be fixed. MediaWiki is used by many different groups and in general we [mw devs] do not judge people for how they use the software. If some non wmf entity reported the bug, it would still be fixed. So dont complain that mw fixes a bug in how page protection. If you are unhappy with current events you should direct your anger at how the wmf decided to use hard security to enforce its dictates, not at the software for working. Sorry Brian, which bug are you referring to? Could you point me to a bug report? Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page. Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'. Moreover the deployed technical change is useless due to design flaws. What was the goal of this change? Was it to prevent sysops injecting JavaScript that logged out user-agents execute? If that is the use-case, this patch is a very weak solution from an engineering perspective. It was rushed it into a production environment, and needed a follow up patch almost immediately. And the bug reports for this new functionality will surely roll in. These patches only make it 'forbidden' to deactivate the MediaViewer. They don't prevent it. These patches only introduce a new policy, signalling a new era, and make it technically more challenging to bypass that new policy. The policy written says Sysops are not allowed to inject JavaScript into the reader's user-agent which interferes with WMF's favoured features. It is still possible, but the only thing that is stopping de.wp sysops from deactivating the MediaViewer some other way is that the WMF has demonstrated it will make drastic changes to the MediaWiki configuration to take away capabilities from their community. Should the community work-around this change, they are fairly confident that the WMF will desysop whoeverdoes it, or more configuration changes and superprotection will occur. -- 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
And what happens when said admin is overwhelmingly reelected by the community? This is not the way forward. WMF can't continue to treat its volunteers in this manner. On Aug 11, 2014 12:01 PM, John Mark Vandenberg jay...@gmail.com wrote: On Tue, Aug 12, 2014 at 12:18 AM, Brian Wolff bawo...@gmail.com wrote: Now, having observed that not only user Eloquence (aka Erik Moeller) himself engaged in the enforcement of superprotect right on de.wp [1] but soon after a workaround was published a change was deployed [2, 3] as counter measurement to block any possible interference can no longer be interpret as acting in good faith but rather strikes me as a form of oppression (or worst as censorship). [Putting the purely mw dev hat on] It was a bug in mediawiki, and thus it should be fixed. MediaWiki is used by many different groups and in general we [mw devs] do not judge people for how they use the software. If some non wmf entity reported the bug, it would still be fixed. So dont complain that mw fixes a bug in how page protection. If you are unhappy with current events you should direct your anger at how the wmf decided to use hard security to enforce its dictates, not at the software for working. Sorry Brian, which bug are you referring to? Could you point me to a bug report? Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page. Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'. Moreover the deployed technical change is useless due to design flaws. What was the goal of this change? Was it to prevent sysops injecting JavaScript that logged out user-agents execute? If that is the use-case, this patch is a very weak solution from an engineering perspective. It was rushed it into a production environment, and needed a follow up patch almost immediately. And the bug reports for this new functionality will surely roll in. These patches only make it 'forbidden' to deactivate the MediaViewer. They don't prevent it. These patches only introduce a new policy, signalling a new era, and make it technically more challenging to bypass that new policy. The policy written says Sysops are not allowed to inject JavaScript into the reader's user-agent which interferes with WMF's favoured features. It is still possible, but the only thing that is stopping de.wp sysops from deactivating the MediaViewer some other way is that the WMF has demonstrated it will make drastic changes to the MediaWiki configuration to take away capabilities from their community. Should the community work-around this change, they are fairly confident that the WMF will desysop whoeverdoes it, or more configuration changes and superprotection will occur. -- 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
On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jay...@gmail.com wrote: Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page. This is false. Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'. Most of what MZMcBride posted there has nothing to do with actually breaking superprotection. Editing a page that isn't superprotected isn't a break in the protection feature itself, for example. Nor is hacking people's accounts. -- Brad Jorsch (Anomie) Software Engineer 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] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Tue, Aug 12, 2014 at 3:49 AM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jay...@gmail.com wrote: Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page. This is false. Care to explain? Was this functionality was ever supported by MediaWiki core? Could you point me towards some documentation? Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'. Most of what MZMcBride posted there has nothing to do with actually breaking superprotection. Editing a page that isn't superprotected isn't a break in the protection feature itself, for example. Of course it is. It isnt a 'feature' until it actually works at the released product level. Rushing component level hardening changes into production, when everyone knows how to work around the new 'hardened' code, it very bad change management. It likely introduces unforeseen bugs, for no actual gain. -- 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
Hi folks, Admins are currently given broad leeway to customize the user experience for all users, including addition of site-wide JS, CSS, etc. These are important capabilities of the wiki that have been used for many clearly beneficial purposes. In the long run, we will want to apply a code review process to these changes as with any other deployed code, but for now the system works as it is and we have no intent to remove this capability. However, we've clarified in a number of venues that use of the MediaWiki: namespace to disable site features is unacceptable. If such a conflict arises, we're prepared to revoke permissions if required. This protection level provides an additional path to manage these situations by preventing edits to the relevant pages (we're happy to help apply any urgent edits) until a particular situation has calmed down. Thanks, Erik -- 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] [Wikitech-l] Superprotect user right, Comming to a wiki near you
Hi Erik, I understand you reasoning, but you couldn't have communicated and timed this in a worse way. You might be doing the right thing, but because of this ill communication and timing, this will be completely overshadowed. That saddens me. Good luck with the shit storm :-( Maarten Erik Moeller schreef op 10-8-2014 14:27: Hi folks, Admins are currently given broad leeway to customize the user experience for all users, including addition of site-wide JS, CSS, etc. These are important capabilities of the wiki that have been used for many clearly beneficial purposes. In the long run, we will want to apply a code review process to these changes as with any other deployed code, but for now the system works as it is and we have no intent to remove this capability. However, we've clarified in a number of venues that use of the MediaWiki: namespace to disable site features is unacceptable. If such a conflict arises, we're prepared to revoke permissions if required. This protection level provides an additional path to manage these situations by preventing edits to the relevant pages (we're happy to help apply any urgent edits) until a particular situation has calmed down. Thanks, Erik ___ 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 Moeller wrote: Admins are currently given broad leeway to customize the user experience for all users, including addition of site-wide JS, CSS, etc. These are important capabilities of the wiki that have been used for many clearly beneficial purposes. In the long run, we will want to apply a code review process to these changes as with any other deployed code, but for now the system works as it is and we have no intent to remove this capability. However, we've clarified in a number of venues that use of the MediaWiki: namespace to disable site features is unacceptable. If such a conflict arises, we're prepared to revoke permissions if required. This protection level provides an additional path to manage these situations by preventing edits to the relevant pages (we're happy to help apply any urgent edits) until a particular situation has calmed down. Let's be clear here. You unilaterally implemented super-protection and then had a Community Advocate apply this new protection level to the German Wikipedia's MediaWiki:Common.js? You'd been threatening to implement super-protection for a long time. I see you finally made good on this very bad idea. This is certainly bold, but also incredibly reckless. Your response to being told we don't like your software is to try shove it down a wiki community's throat? The German Wikipedia can easily use MediaWiki:Vector.js or an on-by-default JavaScript gadget to implement this change. The German Wikipedia can also block Jan Eissfeldt's account for conduct unbecoming of an administrator. In my opinion, it also wouldn't be unreasonable for the stewards to remove Jan Eissfeldt's capability to protect this page. MZMcBride ___ 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 10 August 2014 15:51, MZMcBride z...@mzmcbride.com wrote: You'd been threatening to implement super-protection for a long time. I see you finally made good on this very bad idea. This is certainly bold, but also incredibly reckless. Your response to being told we don't like your software is to try shove it down a wiki community's throat? I thought this was a response to someone hamfistedly editing en:wp's JS and *actually breaking it*. When Erik reverted this change and said don't break the damn wiki, the response was but we can so we should be able to! and an attempt to take the Foundation to en:wp arbitration. The obvious response is to make it so that such blithering stupidity can't be enacted again. - 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
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
David Gerard wrote: On 10 August 2014 15:51, MZMcBride z...@mzmcbride.com wrote: You'd been threatening to implement super-protection for a long time. I see you finally made good on this very bad idea. This is certainly bold, but also incredibly reckless. Your response to being told we don't like your software is to try shove it down a wiki community's throat? I thought this was a response to someone hamfistedly editing en:wp's JS and *actually breaking it*. When Erik reverted this change and said don't break the damn wiki, the response was but we can so we should be able to! and an attempt to take the Foundation to en:wp arbitration. The obvious response is to make it so that such blithering stupidity can't be enacted again. Super-protection was implemented in response to the German, not English, Wikipedia. It turns out that multiple communities don't like MediaViewer. Erik is squarely responsible for the mess being made here and deserves the full blame and consequences. He instigated the arbitration case on the English Wikipedia and he's now instigating a war with the German Wikipedia. The German Wikipedia community has looked at and evaluated MediaViewer and has decided that it doesn't want MediaViewer enabled on its wiki. Erik has made it his mission to force MediaViewer on the German Wikipedians (and the Commoners), using system administrators and community advocates and anyone else he can coerce. This is unacceptable behavior on Erik's part. MediaViewer is an entirely supplementary feature, not some fundamental or critical piece of infrastructure in desperate need of protection. MZMcBride ___ 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 10 August 2014 16:08, MZMcBride z...@mzmcbride.com wrote: He instigated the arbitration case on the English Wikipedia That's *definitely* a claim needing actual evidence, considering he didn't bring it. I assume you can produce something. - 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
Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you
On Sun, Aug 10, 2014 at 10:08 PM, MZMcBride z...@mzmcbride.com wrote: David Gerard wrote: On 10 August 2014 15:51, MZMcBride z...@mzmcbride.com wrote: You'd been threatening to implement super-protection for a long time. I see you finally made good on this very bad idea. This is certainly bold, but also incredibly reckless. Your response to being told we don't like your software is to try shove it down a wiki community's throat? I thought this was a response to someone hamfistedly editing en:wp's JS and *actually breaking it*. When Erik reverted this change and said don't break the damn wiki, the response was but we can so we should be able to! and an attempt to take the Foundation to en:wp arbitration. The obvious response is to make it so that such blithering stupidity can't be enacted again. Super-protection was implemented in response to the German, not English, Wikipedia. It turns out that multiple communities don't like MediaViewer. Erik is squarely responsible for the mess being made here and deserves the full blame and consequences. He instigated the arbitration case on the English Wikipedia and he's now instigating a war with the German Wikipedia. The German Wikipedia community has looked at and evaluated MediaViewer and has decided that it doesn't want MediaViewer enabled on its wiki. Erik has made it his mission to force MediaViewer on the German Wikipedians (and the Commoners), using system administrators and community advocates and anyone else he can coerce. This is unacceptable behavior on Erik's part. MediaViewer is an entirely supplementary feature, not some fundamental or critical piece of infrastructure in desperate need of protection. As this has wide-ranging implications, I have started an RFC on meta https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotect_rights -- 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
On Sun, Aug 10, 2014 at 3:27 PM, Erik Moeller e...@wikimedia.org wrote: Hi folks, Admins are currently given broad leeway to customize the user experience for all users, including addition of site-wide JS, CSS, etc. These are important capabilities of the wiki that have been used for many clearly beneficial purposes. In the long run, we will want to apply a code review process to these changes as with any other deployed code, but for now the system works as it is and we have no intent to remove this capability. However, we've clarified in a number of venues that use of the MediaWiki: namespace to disable site features is unacceptable. If such a conflict arises, we're prepared to revoke permissions if required. This protection level provides an additional path to manage these situations by preventing edits to the relevant pages (we're happy to help apply any urgent edits) until a particular situation has calmed down. erik, this was designed so, and worked well exactly like this. administrators are voted, and there are hundreds which work together. if it is wise process to review a change by another administrator implement it like this. that has to be enough. it worked well 5 years ago when we had most new editors joining. if you cannot convince the admins about a change, there is strong evidence that something else is wrong - not the user rights. rupert ___ 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
This is, by far, the most disgusting and disrespectful action undertaken by the Foundation that I have ever witnessed. The 2012 mass desysopping of volunteer administrators on the WMF wiki and the past threats of desysopping users re: VisualEditor and MediaViewer do not even come close to this. It is clear to me that the Foundation has agreed on this sneaky change behind closed doors while some of the most outspoken Wikimedia volunteers were (and still are) gathered in London. This is not the first time that we're seeing this happpen, and it is clear to me that the Foundation has lost all remaining moral authority to talk about transparency and involving volunteers in the decision-making process. Erik has forced his employees, including a so-called community advocacy liaison, to use this opportunity to actively fight the volunteer community of the German Wikipedia. He himself has engaged in a wheel war over this, and continues to shove MediaViewer down the German Wikipedia's community throat. I'm not sure what was the purpose of this change, but if its aim was to escalate the already tense situation between the WMF and its volunteer communities regarding MediaViewer, protecting the MediaWiki:Common.js page so that no one can edit it was the perfect choice. This action will cause a huge shitstorm, and Erik deserves every bit of shit and mud that will be thrown his way. You can force anything you like on your employees, but you cannot force the volunteer community to do what you want, not in a manner like this. Remember that in the end, the community can exist without the WMF, but there is no WMF without the community. -- Tomasz ___ 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
It is clear to me that the Foundation has agreed on this sneaky change behind closed doors while some of the most outspoken Wikimedia volunteers were (and still are) gathered in London. It's interesting you mention Wikimania, because one of the things I took away from the conference was the idea that if Wikimedia sites keep on looking and acting like they did in 2004, we'll get left behind by the rest of the internet Chris ___ 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 Sun, Aug 10, 2014 at 6:29 PM, John Mark Vandenberg jay...@gmail.com wrote: As this has wide-ranging implications, I have started an RFC on meta https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotect_rights With that done, I'd like to ask that discussion on this topic be continued there. Not that this isn't an appropriate forum for the issue to be raised, because it obviously is, but a public, transparent, and permanently documented RfC seems like a better place for it than the inboxes of this select few. Austin ___ 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
The show must go on. To ensure that no German Wikipedia administrator deletes MediaWiki:Common.js to cancel the super-protection, the WMF has just merged https://gerrit.wikimedia.org/r/#/c/153345/ and deployed it to Wikimedia wikis as a matter of emergency after a personal request from Erik Moller. Someone is definitely forgetting that Wikimedia wikis are not the Foundation's personal playground. You should be ashamed of yourself, Erik, and you should resign or be fired. And all volunteers should make sure to remember who was involved in deploying those shameful patches to Wikimedia wikis without consulting anything with the people who actually matter -- the community. Tomasz ___ 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 Sun, Aug 10, 2014 at 11:42 PM, Tomasz W. Kozłowski twkozlow...@gmail.com wrote: Someone is definitely forgetting that Wikimedia wikis are not the Foundation's personal playground. You should be ashamed of yourself, Erik, and you should resign or be fired. And all volunteers should make sure to remember who was involved in deploying those shameful patches to Wikimedia wikis without consulting anything with the people who actually matter -- the community. Tomasz, While I appreciate your indignation, this is absolutely not the tone appropriate for the list, nor is it one likely to effect your desired outcome. Please be civil, and consider commenting on the RfC rather than making personal attacks and veiled threats on this mailing list. Austin ___ 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
