Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On Aug 31, 2014 11:46 PM, Pine W wiki.p...@gmail.com wrote: Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for the projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead of feuding, and I'm getting MediaViewer issue fatigue. WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make global decisions on a consensus basis. Pine I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different projects, and frankly, I'm not buying it, unless the setting is intended to be removed completely. Could someone explain to me how having a different default state for the setting has much, or any, impact? - Martijn ___ 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] Next steps regarding WMF-community disputes about deployments
Hoi, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default on or off is not relevant really. When you read the Wikipedia Signpost you read about one of the major German players and it is found necessary to mention that his tools environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that. Consequently my conclusion that it is not about the MediaViewer at all. The next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM On 1 September 2014 08:11, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Aug 31, 2014 11:46 PM, Pine W wiki.p...@gmail.com wrote: Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for the projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead of feuding, and I'm getting MediaViewer issue fatigue. WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make global decisions on a consensus basis. Pine I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different projects, and frankly, I'm not buying it, unless the setting is intended to be removed completely. Could someone explain to me how having a different default state for the setting has much, or any, impact? - Martijn ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
The difficulty of working with multiple configurations is one of WMF's main points, along with its opinion that readers prefer MV and that WMF should prioritize what WMF feels the readers want. WMF also is making a point of claiming soveriegnty over software configuration. Meanwhile, many volunteers seem to view readership numbers as adequate with the status quo, do not believe that MV adds value, disagree with the design of Media Viewer, and are angered by WMF's undemocratic conduct and arrogant comments. This kind of situation is unlikely to have a happy ending without some concessions and mediation. Pine On Aug 31, 2014 11:32 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default on or off is not relevant really. When you read the Wikipedia Signpost you read about one of the major German players and it is found necessary to mention that his tools environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that. Consequently my conclusion that it is not about the MediaViewer at all. The next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM On 1 September 2014 08:11, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Aug 31, 2014 11:46 PM, Pine W wiki.p...@gmail.com wrote: Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for the projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead of feuding, and I'm getting MediaViewer issue fatigue. WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make global decisions on a consensus basis. Pine I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different projects, and frankly, I'm not buying it, unless the setting is intended to be removed completely. Could someone explain to me how having a different default state for the setting has much, or any, impact? - Martijn ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ 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] Next steps regarding WMF-community disputes about deployments
I think you've hit the nail on the head here. It's not about MediaViewer at all, it's about two things: #1: The frustration of some volunteers that they feel their views are not being adequately considered in major deployments of new software. #2: A lack of confidence and faith in the WMF Engineering team to deliver quality software. The second is the more dangerous one at this point. After the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left. The technical problems with MediaViewer were not as serious, but since a significant portion of the power user base was expecting a failure, they jumped on the flaws that it did have, and here we are. To be honest, if Erik were to turn water into wine at this point, people would still complain, and loudly, that he had provided them with red when they wanted white. I'm not sure that the solutions that have been offered; a new deployment process, or a tech council, are going to be sufficient to correct the real problem, which at this point is largely one of perception. Similarly, I don't think that the WMF adopting a complete hands-off approach as some seem to be demanding is going to lead to anything other than stagnation as individual communities squabble indecisively over what changes should be made. I do know that if it's not fixed, that pretty much every major deployment of new features is going to follow this same pattern, which is obviously highly undesirable. What I'd suggest is that we leave the emotional hostility at the door and try to be reasonable. Neither side is going to get exactly what they want, and that is to be expected. To be honest, some of the invective that has been directed at Foundation staff has been completely over the top; phrases like Taliban diplomacy or honest-to-god comparisons to the Nazis don't move us towards a solution or make one seem like someone that can be intelligently reasoned with, they only harden feelings on both sides and make a suitable arrangement being found less likely. No employee should be made to receive that sort of harassment in the course of their job, no matter how much you disagree with them. Cheers, Craig Franklin On 1 September 2014 16:31, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default on or off is not relevant really. When you read the Wikipedia Signpost you read about one of the major German players and it is found necessary to mention that his tools environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that. Consequently my conclusion that it is not about the MediaViewer at all. The next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM On 1 September 2014 08:11, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Aug 31, 2014 11:46 PM, Pine W wiki.p...@gmail.com wrote: Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for the projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead of feuding, and I'm getting MediaViewer issue fatigue. WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make global decisions on a consensus basis. Pine I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different projects, and frankly, I'm not buying it, unless the setting is intended to be removed completely. Could someone explain to me how having a different default state for the setting has much, or any, impact? - Martijn ___ 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:
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Warning, tl;dr rant below in which live my personal opinion. On 09/01/2014 08:00 AM, Craig Franklin wrote: fter the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left. That /was/ a bad botch; and (IMO) the reason why that happened is that someone set a hard deploy date that should never have been set in stone and then held to it even though VE was clearly not ready. (It is *now* at a point with rollout would have been plausible). Clearly nobody at WMF Engineering is going to do *that* again. But I also don't think that was causative in any way; the tension between WMF holding the reins to the servers and (part of) the communities was the same years before that. ACCTRIAL anyone? The fundamental issue is that the WMF is attempting to provide some direction, and the communities do not want any (for various and divergent reasons). I side with the WMF in this; not because they sign my paycheck (I'm in Ops - I have zero to do with dev work) but because I've been a Wikipedian for 10 years and I *see* that the communities have no capacity for change - or that what little change manages to gather micro-consensus is local and often shortsighted. The projects are directionless, and it shows in the increasing stagnation and calcification. Are all the attempts by the WMF at providing direction successes? Not even close. Some of the things they tried ranged from merely misguided to downright daft (also IMO, obviously). The process *does* need community engagement. That'd seriously increases the value of what (and how) the WMF does things, and likely reduce the number of bad ideas from the outset. But the community engagement it needs is one that is done in good faith; something which I have yet to see more than exceptions here and there. It also needs fewer reactionnary hotheads. Editing sucks. Reading is lacking. Most of the tooling is crap. That X editors have gotten used to it and have implemented piles of workarounds doesn't justify keeping the old shit around. MV is a perfect example. 99% of the problems it objectively has (we ignore here matters of taste) derive from the difficulty of parsing the multitude overcomplicated templates living on File: pages to work around the fact that a wikitext page is complete and utter crap at storing metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV. How is it that the old saying goes? 'We've always done things this way' is the most dangerous statement in any language? -- 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] Next steps regarding WMF-community disputes about deployments
On 01/09/2014, Marc A. Pelletier m...@uberbox.org wrote: ... metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV. ... So, can you link me to a positive proposal to do the elemental foundation of this, and point to a realistic (and Foundation supported) proposal to the community to standardize licence templates on Commons? Do this and you are most of the way there. As someone who has uploaded 400,000 images to Commons with a variety of licences, I would welcome this proposal rather than doing it the wrong way around. Right now a rationale of blaming underpinning infrastructure not being ready for MV, after rolling it out, looks like setting your house on fire in order to give your husband sufficient motivation to check the smoke alarm. Fae -- fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae ___ 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] Next steps regarding WMF-community disputes about deployments
On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier m...@uberbox.org wrote: Warning, tl;dr rant below in which live my personal opinion. On 09/01/2014 08:00 AM, Craig Franklin wrote: fter the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left. That /was/ a bad botch; and (IMO) the reason why that happened is that someone set a hard deploy date that should never have been set in stone and then held to it even though VE was clearly not ready. (It is *now* at a point with rollout would have been plausible). Clearly nobody at WMF Engineering is going to do *that* again. We've heard that before. But I also don't think that was causative in any way; the tension between WMF holding the reins to the servers and (part of) the communities was the same years before that. ACCTRIAL anyone? Sure, for reasons I'll get to below. That contradicts the rest of what you said here. The fundamental issue is that the WMF is attempting to provide some direction, and the communities do not want any (for various and divergent reasons). I don't think it's that the communities don't want any direction. It's that large, open projects historically managed by their volunteers are not amenable to top-down, authoritarian direction. All that will do is start fights, to the detriment of everyone and especially to the detriment of said projects. None of us are out a paycheck if we scale back our activity or walk away in disgust. I side with the WMF in this; not because they sign my paycheck (I'm in Ops - I have zero to do with dev work) but because I've been a Wikipedian for 10 years and I *see* that the communities have no capacity for change - or that what little change manages to gather micro-consensus is local and often shortsighted. The projects are directionless, and it shows in the increasing stagnation and calcification. That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said Nah, rather not. When treated that way, do you think the community has much appetite to continue discussing necessary changes when the last time was a significant effort ultimately ending in futility, not because of a failure on the community's part, but because of WMF's refusal to listen? Are all the attempts by the WMF at providing direction successes? Not even close. Some of the things they tried ranged from merely misguided to downright daft (also IMO, obviously). The process *does* need community engagement. That'd seriously increases the value of what (and how) the WMF does things, and likely reduce the number of bad ideas from the outset. As above, that's not going to happen if that engagement continues to result in brushoffs. Look at Flow. One overwhelming message is We don't want it at all (and that demands real consideration, not dismissive comments about resistance to change and power users), but when asked what could at least make it better, the answers of Preserve ability for anyone to refactor posts as needed, don't restrict to admins and Don't limit indentation have fallen on deaf ears. Again, if there's no one listening, people are not going to continue talking to what by all appearances is a brick wall. But the community engagement it needs is one that is done in good faith; something which I have yet to see more than exceptions here and there. It also needs fewer reactionnary hotheads. Editing sucks. Reading is lacking. Most of the tooling is crap. That X editors have gotten used to it and have implemented piles of workarounds doesn't justify keeping the old shit around. Maybe. I don't really think it's crap. Reflinks wasn't crap. That doesn't mean we can't do better, but we need to do actually better, not just We need to do something, this is something, so do it! Regardless, same again: That needs to be met with good faith on the other side, to stop just plowing ahead when everyone's saying WAIT, there's serious problems here!. Engagement doesn't work if it's the classic suggestions box positioned directly over a garbage can. MV is a perfect example. 99% of the problems it objectively has (we ignore here matters of taste) derive from the difficulty of parsing the multitude overcomplicated templates living on File: pages to work around the fact that a wikitext page is complete and utter crap at storing metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV. How is it that the old saying goes? 'We've always done things this way' is the most dangerous statement in any
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On 09/01/2014 11:45 AM, Todd Allen wrote: On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier m...@uberbox.org wrote: We've heard that before. Oh, I'm pretty damn sure that the stick to the timeline idea isn't going to get traction ever again. :-) But yeah in general recognizing an error is not, in itself, proof against repeating it. Errare humanum est. I don't think it's that the communities don't want any direction. It's that large, open projects historically managed by their volunteers are not amenable to top-down, authoritarian direction. All that will do is start fights, to the detriment of everyone and especially to the detriment of said projects. None of us are out a paycheck if we scale back our activity or walk away in disgust. There's that, but there's also the (unavoidable) issue that Wikipedia was revolutionnary, so it attracted a great deal of people who had little to no desire to abide The Man. The problem is we /are/ The Man now. That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said Nah, rather not. That, IMO, is an example of what I call a shortsighted change. It *might* have been a good local change, in the end, but it nevertheless was a fundamental dent in the project values in order to solve an extremely local problem. If I were the Foundation back then I probably also would have refused to proceed without Licence-change-level consensus and a long consultation process - at the very least. Like or not, the Foundation is in the odd position of being the guardian of the Big Picture; local projects are exactly that - local. What may be a good local change may turn out to be globally disastrous (because divergence, precedent, etc). But that's getting into a discussion of federalism as a concept (and whether the projects are de facto federated) which may be interesting in itself but is way wy off-topic. :-) Regardless, same again: That needs to be met with good faith on the other side, to stop just plowing ahead when everyone's saying WAIT, there's serious problems here!. Engagement doesn't work if it's the classic suggestions box positioned directly over a garbage can. I don't think that's true. At least, from my privileged position (where I see much of the internal dev chatter from the sidelines) that has never seemed to be the case. Change for the sake of change can easily be as dangerous. That's true, to a point, but I can say with quite a bit of confidence that nobody at the Foundation ever said Let's change this without a solid This seems to be an improvement because behind it (or, at the very least Y is demonstrably broken, we don't know what's the best way to fix it, let's try Z. They may be *wrong*; but every bit of development I've seen is based on a rational desire to improve and from reasonable assumptions about what will be an improvement. And, honestly, it's better to try and possibly fail to fix than it is to avoid trying and definitely stay broken. -- 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] Next steps regarding WMF-community disputes about deployments
On Sep 1, 2014 5:10 PM, Marc A. Pelletier m...@uberbox.org wrote: Warning, tl;dr rant below in which live my personal opinion. Thank you for that. A heartfelt rant feels a lot better than being told my call is important to you. (snip) The fundamental issue is that the WMF is attempting to provide some direction, and the communities do not want any (for various and divergent reasons). I don't really have all that much of a problem with direction. I have a problem though with strong arming change, which is snap happened here. (snip) The process *does* need community engagement. That'd seriously increases the value of what (and how) the WMF does things, and likely reduce the number of bad ideas from the outset. But the community engagement it needs is one that is done in good faith; Yes, from both sides. The flow example cited in another email shows this well. There is a large contingent of thank you for your concern. We won't do that because we believe x rather than y, effectively closing discussion. That's not a great atmosphere to share ideas in. Another frequent problem is saying in the early stages not to worry, it's only the early stages, and all that will be fixed, just come back in a few months, and you'll see how great it'll be, and when it isn't say that earlier feedback would have helped, but nobody showed interest in the early stages. something which I have yet to see more than exceptions here and there. It also needs fewer reactionnary hotheads. Editing sucks. Reading is lacking. Most of the tooling is crap. That X editors have gotten used to it and have implemented piles of workarounds doesn't justify keeping the old shit around. MV is a perfect example. 99% of the problems it objectively has (we ignore here matters of taste) derive from the difficulty of parsing the multitude overcomplicated templates living on File: pages to work around the fact that a wikitext page is complete and utter crap at storing metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. Yes! This must be said more often! The *correct* solution is to fix the damn image pages, not to remove MV. The *correct* solution is to make MV bail completely on pages it fails to parse, falling back to the known bad-but-sufficient behaviour, and maybe adding a hidden category unparsable by MV to the image, so that it can be addressed. If 10% of the effort spent on the long tail of template madness was spent on implementing when in doubt, bail much debate would have been unnecessary. Doing the right thing 90% of the time and nothing 10% of the time is preferable over doing the right thing 98 % of the time and the wrong thing 2%. The same, by the way, goes for VE, which should have had bail and give me what you have now as wikitext from the onset, and Flow which needs a bail and convert this thread to ye olde talkpage thread (which I fear will be batted away as reactionary crank talk, and by the time flow will be done unneeded anyway) -- Martijn How is it that the old saying goes? 'We've always done things this way' is the most dangerous statement in any language? -- 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] Next steps regarding WMF-community disputes about deployments
On 1 September 2014 17:57, Martijn Hoekstra martijnhoeks...@gmail.com wrote: The same, by the way, goes for VE, which should have had bail and give me what you have now as wikitext from the onset, and Flow which needs a bail and convert this thread to ye olde talkpage thread (which I fear will be batted away as reactionary crank talk, and by the time flow will be done unneeded anyway) By the way: Is Flow going to support the use case of cut'n'pasting a piece from the article page to the talk page, as a lump of wikitext or as a piece of rich text from VE? 'Cos if it doesn't, I predict that will be the sticking point with the people who actually communicate on talk pages. - 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] Next steps regarding WMF-community disputes about deployments
On 09/01/2014 12:57 PM, Martijn Hoekstra wrote: The *correct* solution is to make MV bail completely on pages it fails to parse, falling back to the known bad-but-sufficient behaviour, and maybe adding a hidden category unparsable by MV to the image, so that it can be addressed. If 10% of the effort spent on the long tail of template madness was spent on implementing when in doubt, bail much debate would have been unnecessary. I don't think it's necessarily easy to even /detect/ that there is something important that couldn't be parsed right; but this makes sense to me indeed in principle. -- 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] Next steps regarding WMF-community disputes about deployments
No employee should be made to receive that sort of harassment in the course of their job, no matter how much you disagree with them. How did it come to be part of Erik's job to create superprotect and attempt to force the community to accept it? As the WMF is defined in its mission statement, its purpose is to empower and enable the community to create the projects. Somehow disabling the community came to be seen as legitimate. Erik was, we suspect, highly involved in that, but really this is between Erik and his management. The wiki communities often harass unpopular messengers. This isn't just about Erik, it's about how wikis function, and unless the WMF manages to facilitate clearer and more efficient and more reliable community process, it's very likely to stay that way, because these kinds of community characteristics are self-reinforcing, since anything else is driven away. Solutions are prohibited, crushed immediately. The real issue in this affair, as many have noted, was not MediaViewer, it was about power and control, which are survival issues, instinctive for human beings. Anyone who was surprised by the intensity of the response doesn't know human beings. Not surprising, I suppose, for software people. But shocking for the WMF as a whole, so I'm hoping that there is some real soul-searching in the WMF offices. This was *entirely predictable.* Abd ul-Rahman Lomax (413) 584-3151 business (413) 695-7114 cell I'm so excited I can't wait for Now. From: Craig Franklin cfrank...@halonetwork.net To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Sent: Monday, September 1, 2014 8:00 AM Subject: Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments I think you've hit the nail on the head here. It's not about MediaViewer at all, it's about two things: #1: The frustration of some volunteers that they feel their views are not being adequately considered in major deployments of new software. #2: A lack of confidence and faith in the WMF Engineering team to deliver quality software. The second is the more dangerous one at this point. After the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left. The technical problems with MediaViewer were not as serious, but since a significant portion of the power user base was expecting a failure, they jumped on the flaws that it did have, and here we are. To be honest, if Erik were to turn water into wine at this point, people would still complain, and loudly, that he had provided them with red when they wanted white. I'm not sure that the solutions that have been offered; a new deployment process, or a tech council, are going to be sufficient to correct the real problem, which at this point is largely one of perception. Similarly, I don't think that the WMF adopting a complete hands-off approach as some seem to be demanding is going to lead to anything other than stagnation as individual communities squabble indecisively over what changes should be made. I do know that if it's not fixed, that pretty much every major deployment of new features is going to follow this same pattern, which is obviously highly undesirable. What I'd suggest is that we leave the emotional hostility at the door and try to be reasonable. Neither side is going to get exactly what they want, and that is to be expected. To be honest, some of the invective that has been directed at Foundation staff has been completely over the top; phrases like Taliban diplomacy or honest-to-god comparisons to the Nazis don't move us towards a solution or make one seem like someone that can be intelligently reasoned with, they only harden feelings on both sides and make a suitable arrangement being found less likely. No employee should be made to receive that sort of harassment in the course of their job, no matter how much you disagree with them. Cheers, Craig Franklin ___ 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] Next steps regarding WMF-community disputes about deployments
Yes, it is emotions that speak, though emotions are often concealed beneath arguments. Basic human psychology. Any attempt to ascribe this affair to sour grapes from a disgruntled software developer is looking at a bush in the forest and not the massive collection of trees. No, it's about basic survival issues, it's called avoiding domination, a nearly universal trait that appears to be instinctive. There are *also* rational issues, but it was not reason that led the WMF to, in a rush, create and impose superprotect, and it was not reason that led to all the extreme comments from the community. We don't expect the community to be reasonable, as to every comment, but we do have higher expectations of people employed to serve us. It is likely, to me, that the root problem here was a new ED, who believed that her mission was to create a better experience for *readers*, and, my guess, she was encouraged to believe that by some of the Staff. And, of course, as a skilled manager from software companies, she would support and rely on the Staff for advice. However, there is a higher master, always, the customers. Those who actually pay the bills. Who are they? Well, we could talk about the donors, but there is a much larger contributor to the WMF, and it contributes labor, not money. That labor makes the projects possible. Some thought that the superprotect decision was a deliberate attempt to shove the community away, to move toward bot maintenance, to kick the experienced users out the door. I don't think so. I think it was simply inept, though an inept decision that might be expected from an *experienced software company manager.* Who was not informed that the community is the actual customer, not the readers. Who, I assume, can learn. Abd ul-Rahman Lomax (413) 584-3151 business (413) 695-7114 cell I'm so excited I can't wait for Now. From: Gerard Meijssen gerard.meijs...@gmail.com To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org Sent: Monday, September 1, 2014 2:31 AM Subject: Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments Hoi, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default on or off is not relevant really. When you read the Wikipedia Signpost you read about one of the major German players and it is found necessary to mention that his tools environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that. Consequently my conclusion that it is not about the MediaViewer at all. The next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM On 1 September 2014 08:11, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Aug 31, 2014 11:46 PM, Pine W wiki.p...@gmail.com wrote: Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for the projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead of feuding, and I'm getting MediaViewer issue fatigue. WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make global decisions on a consensus basis. Pine I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different projects, and frankly, I'm not buying it, unless the setting is intended to be removed completely. Could someone explain to me how having a different default state for the setting has much, or any, impact? - Martijn ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Hoi, Dear Pine. I do not care a fig about what some users think. You either support their view or you do not. When they consider that the current number of readers is adequate, I want to appreciate what they think those numbers are, what the trends are and how it is possible that their opinion is so starkly different from the ones I know about. Readership is down on computers and the current numbers are only supported because of tablets and mobiles. The same thing can be said about new editors; they are mainly arriving from mobiles and tablets. Even old timers like myself loudly HATE the old crappy interface. So I am really displeased that you voice what some users think; as far as I am concerned it is weasel talk. You either support the voices of some users or you do not. When you do, say so and argue. Do not let it hang in the air as if it has nothing to do with you. Pine I know you know about research.. You know the numbers, you know how to get them where to ask. You do not have an excuse. Thanks, GerardM On 1 September 2014 09:34, Pine W wiki.p...@gmail.com wrote: The difficulty of working with multiple configurations is one of WMF's main points, along with its opinion that readers prefer MV and that WMF should prioritize what WMF feels the readers want. WMF also is making a point of claiming soveriegnty over software configuration. Meanwhile, many volunteers seem to view readership numbers as adequate with the status quo, do not believe that MV adds value, disagree with the design of Media Viewer, and are angered by WMF's undemocratic conduct and arrogant comments. This kind of situation is unlikely to have a happy ending without some concessions and mediation. Pine On Aug 31, 2014 11:32 PM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, The argument is not at all about the MediaViewer. It is only the latest flash point. Consequently the notion of how hard it is to set a default on or off is not relevant really. When you read the Wikipedia Signpost you read about one of the major German players and it is found necessary to mention that his tools environment was ended and it became WMF labs. For me it gives the impression of sour grapes and a sense of failure because volunteers do not decide the agenda and feel angry/frustrated about that. Consequently my conclusion that it is not about the MediaViewer at all. The next thing that comes along will be the next flash point. This is because it is emotions that speak and not arguments. Thanks, GerardM On 1 September 2014 08:11, Martijn Hoekstra martijnhoeks...@gmail.com wrote: On Aug 31, 2014 11:46 PM, Pine W wiki.p...@gmail.com wrote: Just in terms of the amount of everyone's time that MediaViewer, Superprotect and related issues are absorbing, this situation is a net negative for the projects. Also, the amount of emotional hostility that this situation involves is disheartening. Personally, I would like to see us building on each other's work instead of feuding, and I'm getting MediaViewer issue fatigue. WMF's principal argument against letting projects make local decisions about configurations of MediaViewer seems to be that having a multitude of site configurations is impractical for site maintainability and development of new features. The Technical Committee would be in a good position to make global decisions on a consensus basis. Pine I've heard the argument that it is difficult to maintain and develop for having different default states of this setting across different projects, and frankly, I'm not buying it, unless the setting is intended to be removed completely. Could someone explain to me how having a different default state for the setting has much, or any, impact? - Martijn ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Thank you very much, Marc, for this clear and sound statement. It seems to me that there are many discussions that are far away from the real points, like the multitude of information on our pages. I once counted how many links there are on the German main page of Wikimedia Commons, I stopped when I reached 170... By the way, I enjoyed your talk at Wikimania, and your enthousiasm about many tools - actually, tools that often help to overcome the downsides of our wiki pages. Kind regards Ziko 2014-09-01 17:10 GMT+02:00 Marc A. Pelletier m...@uberbox.org: Warning, tl;dr rant below in which live my personal opinion. On 09/01/2014 08:00 AM, Craig Franklin wrote: fter the catastrophic aborted launch of the Visual Editor, complete with numerous bugs that should have been picked up in even a cursory unit testing scheme or regression testing scheme prior to being deployed to a productive environment, there's not a good deal of faith left. That /was/ a bad botch; and (IMO) the reason why that happened is that someone set a hard deploy date that should never have been set in stone and then held to it even though VE was clearly not ready. (It is *now* at a point with rollout would have been plausible). Clearly nobody at WMF Engineering is going to do *that* again. But I also don't think that was causative in any way; the tension between WMF holding the reins to the servers and (part of) the communities was the same years before that. ACCTRIAL anyone? The fundamental issue is that the WMF is attempting to provide some direction, and the communities do not want any (for various and divergent reasons). I side with the WMF in this; not because they sign my paycheck (I'm in Ops - I have zero to do with dev work) but because I've been a Wikipedian for 10 years and I *see* that the communities have no capacity for change - or that what little change manages to gather micro-consensus is local and often shortsighted. The projects are directionless, and it shows in the increasing stagnation and calcification. Are all the attempts by the WMF at providing direction successes? Not even close. Some of the things they tried ranged from merely misguided to downright daft (also IMO, obviously). The process *does* need community engagement. That'd seriously increases the value of what (and how) the WMF does things, and likely reduce the number of bad ideas from the outset. But the community engagement it needs is one that is done in good faith; something which I have yet to see more than exceptions here and there. It also needs fewer reactionnary hotheads. Editing sucks. Reading is lacking. Most of the tooling is crap. That X editors have gotten used to it and have implemented piles of workarounds doesn't justify keeping the old shit around. MV is a perfect example. 99% of the problems it objectively has (we ignore here matters of taste) derive from the difficulty of parsing the multitude overcomplicated templates living on File: pages to work around the fact that a wikitext page is complete and utter crap at storing metadata. It's not an argument against MV, it's an argument for getting rid of the horrid way we handle File: pages with ad-hoc workarounds. The *correct* solution is to fix the damn image pages, not to remove MV. How is it that the old saying goes? 'We've always done things this way' is the most dangerous statement in any language? -- Marc ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l 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] Fwd: Wikimedia India Chapter: Current state of affairs
-- Forwarded message -- From: Jayanta Nath jaya...@wikimedia.in Date: Mon, Sep 1, 2014 at 10:45 PM Subject: Wikimedia India Chapter: Current state of affairs To: wmin-memb...@googlegroups.com Cc: Discussion list on Indian language projects of Wikimedia. wikimediaindi...@lists.wikimedia.org Dear Wikimedia India Chapter members and other interested stakeholders in the list, Dear members, The Executive committee of Wikimedia India has held an emergency teleconference on their official DSNL channel on 31 Aug 2014. As salient items on the agenda, the following topics were discussed and decided upon: 1. Earlier, Radhakrishna Arvapally, a senior chapter member and former Chair of Bangalore SIG, was co-opted by an emergency resolution. The resolution was passed unanimously. The resolution had also proposed another senior member. However, due to heavy personal engagements, the second nominee requested the EC to exempt from such considerations. Radhakrishna was invited to the telecon and was officially welcomed to be part of the EC. 2. Jayanta Nath, a senior Wikipedian from Kolkata and EC member, was unanimously elected as the new President of the Wikimedia India Chapter. Also, Radhakrishna Arvapally and Viswanathan Prabhakaran were elected as the new Secretary and Treasurer of the chapter respectively. 3. Any decision about hiring is kept on hold for now. The current EC agreed together that the opinion of the new EC (emerging through the upcoming general elections) should also be taken on-board for a major decision like this, since they are the ones to deal with the newly hired candidate(s)for a longer term. 4. Another extra ordinary EC Telecon was scheduled to be conducted tentatively on 02 September 2014, 9.00 PM to take up other urgent matters pending for decisions. This is for the general information for all chapter members and other interested stakeholders. Thank You, Jayanta Nath President Wikimedia India Chapter ___ 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] Next steps regarding WMF-community disputes about deployments
On Sep 1, 2014, at 8:45 AM, Todd Allen toddmal...@gmail.com wrote: That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said Nah, rather not. That's... Not exactly what I remember happening there. What I remember was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked what's the problem you're actually trying to solve?, and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since. __ Philippe Beaudette Director, Community Advocacy ___ 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] Next steps regarding WMF-community disputes about deployments
On Sep 1, 2014 3:21 PM, Philippe Beaudette pbeaude...@wikimedia.org wrote: On Sep 1, 2014, at 8:45 AM, Todd Allen toddmal...@gmail.com wrote: That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said Nah, rather not. That's... Not exactly what I remember happening there. What I remember was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked what's the problem you're actually trying to solve?, and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since. I don't agree with that assessment, but it's possible I'm missing some elements of the process. Philippe, any chance you could full in the summary with a few specifics, and maybe some links? 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] Next steps regarding WMF-community disputes about deployments
That's the issue I cited above. You haven't heard more complaints, because the complaint was pointless the first time and took a massive effort to produce. The underlying issue isn't fixed. We're still drowning in crap and spam from people who never have the slightest intent of editing helpfully, and those who are newbies who genuinely want to help but need guidance get caught in the crossfire aimed at the vandals and spammers. It is relatively rare that when a genuinely new editor's first edit is a creation, it is the creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that they should do it. So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly the best we were going to get. On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette pbeaude...@wikimedia.org wrote: On Sep 1, 2014, at 8:45 AM, Todd Allen toddmal...@gmail.com wrote: That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said Nah, rather not. That's... Not exactly what I remember happening there. What I remember was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked what's the problem you're actually trying to solve?, and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since. __ Philippe Beaudette Director, Community Advocacy ___ 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] Next steps regarding WMF-community disputes about deployments
Wasn't the creation of the DRAFT namespace at least in part a response to concerns raised at ACTRIAL, in particular new, poorly developed articles showing up in mainspace? Risker/Anne On 1 September 2014 19:08, Joe Decker joedec...@gmail.com wrote: This, to the best of my knowledge, represents the entirety of the WMF's response to ACTRIAL. To the extent that there was additional feedback given, it was not given at WP:ACTRIAL, nor any other venue I am aware of. https://bugzilla.wikimedia.org/show_bug.cgi?id=30208 --Joe On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmal...@gmail.com wrote: That's the issue I cited above. You haven't heard more complaints, because the complaint was pointless the first time and took a massive effort to produce. The underlying issue isn't fixed. We're still drowning in crap and spam from people who never have the slightest intent of editing helpfully, and those who are newbies who genuinely want to help but need guidance get caught in the crossfire aimed at the vandals and spammers. It is relatively rare that when a genuinely new editor's first edit is a creation, it is the creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that they should do it. So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly the best we were going to get. On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette pbeaude...@wikimedia.org wrote: On Sep 1, 2014, at 8:45 AM, Todd Allen toddmal...@gmail.com wrote: That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said Nah, rather not. That's... Not exactly what I remember happening there. What I remember was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked what's the problem you're actually trying to solve?, and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since. __ Philippe Beaudette Director, Community Advocacy ___ 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 -- Joe Decker www.joedecker.net ___ 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] Next steps regarding WMF-community disputes about deployments
I hope that's not the feature Philippe meant, but maybe. For my clients and students I think it's generally caused more confusion than it's solved, since now they have an additional layer of bureaucracy to navigate (AFC). Is there any data suggesting that's been a net improvement for new users? Pete On Sep 1, 2014 4:38 PM, Risker risker...@gmail.com wrote: Wasn't the creation of the DRAFT namespace at least in part a response to concerns raised at ACTRIAL, in particular new, poorly developed articles showing up in mainspace? Risker/Anne On 1 September 2014 19:08, Joe Decker joedec...@gmail.com wrote: This, to the best of my knowledge, represents the entirety of the WMF's response to ACTRIAL. To the extent that there was additional feedback given, it was not given at WP:ACTRIAL, nor any other venue I am aware of. https://bugzilla.wikimedia.org/show_bug.cgi?id=30208 --Joe On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmal...@gmail.com wrote: That's the issue I cited above. You haven't heard more complaints, because the complaint was pointless the first time and took a massive effort to produce. The underlying issue isn't fixed. We're still drowning in crap and spam from people who never have the slightest intent of editing helpfully, and those who are newbies who genuinely want to help but need guidance get caught in the crossfire aimed at the vandals and spammers. It is relatively rare that when a genuinely new editor's first edit is a creation, it is the creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that they should do it. So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly the best we were going to get. On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette pbeaude...@wikimedia.org wrote: On Sep 1, 2014, at 8:45 AM, Todd Allen toddmal...@gmail.com wrote: That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said Nah, rather not. That's... Not exactly what I remember happening there. What I remember was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked what's the problem you're actually trying to solve?, and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since. __ Philippe Beaudette Director, Community Advocacy ___ 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 -- Joe Decker www.joedecker.net ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
What is irritating about the ACTRIAL scenario, was that it was a well defined (6 month) test. It might have worked, it might not have worked. But we would have known. We would have had solid comparators. Most of what we do (WMF and community) has no control to establish whether it works. To be clear, I am against preventing article creation by IPs let alone non-autoconfirmed users. But this trial might well have provided compelling evidence one way or the other. The dismissal as a we know better was a bad thing, but not uncommon on Bugzilla. On 2 September 2014 01:06, Pete Forsyth petefors...@gmail.com wrote: I hope that's not the feature Philippe meant, but maybe. For my clients and students I think it's generally caused more confusion than it's solved, since now they have an additional layer of bureaucracy to navigate (AFC). Is there any data suggesting that's been a net improvement for new users? Pete On Sep 1, 2014 4:38 PM, Risker risker...@gmail.com wrote: Wasn't the creation of the DRAFT namespace at least in part a response to concerns raised at ACTRIAL, in particular new, poorly developed articles showing up in mainspace? Risker/Anne On 1 September 2014 19:08, Joe Decker joedec...@gmail.com wrote: This, to the best of my knowledge, represents the entirety of the WMF's response to ACTRIAL. To the extent that there was additional feedback given, it was not given at WP:ACTRIAL, nor any other venue I am aware of. https://bugzilla.wikimedia.org/show_bug.cgi?id=30208 --Joe On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen toddmal...@gmail.com wrote: That's the issue I cited above. You haven't heard more complaints, because the complaint was pointless the first time and took a massive effort to produce. The underlying issue isn't fixed. We're still drowning in crap and spam from people who never have the slightest intent of editing helpfully, and those who are newbies who genuinely want to help but need guidance get caught in the crossfire aimed at the vandals and spammers. It is relatively rare that when a genuinely new editor's first edit is a creation, it is the creation of an appropriate article on a workable subject, and that's normally more by dumb luck than them having actual knowledge that they should do it. So, consider that a complaint. The proposed fix didn't work, and most people at the time didn't figure it would work, but it was clearly the best we were going to get. On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette pbeaude...@wikimedia.org wrote: On Sep 1, 2014, at 8:45 AM, Todd Allen toddmal...@gmail.com wrote: That's contradicted by, among other things, ACTRIAL as mentioned above. The en.wp community came to a clear consensus for a major change, and the WMF shrugged and said Nah, rather not. That's... Not exactly what I remember happening there. What I remember was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked what's the problem you're actually trying to solve?, and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since. __ Philippe Beaudette Director, Community Advocacy ___ 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 -- Joe Decker www.joedecker.net ___ 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:
