Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
James, Pine suggested you might be able to fill in some of the gaps here. I am not tied to any given format, but what I'm looking for is the connective tissue between things like ACTRIAL, AFC and its increased use, Page Curation, the Draft: namespace, etc. Reading through the associated pages on wiki, it appears (most specifically from a couple comments from Steven Walling) that there was a strategic framework at the WMF that tied this stuff together. But after spending 45 minutes or so browsing wiki discussions and feature pages, I didn't feel I was getting any closer to seeing what it was/is. Can you help? Pete On Fri, Apr 24, 2015 at 12:21 AM, Pete Forsyth petefors...@gmail.com wrote: On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.p...@gmail.com wrote: Philippe is on vacation, so I'm forwarding this to Rachel. Thanks Pine. That's unfortunate, but maybe there is somebody (maybe Fabrice?) who can shed some light on the general thinking in the software development in this area. There have been several closely related things -- Article Creation Wizard, Draft: namespace, New Page Patrol software... -- and I see many references to an overall plan, but I've had difficulty finding a summary of that plan. In the meantime, I've been trying to put the pieces together myself, and have gotten some good assistance from Nemo Bis and Aaron Halfaker -- see here: https://meta.wikimedia.org/wiki/Research_talk:Wikipedia_article_creation#Cutoff_date_for_comparison.3F At this point, in addition to clarification from Philippe about which part he was referring to, the main thing I'm hoping to accomplish is basically a timeline of milestones, more or less like this (I have somewhat made up the data below for the sake of illustrating the format): * January 1, 2004: AFC process created. [[Wikilink to tool]] [diff or mailing list for decision-making process] * February 1, 2011: RfC on English Wikipedia calls for new procedure [[wikilink to RfC]] [Bugzilla link for request] * June 1, 2011: Articles for Creation wizard launched [[Wikilink]] [discussion link] with these impacts on user experience: ** Impact 1 ** Impact 2 ** Impact 3... ...and so on. Who at WMF would be best able to fill in the gaps in such a list? Or does the list already exist in a strategy document somewhere? I haven't been able to find it yet, but I'm still looking. 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] Next steps regarding WMF-community disputes about deployments
I put model writing a new article with visual editor on my to-do list. It may be a good idea to do a few test runs where we boot a hundred or so pages in each category in VisualEditor, and then see how many of each have errors. On Apr 25, 2015 1:51 PM, David Gerard dger...@gmail.com wrote: On 25 April 2015 at 04:11, David Goodman dgge...@gmail.com wrote: As I cannot use it consistently myself without making errors, I'm not going to teach people the visual editor. I've done quite nicely teaching beginners to use the wiki syntax, by imitating what they see. When did you last use it? I ask because I just started using it again after a long while not, and it's *ridiculously* better now than it was in its first six months. It's now at the sort of quality where I'd be enormously happy to put it in front of people, as it wasn't two years ago. Also, it is the only sane way to edit tables. (The amazing thing about wikitext for tables is that it's actually worse than the plain HTML it replaced.) I expect your newbies will be less than pleased if they ever have to add or remove a table column and only later discover that the VE makes this a near-trivial task. - d. ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On 25 April 2015 at 04:11, David Goodman dgge...@gmail.com wrote: As I cannot use it consistently myself without making errors, I'm not going to teach people the visual editor. I've done quite nicely teaching beginners to use the wiki syntax, by imitating what they see. When did you last use it? I ask because I just started using it again after a long while not, and it's *ridiculously* better now than it was in its first six months. It's now at the sort of quality where I'd be enormously happy to put it in front of people, as it wasn't two years ago. Also, it is the only sane way to edit tables. (The amazing thing about wikitext for tables is that it's actually worse than the plain HTML it replaced.) I expect your newbies will be less than pleased if they ever have to add or remove a table column and only later discover that the VE makes this a near-trivial task. - 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
As I cannot use it consistently myself without making errors, I'm not going to teach people the visual editor. I've done quite nicely teaching beginners to use the wiki syntax, by imitating what they see. As I have spent most of my time for the last year and a half dealing with the gross deficiencies in AfC, I continue to feel that the best thing to do with it is to discontinue it altogether: it's an excellent example of technical solutions made without considering the inadequate number of skilled people to operate it, and the attraction it would have for the incompetent. (It also showed the lack of willingness of those devising it to make even the most obvious of changes (there is *still* no easy way to list multiple reasons for rejection without a manual over-ride) I cannot judge competence at the technical level except by the results. Draft space was initiated by those like myself trying to find a replacement for it. We hoped it would replace, not just add on as it has done. What I primarily want from the tech staff at WMF is to improve performance by fixing obsolete internal elements of the system. They finally seem to be doing that. What is equally needed but of less relevance to my own work is to do whatever depth of reprogramming is needed to accommodate mobile devices. They're doing that--how well I leave it to others to say. On Fri, Apr 24, 2015 at 3:40 AM, Pine W wiki.p...@gmail.com wrote: Hi Pete, James A. might be able to answer that, or know which project manager to ping. AFC and related processes are within my scope of concern regarding editor retention, but they're not my expertise. I wish I could help more. Currently, when I'm not dealing with Cascadia Wikimedians budgets and events, my other item of great interest is VisualEditor, which I feel has come a long way. In Cascadia we intend to start to introduce new users to VisualEditor, using some presentation materials that I'm putting together, hopefully for eventual integration into a couple of videos. Regarding broader editor engagement plans going forward, I would like to see those fleshed out by WMF, and I have that on my list of items to ask Rachel and/or Lila about if no one else does in the next few weeks. Pine Pine *This is an Encyclopedia* https://www.wikipedia.org/ *One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.* *—Catherine Munro* On Fri, Apr 24, 2015 at 12:21 AM, Pete Forsyth petefors...@gmail.com wrote: On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.p...@gmail.com wrote: Philippe is on vacation, so I'm forwarding this to Rachel. Thanks Pine. That's unfortunate, but maybe there is somebody (maybe Fabrice?) who can shed some light on the general thinking in the software development in this area. There have been several closely related things -- Article Creation Wizard, Draft: namespace, New Page Patrol software... -- and I see many references to an overall plan, but I've had difficulty finding a summary of that plan. In the meantime, I've been trying to put the pieces together myself, and have gotten some good assistance from Nemo Bis and Aaron Halfaker -- see here: https://meta.wikimedia.org/wiki/Research_talk:Wikipedia_article_creation#Cutoff_date_for_comparison.3F At this point, in addition to clarification from Philippe about which part he was referring to, the main thing I'm hoping to accomplish is basically a timeline of milestones, more or less like this (I have somewhat made up the data below for the sake of illustrating the format): * January 1, 2004: AFC process created. [[Wikilink to tool]] [diff or mailing list for decision-making process] * February 1, 2011: RfC on English Wikipedia calls for new procedure [[wikilink to RfC]] [Bugzilla link for request] * June 1, 2011: Articles for Creation wizard launched [[Wikilink]] [discussion link] with these impacts on user experience: ** Impact 1 ** Impact 2 ** Impact 3... ...and so on. Who at WMF would be best able to fill in the gaps in such a list? Or does the list already exist in a strategy document somewhere? I haven't been able to find it yet, but I'm still looking. 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 ___ Wikimedia-l mailing list, guidelines at:
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.p...@gmail.com wrote: Philippe is on vacation, so I'm forwarding this to Rachel. Thanks Pine. That's unfortunate, but maybe there is somebody (maybe Fabrice?) who can shed some light on the general thinking in the software development in this area. There have been several closely related things -- Article Creation Wizard, Draft: namespace, New Page Patrol software... -- and I see many references to an overall plan, but I've had difficulty finding a summary of that plan. In the meantime, I've been trying to put the pieces together myself, and have gotten some good assistance from Nemo Bis and Aaron Halfaker -- see here: https://meta.wikimedia.org/wiki/Research_talk:Wikipedia_article_creation#Cutoff_date_for_comparison.3F At this point, in addition to clarification from Philippe about which part he was referring to, the main thing I'm hoping to accomplish is basically a timeline of milestones, more or less like this (I have somewhat made up the data below for the sake of illustrating the format): * January 1, 2004: AFC process created. [[Wikilink to tool]] [diff or mailing list for decision-making process] * February 1, 2011: RfC on English Wikipedia calls for new procedure [[wikilink to RfC]] [Bugzilla link for request] * June 1, 2011: Articles for Creation wizard launched [[Wikilink]] [discussion link] with these impacts on user experience: ** Impact 1 ** Impact 2 ** Impact 3... ...and so on. Who at WMF would be best able to fill in the gaps in such a list? Or does the list already exist in a strategy document somewhere? I haven't been able to find it yet, but I'm still looking. 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] Next steps regarding WMF-community disputes about deployments
Hi Pete, James A. might be able to answer that, or know which project manager to ping. AFC and related processes are within my scope of concern regarding editor retention, but they're not my expertise. I wish I could help more. Currently, when I'm not dealing with Cascadia Wikimedians budgets and events, my other item of great interest is VisualEditor, which I feel has come a long way. In Cascadia we intend to start to introduce new users to VisualEditor, using some presentation materials that I'm putting together, hopefully for eventual integration into a couple of videos. Regarding broader editor engagement plans going forward, I would like to see those fleshed out by WMF, and I have that on my list of items to ask Rachel and/or Lila about if no one else does in the next few weeks. Pine Pine *This is an Encyclopedia* https://www.wikipedia.org/ *One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.* *—Catherine Munro* On Fri, Apr 24, 2015 at 12:21 AM, Pete Forsyth petefors...@gmail.com wrote: On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.p...@gmail.com wrote: Philippe is on vacation, so I'm forwarding this to Rachel. Thanks Pine. That's unfortunate, but maybe there is somebody (maybe Fabrice?) who can shed some light on the general thinking in the software development in this area. There have been several closely related things -- Article Creation Wizard, Draft: namespace, New Page Patrol software... -- and I see many references to an overall plan, but I've had difficulty finding a summary of that plan. In the meantime, I've been trying to put the pieces together myself, and have gotten some good assistance from Nemo Bis and Aaron Halfaker -- see here: https://meta.wikimedia.org/wiki/Research_talk:Wikipedia_article_creation#Cutoff_date_for_comparison.3F At this point, in addition to clarification from Philippe about which part he was referring to, the main thing I'm hoping to accomplish is basically a timeline of milestones, more or less like this (I have somewhat made up the data below for the sake of illustrating the format): * January 1, 2004: AFC process created. [[Wikilink to tool]] [diff or mailing list for decision-making process] * February 1, 2011: RfC on English Wikipedia calls for new procedure [[wikilink to RfC]] [Bugzilla link for request] * June 1, 2011: Articles for Creation wizard launched [[Wikilink]] [discussion link] with these impacts on user experience: ** Impact 1 ** Impact 2 ** Impact 3... ...and so on. Who at WMF would be best able to fill in the gaps in such a list? Or does the list already exist in a strategy document somewhere? I haven't been able to find it yet, but I'm still looking. 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 ___ 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 agree with the statement New tech can only do so much to fix the problem. Our retention rate for new editors was 1% the last time I checked. What we should do about that should probably be the subject of a different thread. We've had multiple discussions about vital statistics for the editor population on this mailing list, the Research mailing list, and the Gendergap mailing list, in addition to countless on-wiki discussions. I also hope that there will be discussions about this issue at the Wikimedia Conference. I personally wrote Saving Wikipedia as one of my interests in attending the conference, and that's not an exaggeration. We need to get out of long-term-decline mode. Pine Pine *This is an Encyclopedia* https://www.wikipedia.org/ *One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.* *—Catherine Munro* On Thu, Apr 23, 2015 at 8:08 PM, Aleksey Bilogur aleksey.bilo...@gmail.com wrote: Sure, and from what I hear it helped, but it was no panacea, especially since it's a solution that still relies on a still-declining editor base. Not like turning the valves would be, and that's clearly not going to happen. Hence why I doubt there's much more room for improvement on this issue. New tech can only do so much to fix the problem. On Thu, Apr 23, 2015 at 11:01 PM, James Alexander jalexan...@wikimedia.org wrote: James Alexander Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.p...@gmail.com wrote: Hi Pete, Philippe is on vacation, so I'm forwarding this to Rachel. Pine He pops in every once in a while during his break but while he is away Maggie and I are splitting his work up (and this is, for better or worse, well before Rachel's time). On Apr 22, 2015 11:59 PM, Pete Forsyth petefors...@gmail.com wrote: Philippe, can you address what you were talking about here last fall -- was the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did in response to ACTRIAL? If so -- has there been any study of whether its intended outcomes panned out? If not -- could you outline what you meant by [WMF] proposed and built a set of tools to directly address that problem without compromising the core value of openness? Pete [[User:Peteforsyth]] I do not believe he was talking about the Draft feature, which came later. I think he was referring to the Page Curation https://www.mediawiki.org/wiki/Page_Curation tool which I know for a fact was created in direct response to ACTRIAL because one of the big complaints was the difficulty with patrolling new pages. While I wasn't directly involved it was one of the first software products I remember (either as a community member or staff member) the Foundation trying to engage closely with the community throughout it's development to create something that would work well. I also think it was the first product with a Community Liaison (who, incidentally, had been the most active page patroller for multiple years before as a community member). ___ 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
Hi Pete, Philippe is on vacation, so I'm forwarding this to Rachel. Pine On Apr 22, 2015 11:59 PM, Pete Forsyth petefors...@gmail.com wrote: Philippe, can you address what you were talking about here last fall -- was the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did in response to ACTRIAL? If so -- has there been any study of whether its intended outcomes panned out? If not -- could you outline what you meant by [WMF] proposed and built a set of tools to directly address that problem without compromising the core value of openness? Pete [[User:Peteforsyth]] On Mon, Sep 1, 2014 at 5:06 PM, 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 ,
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Philippe, can you address what you were talking about here last fall -- was the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did in response to ACTRIAL? If so -- has there been any study of whether its intended outcomes panned out? If not -- could you outline what you meant by [WMF] proposed and built a set of tools to directly address that problem without compromising the core value of openness? Pete [[User:Peteforsyth]] On Mon, Sep 1, 2014 at 5:06 PM, 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: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@lists.wikimedia.org Unsubscribe:
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
James Alexander Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur On Thu, Apr 23, 2015 at 11:03 AM, Pine W wiki.p...@gmail.com wrote: Hi Pete, Philippe is on vacation, so I'm forwarding this to Rachel. Pine He pops in every once in a while during his break but while he is away Maggie and I are splitting his work up (and this is, for better or worse, well before Rachel's time). On Apr 22, 2015 11:59 PM, Pete Forsyth petefors...@gmail.com wrote: Philippe, can you address what you were talking about here last fall -- was the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did in response to ACTRIAL? If so -- has there been any study of whether its intended outcomes panned out? If not -- could you outline what you meant by [WMF] proposed and built a set of tools to directly address that problem without compromising the core value of openness? Pete [[User:Peteforsyth]] I do not believe he was talking about the Draft feature, which came later. I think he was referring to the Page Curation https://www.mediawiki.org/wiki/Page_Curation tool which I know for a fact was created in direct response to ACTRIAL because one of the big complaints was the difficulty with patrolling new pages. While I wasn't directly involved it was one of the first software products I remember (either as a community member or staff member) the Foundation trying to engage closely with the community throughout it's development to create something that would work well. I also think it was the first product with a Community Liaison (who, incidentally, had been the most active page patroller for multiple years before as a community member). ___ 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 don't know that there is a next step. The WMF has clearly indicated they will not budge on the solution that the high-level Wikipedia community says is needed. I have qualms myself about the way the community operates at times but covering ACTRAIL and New Page Patrol at the Signpost felt like an enormous and egregious slap across the face. I still see and feel the repercussions of these breaches of trust today. On Thu, Apr 23, 2015 at 2:03 PM, Pine W wiki.p...@gmail.com wrote: Hi Pete, Philippe is on vacation, so I'm forwarding this to Rachel. Pine On Apr 22, 2015 11:59 PM, Pete Forsyth petefors...@gmail.com wrote: Philippe, can you address what you were talking about here last fall -- was the draft feature, and the way it directed new contributors toward the Articles for Creation process, the thing you alluded to, that WMF did in response to ACTRIAL? If so -- has there been any study of whether its intended outcomes panned out? If not -- could you outline what you meant by [WMF] proposed and built a set of tools to directly address that problem without compromising the core value of openness? Pete [[User:Peteforsyth]] On Mon, Sep 1, 2014 at 5:06 PM, 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,
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On Sat, Sep 6, 2014 at 8:13 AM, Erik Moeller e...@wikimedia.org wrote: The team has pretty strong arguments why they don't want posts to be editable (the gist is, they fear that no other discussion system does this, and it will freak people out -- they see the introduction of a new system as a good opportunity to reset expectations). I would argue that the best and most successful examples of knowledge production oriented discussion systems allow the editing of posts by others. Quora has that feature. Stackoverflow has that feature. The edit might be sent through a review queue depending on your reputation, but from the user's point of view that's not a big difference, and the bar is pretty low - Stackoverflow allows direct editing from 2000 reputation points, while access to the various queues (which is the closest equivalent to being a Wikipedia admin) comes after 10,000 points. (An active user can easily earn 100 or more points a week, so 2000 points mean a few months of using the site.) ___ 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 would suggest aiming for a series of base hits. (: An attempt was made to hit VE out of the park. We know how well that worked. I think a lot of the work of capturing suggestions is supposed to be done by the project manager and the engineering community liaisons. It would be interesting to have community ideas documented in a single, public, searchable, well-organized location. The project manager and community liaison could be the curators. It might be good for people who are interested in Flow to attend the Flow IRC office hours, and join in the Flow discussions on the Editor Engagement email list. Pine On Sun, Sep 7, 2014 at 12:38 AM, Wil Sinclair w...@wllm.com wrote: Fundamentally, I'd ask people to relax a bit regarding Flow. Nobody's planning to push this one out radically. Today we saw some on-wiki drama because a new test page was turned on. For something like the en.wp Teahouse, I'd want the hosts to be fully on-board before converting it over (and the rest of the community to not oppose it). If that's not doable, we can focus on other use cases first. It's early days and this one's a long haul -- just like VE. But we shouldn't shy away from a problem just because it's hard. I think this is one of the points some of us here are trying to make. We *don't* want Flow to be just like VE. We want it to be a good piece of software that is rolled out smoothly. There are some serious communication problems that I can already see having a toll. Fractured discussions, issues/concerns not captured in workflows, and many members of the community who feel like they haven't been heard out during earlier stages of the project. We have an opportunity to not get all wound around the axle like we have been with MV, and that opportunity should not be thrown away. Quite frankly, the WMF could do a lot more to improve communications across the community with respect to Flow. Pick one forum and redirect discussions- even this one- to it. Right now there are a few candidates. Make sure all the takeaways from those discussions are captured in workflows; don't let ideas get lost in archives. Choose one place to keep your backlog- bugzilla or trello- and stick with it. You'll need the community's help to see what works for the different roles everyone must play to make software that works well for its users. But the community needs your help in organizing the highly detailed communications with users that is always required to build good software. It good to hear you say that this is a long haul, because Flow obviously has a ways to go. But that doesn't mean it has to be a death march to the same reception as VE or MV. Let's all be smarter this time. Learning how to communicate better is a great place to start, and I hope the feedback I've given here is helpful. Please let me know if there is anything you can think of that I- or anyone else in the broader community- can do to help you hit this one out of the park. ,Wil ___ 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, I like your story and I understand the sentiment. For me the story is about the kind of functionality that we may or may not need in Flow. The story is not about retaining what went before.. Mark my words, I cannot wait for the old talk system to go. As I understand the current situation, Flow is gaining in functionality and it is being used in all kinds of settings. As time goes by, it becomes feature rich and increasingly versatile. I am sure the husband learned from the first time an egg was presented to his wife. I am sure they shared fond memories of this moment of embarrassment. Life is short and learning how to improve your ways makes life more pleasant. The lessons of the egg are for all of us. Do not single out anyone and do not think any of us is beyond the need of learning from past mistakes. Thanks, GerardM On 7 September 2014 03:17, Risker risker...@gmail.com wrote: I'm not going to reply in-line here, because I think there's been an undoubtedly unintentional missing of the point here. Instead I will tell a story about a friend of mine. Some years ago, when her children were 3 and 4, their family had a lovely traditional Christmas Day, but something felt like it was missing. She told her husband about a tradition in her own family, where she and her siblings had (since they were very young children) always bought their mother a Terry's Chocolate Orange for Christmas - no matter what else her mom got, that was considered the one essential Christmas gift under the tree. Mom would glow with joy when she unwrapped it, and her most heartfelt thanks was for this specific present. Some time later in the day, she'd smack it open and everyone would get a piece. My friend thought it would be wonderful to start a similar tradition in her own young family. Her husband remembered this story in the weeks leading up to the next Christmas. He plotted with the children, now 4 and 5; he researched the best types of similar treats; and ultimately he helped the children obtain a chocolate orange made of the finest Swiss chocolate, filled with Grand Marnier liqueur, presented in an elegant marquetry box. Everyone was surprised when she burst into tears instead of smiles, and spent the whole day snapping at people and generally being a grouch. Finally her husband confronted her and insisted she explain her behaviour. What happened, of course, was that despite his best efforts, he'd missed the real purpose of the chocolate orange. He thought it was symbolic of the esteem in which the matriarch was held. Really, it was about the familial sharing of a special treat; the joy that the sharing brought to both the recipient and the presenters. But she couldn't share liqueur-filled chocolate with her children, and could barely bring herself to smack open the beautifully designed and presented chocolate. In other words, even though the gift looked brilliant on paper, it missed the point. I think the design of Flow is much like the liqueur-filled chocolates. It's missed the point of a discussion space on Wikimedia projects. All the use cases in the world, no matter how carefully researched and accounted for, will help you build a discussion system to effectively replace a discussion system if you don't understand that the one overriding, incontrovertible feature of the current system is that it is a page that acts just like all the other wiki pages, with all the same functions, and anyone who can work on one wiki-page can work on any of them. In other words, you're building something that is explicitly different from wiki-pages - but the expectation of the majority of the people who will use these pages is that they work exactly like any other wiki-page. This is what I mean when I say that you've not really understood how wiki-discussion functions, and you've created the bells and whistles without demonstrating an understanding of what the real, core functions of these pages are. The priority in design should focus on being able to produce identical results for basic wiki-editing and page management: we move pages, we protect them, we undo and revert edits, we fix typos and correct URLS and links in each other's posts, we quote each other and copy/paste, we modify each other's words when collaborating on the wording of a complex section of an article, we get rid of trolling, we delete and sometimes suppress personal attacks, we hat and archive individual discussions. Whether or not a post gets auto-signed is a frill compared to those basic functions, and it is inevitable that the deprioritization of the basics will result in people not really caring much about the frills (no matter how well they are executed) and focusing instead on what the new system doesn't do. This is the real parallel between Flow and Visual Editor - focusing on the difference between the new product and that it was intended to replace, instead of ensuring
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
2014-09-07 4:17 GMT+03:00 Risker risker...@gmail.com: I think the design of Flow is much like the liqueur-filled chocolates. It's missed the point of a discussion space on Wikimedia projects. All the use cases in the world, no matter how carefully researched and accounted for, will help you build a discussion system to effectively replace a discussion system if you don't understand that the one overriding, incontrovertible feature of the current system is that it is a page that acts just like all the other wiki pages, with all the same functions, and anyone who can work on one wiki-page can work on any of them. I see your point, but the fact is that the current system is NOT a page that acts just like all the other wiki pages. Talk pages use categories differently. Article talk pages, for better or worse, don't have interlanguage links. Talk pages use : for indentation a lot; articles rarely use this piece of syntax. Talk pages can use templates the same way as articles, but the actual templates used on them are different. Long talk pages are archived; articles aren't. Talk pages have signatures; articles, for better or worse, don't. Talk pages rarely have images. So yes, the wiki syntax is the same, but the practice of its use is fundamentally different. And voila - the wiki syntax in Flow works much the same way as elsewhere - links, templates, etc. The plan is to use the same VisualEditor as for articles in the future. What Flow replaces is the crutches built to force wiki pages into being discussion forums - talkback, indentation, archive templates and bots, the infinite edit conflicts, etc. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ 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/06/2014 17:06 PM, Marc A. Pelletier wrote: On 09/06/2014 12:34 PM, Isarra Yos wrote: if the designers do not even understand the basic principles behind a wiki, how can what is developed possibly suit our needs? You're starting from the presumption that, for some unexplained reason, collaborative discussion benefits from being a wiki (as opposed to, you know, the actual content). Wikipedia has been built using that platform. I'd say that's a very good reason to trust that the model is at least capable. :-) Very many people, myself included, believe that a wiki page is an *atrocious* medium for discussion. Sure, and I agree there are many way to improve how users are engaged into discussion and to keep it manageable. But what is missing from this conversation is the point that Wikipedia talk space is not *merely* a medium for discussion: there are other vital roles that may be hindered by a radical focus on conversation: tl;dr version: there are times and places that Wikipedia discussion system needs to be a Microsoft OneNote, and Flow is building us a Twitter (minus the 140 characters limit). - The talk space has a strong expectation that it serves as an archive of all decisions taken in building the articles, i.e. to show how the sausages are made. The disembodied nature of Flow topics, which may be shown out of order and distributed to many boards, makes it hard to recover a sequential view of the conversations in order as they happened. - Same thing for keeping user's behavior in check - policy enforcement often requires that the reviewers can see exactly what the users saw when they performed some particular disruptive action, to assess whether it was made in good faith from incomplete information or a misunderstanding. - Comment-based discussion is not the only way editors collaborate; nor discussions are limited to users expressing their particular views at ordered, pre-defined processes. Some fellow users have already pointed out how the wiki page works as a shared whiteboard where semi-structured or free-form content can be worked upon by several editors, and improved iteratively in an opportunistic way. Sometimes, that re-shaping of text is made onto the form of the conversation itself, by re-factoring, splitting, merging and re-classifying comments from many editors. This would be hard or impossible to do if the layout of the discussion is fixed in hardware and comments belong to the poster. - Wikiprojects develop over time new procedures that better suit the workflow of their members to achieve their goals. Their project pages are free-form collages of all the relevant information they require to do their work, plus discussion processes that may involve just its members or any other external participant. As projects cover all the aspects of human knowledge, it would be difficult to provide a one-size-fits-all interface that may cover all their needs - the flexibility to compose new layouts and compilations of content is core to achieve their goals. - There's a sense now that the community owns the content of all pages including talk, and can manage it to their liking. That will disappear if the base model is changed to one based on user-owned comments. There has not been enough discussion of how that will affect all the existing projects and guidelines, or whether such change is acceptable and beneficial to the goal of writing the encyclopedia. A wiki-like system is very good at achieving those. Some of these needs have surfaced at previous discussion at Talk:Flow, and some have been already addressed or influenced the design, but some others are squarely opposed to the nature of a threaded discussion where the structure is enforced by the platform. It would be sensible that the process to gather feedback from the community includes solid answers to these facets of the tool. ___ 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 Fri, Sep 5, 2014 at 10:42 PM, Risker risker...@gmail.com wrote: The major deficiencies that have long been identified in the current discussion system (and that can be addressed by technology) are all able to be addressed in MediaWiki software or by extensions. Automatic signatures have been done by bots for years; indenting could be added to the editing function gadget and moved to an extension; much work has already been done on graceful resolution of edit conflicts. The ability to watchlist an individual thread or section of a page is more challenging but, I have been told, still possible. Let's just acknowledge that the limitations of what can reasonably be layered onto wikitext-based representation of comments have not been fully explored, rather than jumping to conclusions about what's easy to address and what's hard. As noted separately, I agree it may be worth pushing the boundaries a bit more on this, if only to know exactly where they are, and to achieve short term improvements. Automatic signature (something that is currently functional on Flow, but is not customizable) turns out to be more of a challenge when users are widely known by a signature line that doesn't match their username, I've not talked to them about it explicitly, but I'd guess that the PM and the UX folks have a negative aversion against custom signatures because of their free-form nature (including sometimes layout-exploding ones). Perhaps a middle-ground can be found here, with some more sanitization applied to prevent some of the sigs-from-hell occasionally found. Other than that I can't see a good reason to not just show them when they're set, and it's certainly technically trivial to do so. and there is no method by which users can add an explanatory note to their signature such as formerly known as User:Whatever. From the point forward that Flow is in wide use, a user rename would be automatically reflected in old comments if desired, much as it is reflected in old edits. But if signatures were supported, as above, you could still use them for these types of indicators, as well. The more efficient indenting has reduced possible indents to three levels, without exception; This seems to be the most religious topic when it comes to Flow. The database stores all threading information. It'd be trivial to expand the threading level if that's more popular and usable. I've heard the argument that this doesn't work on mobile, but we could just set a different threading level on mobile. I think it's worth experimenting with flat pages (with quoting) for certain purposes, and Danny wants to, but it strikes me as most reasonable to start with something that more closely resembles talk pages as they are now (which is why we did that with LQT originally). Rigid predictable technical restrictions on who can edit what has resulted in inability to remove posts that are obviously unsuitable (there's no undo or revert function), replaced with a hide function that can only be applied by certain users that's practically a red flag for people to look-see what the problem edit is. The team has pretty strong arguments why they don't want posts to be editable (the gist is, they fear that no other discussion system does this, and it will freak people out -- they see the introduction of a new system as a good opportunity to reset expectations). I personaly am not religious about it; when we built LQT we made posts editable (and made it clear who had edited someone else's posts) to preserve that normal aspect of wiki-style editing. I think we should keep talking about this. I've not seen it named as a dealbreaker for small scale deployments. The architecture can easily support both models. At the core is whether or not there is value in developing a discussion system that is radically divorced from any other interface used by the system. That's a legitimate question, although it's not as radically divorced as you would think; ultimately it'll use the VisualEditor (probably with a simplified toolbar by default) just like Flow does. As for the claim that the team never looked at current use cases, having spent hours in rooms with them where they pored over printouts of hundreds of talk pages, analyzed use cases, categorized them, prioritized them, etc., I can assure you there's been a lot more of this kind of thinking than you appreciate. There also have been round tables and other outreach efforts, and a dedicated community liaison from the start. Still, I don't think there's been enough talking to each other -- we're still getting better at doing that, collectively, and trusting in the value of conversation even when there's a lot of noise and a lot of heat. This is an opportunity for me to remind folks that the cost of heat (accusations, insults, reverts, etc.) is that people withdraw. We (WMF) have to do our part to prevent things from getting heated, but I'd ask folks who notice this kind of thing
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller e...@wikimedia.org wrote: That's a legitimate question, although it's not as radically divorced as you would think; ultimately it'll use the VisualEditor (probably with a simplified toolbar by default) just like Flow does. .. just like article editing, I mean - you'll have a choice between VE/wikitext, probably with a toolbar that's optimized for comments (perhaps advanced tools available when needed). Moreover, I think the idea that talk pages are actually an intuitive system once you're familiar with editing articles is both unproven and contradicted by all user research into article editing and talk pages. Users discover wikitext incrementally, and they understand it to be kind of like HTML. They think of it as a document formatting language. When they first discover talk pages, they have to learn a whole new set of conventions -- the notion of signing and indenting your own comments, the idea that in order to participate in a thread you have to edit it, etc. That is a system divorced from editing, and it's a mental model unlike any other discussion system. The argument would be more supportable if you could layer a decent UI on top of wikitext-based talk pages, as you suggest. But if you can do that, you'll end up with a UI that introduces many of the same conventions that Flow introduces, just with a hard limitation on some of the additional capabilities and conveniences you can introduce. It may be, as I acknowledged, still worth doing - even as an interim step towards Flow. 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] Next steps regarding WMF-community disputes about deployments
Something that that would be useful is a video demonstration of Flow in action. I like the goal of VE in principle, and I hear lots of comments to the effect that it is improving over time. MediaViewer seems to be on the road to improvement. I understand where both of those are headed. But I am trying to get a mental picture of Flow from what I've read. A video would be worth a thousand words. If Flow helps us to organize discussions in ways that makes them easier for everyone to follow, that will be good. If Flow disrupts constructive ways of having conversations and is not intuitive, there will be yet another round of power users asking why time and money are being spent on projects that miss the biggest pain points and may cause more pain. I am hoping that Flow will be an improvement, and I think a video demo or mockup of Flow would be helpful to evaluate if Flow's design is likely to produce the intended results. Pine On Fri, Sep 5, 2014 at 11:29 PM, Erik Moeller e...@wikimedia.org wrote: On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller e...@wikimedia.org wrote: That's a legitimate question, although it's not as radically divorced as you would think; ultimately it'll use the VisualEditor (probably with a simplified toolbar by default) just like Flow does. .. just like article editing, I mean - you'll have a choice between VE/wikitext, probably with a toolbar that's optimized for comments (perhaps advanced tools available when needed). Moreover, I think the idea that talk pages are actually an intuitive system once you're familiar with editing articles is both unproven and contradicted by all user research into article editing and talk pages. Users discover wikitext incrementally, and they understand it to be kind of like HTML. They think of it as a document formatting language. When they first discover talk pages, they have to learn a whole new set of conventions -- the notion of signing and indenting your own comments, the idea that in order to participate in a thread you have to edit it, etc. That is a system divorced from editing, and it's a mental model unlike any other discussion system. The argument would be more supportable if you could layer a decent UI on top of wikitext-based talk pages, as you suggest. But if you can do that, you'll end up with a UI that introduces many of the same conventions that Flow introduces, just with a hard limitation on some of the additional capabilities and conveniences you can introduce. It may be, as I acknowledged, still worth doing - even as an interim step towards Flow. 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] Next steps regarding WMF-community disputes about deployments
On Fri, Sep 5, 2014 at 11:41 PM, Pine W wiki.p...@gmail.com wrote: Something that that would be useful is a video demonstration of Flow in action. That could be handy, Pine. But sometimes you can't demonstrate all benefits yet, because they don't even exist in the implementation yet -- only in the foundations of an architecture. And sometimes you can show the idea of a benefit, but people will look at the current implementation and hate some aspect of it, and fail to imagine a version of it that would be beneficial. To give an example of the latter, Flow already has the ability to give thread-level notifications of responses. But the first implementation of notifications was very spammy (generated too many notifications), so people who looked at it said I don't see the benefit! It's just spammy!. Love em or hate em, sites like Facebook spend years tweaking the algorithm for every one of their features (newsfeed, notifications, etc.) to get the best results from their perspective. It takes time to get this right -- and the initial reaction may often be No, this sucks because, well, it's not quite right yet. Fundamentally, I'd ask people to relax a bit regarding Flow. Nobody's planning to push this one out radically. Today we saw some on-wiki drama because a new test page was turned on. For something like the en.wp Teahouse, I'd want the hosts to be fully on-board before converting it over (and the rest of the community to not oppose it). If that's not doable, we can focus on other use cases first. It's early days and this one's a long haul -- just like VE. But we shouldn't shy away from a problem just because it's hard. 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] Next steps regarding WMF-community disputes about deployments
Hoi, I have used LiquidThreads and the current talk pages for too long. I prefer LiquidThreads ANY day warts and all over the talk pages. Ok this discussion is about automated discussion environments and lets keep to that subject. As you may know, translatewiki.net uses LQT. It is therefore quite a good environment for learning about the use of Flow. It is truly multi-lingual; by definition. It eats its own dog food; it is where the localisation of Flow and any other MediaWiki software happens. Conversion software is being developed and it will be great when it and flow is at the stage where it can bring Flow to translatewiki.net. One additional benefit is that the twn community and people like Siebrand are well able and fearless. When they have issues they will be precise, topical and in a language that will be understood by the developers of Flow. When twn is happy using flow, you can be sure that technically it suffices and that it did get proper attention from the perspectives of all the languages that are actively maintained. Thanks, GerardM On 5 September 2014 23:43, Tim Davenport shoehu...@gmail.com wrote: I really don't like the way that people are referring to Flow as a done deal with an inevitable roll out. Nothing remotely close to workable software has been produced, no case has been made that the purported problems being addressed by this top-down software project are valid issues in the community, the range of unintended effects that will be cause by the mass archiving of talk pages and move to a new flashy system hasn't been properly assessed. With Visual Editor, there was a clear need for WYSIWYG capabilities — although the software rolled out was grossly inadequate and the roll out process hamhanded (not to say incompetent). With Media Viewer, at least there is a clear benefit to a certain percentage of WP readers to offset the inconveniences resulting from mildly inadequate software. With Flow we are looking at the potential of grossly inadequate software with no apparent saving graces other than the fact that the old software is old and the new software will be new and that things will look nice. If this is done wrong, it will be a catastrophe for WMF far bigger than what happened with VE. Wil Sinclair, an enthusiast for the LiquidThreads/Flow mechanism for talk pages, is in an excellent position to give us some A/B numbers for participation at his site, with in without LiquidThreads being imposed from above. How did that work out with participation levels at the OffWiki site, Mr. Sinclair? How many very active editors has the convenient LiquidThreads mechanism generated for your site? How many edits have taken place in the month after LiquidThreads was installed over community objections versus the month before it was installed? Has the clean up process been easy reconverting to MediaWiki without the LiquidThreads extension? Bottom line: OffWiki site participation was blown up by a unilateral move to LiquidThreads by the tech department. Observe and learn. Tim Davenport Carrite on WP /// Randy from Boise on WPO Corvallis, OR === Wil Sinclair wrote: This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle: 1) Is the WMF working with the community as closely and substantially as possible to make sure Flow is ready for primetime? 2) Is the community preparing itself for a major change, not only in interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces? I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it. What can we do to make the Flow rollout as smooth as starting '''now'''? ,Wil ___ 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
On 06/09/14 06:13, Erik Moeller wrote: On Fri, Sep 5, 2014 at 10:42 PM, Risker risker...@gmail.com wrote: The major deficiencies that have long been identified in the current discussion system (and that can be addressed by technology) are all able to be addressed in MediaWiki software or by extensions. Automatic signatures have been done by bots for years; indenting could be added to the editing function gadget and moved to an extension; much work has already been done on graceful resolution of edit conflicts. The ability to watchlist an individual thread or section of a page is more challenging but, I have been told, still possible. Let's just acknowledge that the limitations of what can reasonably be layered onto wikitext-based representation of comments have not been fully explored, rather than jumping to conclusions about what's easy to address and what's hard. As noted separately, I agree it may be worth pushing the boundaries a bit more on this, if only to know exactly where they are, and to achieve short term improvements. But many of these things have been explored and experimented with. That's just it. We have extensions to create a whole new discussion system already which get some things right and others no so much, like LQT and Comments, and various bots and gadgets that do smaller tasks (auto-signing, indentation, cleanup, etc). Have the successes and failures of the existing approaches and tools been considered? Are things LQT got right present in Flow? Automatic signature (something that is currently functional on Flow, but is not customizable) turns out to be more of a challenge when users are widely known by a signature line that doesn't match their username, I've not talked to them about it explicitly, but I'd guess that the PM and the UX folks have a negative aversion against custom signatures because of their free-form nature (including sometimes layout-exploding ones). Perhaps a middle-ground can be found here, with some more sanitization applied to prevent some of the sigs-from-hell occasionally found. Other than that I can't see a good reason to not just show them when they're set, and it's certainly technically trivial to do so. Signatures that break the page are currently dealt with by yelling at the user to fix their sig and then blocking them if need be. I dunno how a structured talkpage would necessarily change that, though having the signatures automatically tidied might be useful in general, as it should at least help prevent unclosed tags. Beyond that what they allow really depends on the project, but any structured formatting with sensible padding should work fine no matter what they do (I mean, I've never seen any issues with that with LQT). and there is no method by which users can add an explanatory note to their signature such as formerly known as User:Whatever. From the point forward that Flow is in wide use, a user rename would be automatically reflected in old comments if desired, much as it is reflected in old edits. But if signatures were supported, as above, you could still use them for these types of indicators, as well. The more efficient indenting has reduced possible indents to three levels, without exception; This seems to be the most religious topic when it comes to Flow. The database stores all threading information. It'd be trivial to expand the threading level if that's more popular and usable. How is this religious? Something is needed to show progression, and lacking anything else, threading has already been proven to work. Just chopping it off has been shown time and again not to (you see it particularly often on blog and news comments). I've heard the argument that this doesn't work on mobile, but we could just set a different threading level on mobile. I think it's worth experimenting with flat pages (with quoting) for certain purposes, and Danny wants to, but it strikes me as most reasonable to start with something that more closely resembles talk pages as they are now (which is why we did that with LQT originally). Formatting the pages as flat with just ids and links to what the things are replying to could be an interesting option experiment with, especially when you don't have a lot of space. Like boards. Be like 4chan! Everyone loves 4chan. Rigid predictable technical restrictions on who can edit what has resulted in inability to remove posts that are obviously unsuitable (there's no undo or revert function), replaced with a hide function that can only be applied by certain users that's practically a red flag for people to look-see what the problem edit is. The team has pretty strong arguments why they don't want posts to be editable (the gist is, they fear that no other discussion system does this, and it will freak people out -- they see the introduction of a new system as a good opportunity to reset expectations). I personaly am not religious about it; when we built LQT we made posts
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On Sat, Sep 6, 2014 at 12:23 AM, Isarra Yos zhoris...@gmail.com wrote: Have the successes and failures of the existing approaches and tools been considered? Are things LQT got right present in Flow? Some, yes (remember Andrew and Brandon have worked on both LQT and Flow) -- in other cases the team deliberately made a different call, and they may have gotten it wrong, or not. Let's reason it through. Flow has LQT-style headers, for example, and thread-level summaries, both with a much nicer UX than LQT, but adopting some of the same principles. Signatures that break the page are currently dealt with by yelling at the user to fix their sig and then blocking them if need be. I dunno how a structured talkpage would necessarily change that, though having the signatures automatically tidied might be useful in general, as it should at least help prevent unclosed tags. Sure, some leeway (and some testing/sanitization) makes sense to me to see what works. Formatting the pages as flat with just ids and links to what the things are replying to could be an interesting option experiment with, especially when you don't have a lot of space. Like boards. Be like 4chan! Everyone loves 4chan. *cough* Why in the world would posts not be editable? I've never used a platform where discussion was important in which users couldn't at least edit their own posts (along with mods) where the lack of such wasn't often complained about (for instance bugzilla and gerrit don't allow it; moodle and tumblr do). Sorry, I should have been clearer. By default, Flow lets you edit your own comments, and lets admins edit all comments, just like typical forum conventions. It just doesn't let everyone edit everything. -- 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] Next steps regarding WMF-community disputes about deployments
On 06/09/2014, Isarra Yos zhoris...@gmail.com wrote: Be like 4chan! Everyone loves 4chan. No. This is so wrong it hurts. 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
Erik - how confident are you that you're coming up with something that the present users of talk pages - people actually trying to get work done on articles - will love? Not just barely tolerate - what are you bringing us? - 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 06/09/14 07:41, Erik Moeller wrote: On Sat, Sep 6, 2014 at 12:23 AM, Isarra Yos zhoris...@gmail.com wrote: Why in the world would posts not be editable? I've never used a platform where discussion was important in which users couldn't at least edit their own posts (along with mods) where the lack of such wasn't often complained about (for instance bugzilla and gerrit don't allow it; moodle and tumblr do). Sorry, I should have been clearer. By default, Flow lets you edit your own comments, and lets admins edit all comments, just like typical forum conventions. It just doesn't let everyone edit everything. But that's not how wikis work. On other platforms that do support such editing at all, users edit their own articles, and their own comments, with only moderators trusted to change them. But on wikis, the users are also the moderators. This applies to content and comments, and admins are only required where things can become sensitive (where concerns of privacy, site stability, or simply dangerous tools in terms of vandalism come into play). Why the sudden divergence that only admins can be mods here? Discussions aren't sensitive. This sort of thing is a large part of why some of us are so skeptical of Flow currently - if the designers do not even understand the basic principles behind a wiki, how can what is developed possibly suit our needs? The thing is, they - you - need to start really listening, and not just arguing (or not responding at all), because otherwise things are just going to get messier and messier. -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] Next steps regarding WMF-community disputes about deployments
On 06.09.2014 19:18, Gerard Meijssen wrote: Hoi, The subject is discussion / talk space not article space editing.. Yaroslav please stay on topic..Surely Marc has more than 13 edits in all kinds of discussion on multiple wikis. Thanks, GerardM On 6 September 2014 19:14, Yaroslav M. Blanter pute...@mccme.ru wrote: On 06.09.2014 19:06, Marc A. Pelletier wrote: Sadly, there *are* people who get offended that the vast unwashed masses could start contributing to *their* project without having gone through a painful, demanding rite of passage. Truth is, most people of the world don't have the time for that, or if they do, (perfectly reasonably) believe that you shouldn't have to pay to volunteer to help. -- Marc Marc, with all my due respect, this statement would be more convincing if spelled out by someone with more than 13 edits in the article space combined in 2013 and 2014. Cheers Yaroslav Sure. However, contributing to *our* project, meaning (I guess) in this case the English Wikipedia, is most and foremost contributing content. And sadly we have enough users around who try to contribute content without having time to go through the rite of passage, and we have to spend way too much time reverting and rewriting their contribution to make it appropriate for an encyclopedia. I agree though that this is off-topic in this thread. 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] Next steps regarding WMF-community disputes about deployments
On 09/06/2014 01:12 PM, Todd Allen wrote: But dismissing them by setting up a (rather ridiculous) straw man is not helpful. I *wish* it was a strawman. How else would you qualify: And sadly we have enough users around who try to contribute content without having time to go through the rite of passage, and we have to spend way too much time reverting and rewriting their contribution to make it appropriate for an encyclopedia. It's more than a little sad to not even have had to /look/ for that comment, it was offered in response to Gerard not even five minutes ago. -- 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
I'm not going to reply in-line here, because I think there's been an undoubtedly unintentional missing of the point here. Instead I will tell a story about a friend of mine. Some years ago, when her children were 3 and 4, their family had a lovely traditional Christmas Day, but something felt like it was missing. She told her husband about a tradition in her own family, where she and her siblings had (since they were very young children) always bought their mother a Terry's Chocolate Orange for Christmas - no matter what else her mom got, that was considered the one essential Christmas gift under the tree. Mom would glow with joy when she unwrapped it, and her most heartfelt thanks was for this specific present. Some time later in the day, she'd smack it open and everyone would get a piece. My friend thought it would be wonderful to start a similar tradition in her own young family. Her husband remembered this story in the weeks leading up to the next Christmas. He plotted with the children, now 4 and 5; he researched the best types of similar treats; and ultimately he helped the children obtain a chocolate orange made of the finest Swiss chocolate, filled with Grand Marnier liqueur, presented in an elegant marquetry box. Everyone was surprised when she burst into tears instead of smiles, and spent the whole day snapping at people and generally being a grouch. Finally her husband confronted her and insisted she explain her behaviour. What happened, of course, was that despite his best efforts, he'd missed the real purpose of the chocolate orange. He thought it was symbolic of the esteem in which the matriarch was held. Really, it was about the familial sharing of a special treat; the joy that the sharing brought to both the recipient and the presenters. But she couldn't share liqueur-filled chocolate with her children, and could barely bring herself to smack open the beautifully designed and presented chocolate. In other words, even though the gift looked brilliant on paper, it missed the point. I think the design of Flow is much like the liqueur-filled chocolates. It's missed the point of a discussion space on Wikimedia projects. All the use cases in the world, no matter how carefully researched and accounted for, will help you build a discussion system to effectively replace a discussion system if you don't understand that the one overriding, incontrovertible feature of the current system is that it is a page that acts just like all the other wiki pages, with all the same functions, and anyone who can work on one wiki-page can work on any of them. In other words, you're building something that is explicitly different from wiki-pages - but the expectation of the majority of the people who will use these pages is that they work exactly like any other wiki-page. This is what I mean when I say that you've not really understood how wiki-discussion functions, and you've created the bells and whistles without demonstrating an understanding of what the real, core functions of these pages are. The priority in design should focus on being able to produce identical results for basic wiki-editing and page management: we move pages, we protect them, we undo and revert edits, we fix typos and correct URLS and links in each other's posts, we quote each other and copy/paste, we modify each other's words when collaborating on the wording of a complex section of an article, we get rid of trolling, we delete and sometimes suppress personal attacks, we hat and archive individual discussions. Whether or not a post gets auto-signed is a frill compared to those basic functions, and it is inevitable that the deprioritization of the basics will result in people not really caring much about the frills (no matter how well they are executed) and focusing instead on what the new system doesn't do. This is the real parallel between Flow and Visual Editor - focusing on the difference between the new product and that it was intended to replace, instead of ensuring that things that had to be similar or identical were considered the first step of design. Risker/Anne On 6 September 2014 02:13, Erik Moeller e...@wikimedia.org wrote: On Fri, Sep 5, 2014 at 10:42 PM, Risker risker...@gmail.com wrote: The major deficiencies that have long been identified in the current discussion system (and that can be addressed by technology) are all able to be addressed in MediaWiki software or by extensions. Automatic signatures have been done by bots for years; indenting could be added to the editing function gadget and moved to an extension; much work has already been done on graceful resolution of edit conflicts. The ability to watchlist an individual thread or section of a page is more challenging but, I have been told, still possible. Let's just acknowledge that the limitations of what can reasonably be layered onto wikitext-based representation of comments have not been fully explored, rather
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
2014-09-06 1:07 GMT+02:00 Steven Walling steven.wall...@gmail.com: On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jay...@gmail.com wrote: IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis. This is rank hyperbole. The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1] Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects. Some examples: I am sure you have tested things out on various wikis, but I can confirm that seeing things been rolled out from a non-English wiki, they multiple times look like if the English community has requested it or has been copied from. One (large) example is the TemplateData part of the VisualEditor which seems to us (nl-wiki) copied from the English Wikipedia, in multiple ways. This is not how we work with templates. And I can name many more examples. Maybe it is not intended to adopt or specially fit with the English Wikipedia, if I compare software changes with the English Wikipedia and with the Dutch Wikipedia, most changes seem to fit exactly like the English Wikipedia and not with the Dutch Wikipedia. So many times it is locally thought and said that a change is likely requested by the English community. Not that we make such big deal of it as we are already used to it, still this is how it is seen by at least some communities. 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] Next steps regarding WMF-community disputes about deployments
On Sun, Sep 7, 2014 at 12:18 PM, Romaine Wiki romaine.w...@gmail.com wrote: 2014-09-06 1:07 GMT+02:00 Steven Walling steven.wall...@gmail.com: On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jay...@gmail.com wrote: IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis. This is rank hyperbole. The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1] Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects. Some examples: I am sure you have tested things out on various wikis, but I can confirm that seeing things been rolled out from a non-English wiki, they multiple times look like if the English community has requested it or has been copied from. One (large) example is the TemplateData part of the VisualEditor which seems to us (nl-wiki) copied from the English Wikipedia, in multiple ways. This is not how we work with templates. IIRC Visual Editor depends on writing TemplateData JSON for all your projects templates, using a mix of local language (parameter descriptions) and English (JSON keywords), which works real well for languages like Arabic and Hebrew. -- 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] Next steps regarding WMF-community disputes about deployments
On 25.08.2014 06:07, Marc A. Pelletier wrote: On 08/24/2014 11:19 PM, Pine W wrote: I have heard people say don't force an interface change on me that I don't think is an improvement. I do not recall a recent interface change deployment that wasn't accompanied with, at the very least, some method of opting out. Did I miss one? -- Marc FLOW? Unless you count leaving the project as opt-out. 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] Next steps regarding WMF-community disputes about deployments
On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote: On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW? Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment. But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless. That also explains the very deliberate development and feedback loop. -- 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
I'm not sure the term loop is appropriate. So far, I see little evidence that feedback provided [1] is making any appreciable difference. [1] https://en.wikipedia.org/wiki/Wikipedia_talk:Flow On Fri, Sep 5, 2014 at 5:34 PM, Marc A. Pelletier m...@uberbox.org wrote: On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote: On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW? Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment. But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless. That also explains the very deliberate development and feedback loop. -- 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
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle: 1) Is the WMF working with the community as closely and substantially as possible to make sure Flow is ready for primetime? 2) Is the community preparing itself for a major change, not only in interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces? I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it. What can we do to make the Flow rollout as smooth as starting '''now'''? ,Wil On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier m...@uberbox.org wrote: On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote: On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW? Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment. But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless. That also explains the very deliberate development and feedback loop. -- 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
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Andreas, what would you do process-wise from the perspective of the WMF and/or the broader community to improve communication and its impact on development of Flow? ,Wil On Fri, Sep 5, 2014 at 10:11 AM, Andreas Kolbe jayen...@gmail.com wrote: I'm not sure the term loop is appropriate. So far, I see little evidence that feedback provided [1] is making any appreciable difference. [1] https://en.wikipedia.org/wiki/Wikipedia_talk:Flow On Fri, Sep 5, 2014 at 5:34 PM, Marc A. Pelletier m...@uberbox.org wrote: On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote: On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW? Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment. But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless. That also explains the very deliberate development and feedback loop. -- 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 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 there have been some pretty strong indications over the years that the current talk page system needs to be improved. However, there's been little discussion at all about whether Flow is that improvement. I have been following the development for quite a while, and it really looks like the system was developed backwards: essential functions for effective discussion that already exist and are used on a daily basis were not included in the initial designs, while the design incorporated plenty of bells and whistles that were considered desirable (although the reasons for desirability weren't necessarily universally held or particularly clear). This has resulted in a huge amount of re-engineering to incorporate (some of the) needed functions , and a lot of downplaying of the feedback given because the feedback has conflicted with the bells and whistles of the original design. There is also the fact that it would add another completely different user interface to the editing process, which increases barriers for existing users but even more so for new users. In other words, the issues with Flow are so deeply rooted in its core design and philosophy that it may not be possible to come up with a product that is actually useful on the projects we have to replace the discussion system we have. It seems that the Flow team has assembled the ingredients to make a chocolate cake with the hope that it will be a suitable replacement for vegetable stew. Risker/Anne On 5 September 2014 13:29, Wil Sinclair w...@wllm.com wrote: This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle: 1) Is the WMF working with the community as closely and substantially as possible to make sure Flow is ready for primetime? 2) Is the community preparing itself for a major change, not only in interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces? I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it. What can we do to make the Flow rollout as smooth as starting '''now'''? ,Wil On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier m...@uberbox.org wrote: On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote: On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW? Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment. But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless. That also explains the very deliberate development and feedback loop. -- 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 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@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
Interesting. What I'm noticing in both this discussion and the discussions around MV is that a lot of us think that the solution has value, but the features are not prioritized well. I don't have much experience with Trello, but I know of lots of other tools (Bugzilla is one, I believe) that can support discussions from the community per feature/bug and have a voting feature. I don't support RfC's on full systems. If we get to this point we've all been doing it wrong for far too long to have an easy fix. But I think that RfC-like discussions on every individual feature make a lot of sense. And I think that one of the biggest steps the WMF can take is to base prioritization of features on such RfC's in a well-defined and well-understood way. IMO, user studies are important, but they'd be better used to '''convince''' the community that something is useful from a perspective that may be very different from a very experienced user's, rather than force features down our throats. I know that this is already happening to some degree. But is the WMF '''obligated''' to prioritize features based on community feedback? As a separate question, would we find it easier to do this onwiki, and are there extensions that we can build with the WMF to facilitate such discussions and feature management? Or we cool with the tools we already have? ,Wil On Fri, Sep 5, 2014 at 10:58 AM, Risker risker...@gmail.com wrote: I think there have been some pretty strong indications over the years that the current talk page system needs to be improved. However, there's been little discussion at all about whether Flow is that improvement. I have been following the development for quite a while, and it really looks like the system was developed backwards: essential functions for effective discussion that already exist and are used on a daily basis were not included in the initial designs, while the design incorporated plenty of bells and whistles that were considered desirable (although the reasons for desirability weren't necessarily universally held or particularly clear). This has resulted in a huge amount of re-engineering to incorporate (some of the) needed functions , and a lot of downplaying of the feedback given because the feedback has conflicted with the bells and whistles of the original design. There is also the fact that it would add another completely different user interface to the editing process, which increases barriers for existing users but even more so for new users. In other words, the issues with Flow are so deeply rooted in its core design and philosophy that it may not be possible to come up with a product that is actually useful on the projects we have to replace the discussion system we have. It seems that the Flow team has assembled the ingredients to make a chocolate cake with the hope that it will be a suitable replacement for vegetable stew. Risker/Anne ___ 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 Sat, Sep 6, 2014 at 3:29 AM, Wil Sinclair w...@wllm.com wrote: This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle: 1) Is the WMF working with the community as closely and substantially as possible to make sure Flow is ready for primetime? ... What can we do to make the Flow rollout as smooth as starting '''now'''? IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis. Risker's assessment of the design problems is spot on. As such, a typical WMF-style big bang deploy of Flow is going to be the most almighty bang the WMF has ever seen. And the community is rightly worried that 2015 is going to be the year that WMF forces Flow onto the projects using its typical deploy methodology. Start development of a rollout plan, and gain consent from the communities on that rollout plan. After rollout on MediaWiki has stablised, Meta-Wiki should be high on the deploy list, as should any wiki which has LQT enabled by community request. Until discussion-focused wikis, such as Meta, universally *likes* Flow, trialling it or rolling it out onto any 'work'/content-focused wiki without community consent is silly. Until it is satisfactorily deployed onto at least one non-English language content project, it shouldnt be deployed onto English Wikipedia, as it is safe to assume that the design will be too English Wikipedia specific, and will fail badly on non-English projects, becoming another WMF tool which looks nice on English Wikipedia but other projects cant have it because it is designed wrong. Allow project level opt-out of the Flow rollout plan. Focus on the projects that want it, and find/employ community advocates with the necessary language skills for the projects at the top of the rollout plan. They need to start work *now*. They need to document existing project workflows, talking with bot operators and site admins especially when developing a migration plan. Bot and gadget software will need to be re-engineered *before* the deploy. -- 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] Next steps regarding WMF-community disputes about deployments
I really don't like the way that people are referring to Flow as a done deal with an inevitable roll out. Nothing remotely close to workable software has been produced, no case has been made that the purported problems being addressed by this top-down software project are valid issues in the community, the range of unintended effects that will be cause by the mass archiving of talk pages and move to a new flashy system hasn't been properly assessed. With Visual Editor, there was a clear need for WYSIWYG capabilities — although the software rolled out was grossly inadequate and the roll out process hamhanded (not to say incompetent). With Media Viewer, at least there is a clear benefit to a certain percentage of WP readers to offset the inconveniences resulting from mildly inadequate software. With Flow we are looking at the potential of grossly inadequate software with no apparent saving graces other than the fact that the old software is old and the new software will be new and that things will look nice. If this is done wrong, it will be a catastrophe for WMF far bigger than what happened with VE. Wil Sinclair, an enthusiast for the LiquidThreads/Flow mechanism for talk pages, is in an excellent position to give us some A/B numbers for participation at his site, with in without LiquidThreads being imposed from above. How did that work out with participation levels at the OffWiki site, Mr. Sinclair? How many very active editors has the convenient LiquidThreads mechanism generated for your site? How many edits have taken place in the month after LiquidThreads was installed over community objections versus the month before it was installed? Has the clean up process been easy reconverting to MediaWiki without the LiquidThreads extension? Bottom line: OffWiki site participation was blown up by a unilateral move to LiquidThreads by the tech department. Observe and learn. Tim Davenport Carrite on WP /// Randy from Boise on WPO Corvallis, OR === Wil Sinclair wrote: This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle: 1) Is the WMF working with the community as closely and substantially as possible to make sure Flow is ready for primetime? 2) Is the community preparing itself for a major change, not only in interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces? I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it. What can we do to make the Flow rollout as smooth as starting '''now'''? ,Wil ___ 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 Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jay...@gmail.com wrote: IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis. This is rank hyperbole. The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1] Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects. Some examples: -- MediaViewer spent a long time being tested outside English Wikipedia before it ever touched that project. It started with pilots in non-English Wikipedias and English Wikivoyage.[3] -- Flow is currently soliciting editors on non-English projects to test it out voluntarily on a sub-set of pages. Any projects that want to help shape the future of this software should pick a discussion space they want to use for testing and speak up. -- My team (Growth) has begun waiting for translations of experimental interfaces, so we can A/B test in many languages simultaneously. We're about to do this again in this month, by testing task recommendations in 12 languages right from the start.[4] We've done with other projects as well, like A/B testing changes aimed at anonymous editors in four languages. -- The Content Translation project is starting with Spanish and Catalan Wikipedias.[5] After we get past the testing stage, none of this erases the fact that English Wikipedia is still the largest project by far, and is a major problem spot to be dealt with regarding issues related to new editor acquisition and retention. The data clearly suggests that it's a project we should be focusing on if we want to fix these problems, but we're certainly not ignoring others. 1). wikitech.wikimedia.org/view/Deployments 2). All technical staff and community contributors share English as their working language. Software gets built in English first obviously, so we don't have to wait on translations as a blocker for deployment. English Wikipedia is also our largest project, so we can get larger randomized samples during A/B tests. Making A/B tests shorter while also retaining accuracy is good. 3). https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan 4). https://meta.wikimedia.org/wiki/Research:Task_recommendations/Experiment_one 5). https://www.mediawiki.org/wiki/Content_translation/Roadmap ___ 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
FWIW, ironically the tangled discussions about MediaViewer across multiple pages have made me think that having a more organized way to read discussions would be a good idea. My understanding is that this is one of Flow's objectives. If Flow can achieve this in a way that is helpful and non-disruptive then I think Flow may save power users time because we may be able to follow multi-page discussions easily. I would appreciate it if Flow helped with that. Of course, the design, implementation and testing need to be done carefully, and I hope there is heavy community involvement in reviewing Flow long before it gets sent to the largest and most sophisticated wikis. Pine On Fri, Sep 5, 2014 at 4:07 PM, Steven Walling steven.wall...@gmail.com wrote: On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jay...@gmail.com wrote: IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis. This is rank hyperbole. The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1] Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects. Some examples: -- MediaViewer spent a long time being tested outside English Wikipedia before it ever touched that project. It started with pilots in non-English Wikipedias and English Wikivoyage.[3] -- Flow is currently soliciting editors on non-English projects to test it out voluntarily on a sub-set of pages. Any projects that want to help shape the future of this software should pick a discussion space they want to use for testing and speak up. -- My team (Growth) has begun waiting for translations of experimental interfaces, so we can A/B test in many languages simultaneously. We're about to do this again in this month, by testing task recommendations in 12 languages right from the start.[4] We've done with other projects as well, like A/B testing changes aimed at anonymous editors in four languages. -- The Content Translation project is starting with Spanish and Catalan Wikipedias.[5] After we get past the testing stage, none of this erases the fact that English Wikipedia is still the largest project by far, and is a major problem spot to be dealt with regarding issues related to new editor acquisition and retention. The data clearly suggests that it's a project we should be focusing on if we want to fix these problems, but we're certainly not ignoring others. 1). wikitech.wikimedia.org/view/Deployments 2). All technical staff and community contributors share English as their working language. Software gets built in English first obviously, so we don't have to wait on translations as a blocker for deployment. English Wikipedia is also our largest project, so we can get larger randomized samples during A/B tests. Making A/B tests shorter while also retaining accuracy is good. 3). https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Release_Plan 4). https://meta.wikimedia.org/wiki/Research:Task_recommendations/Experiment_one 5). https://www.mediawiki.org/wiki/Content_translation/Roadmap ___ 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
On Sat, Sep 6, 2014 at 9:07 AM, Steven Walling steven.wall...@gmail.com wrote: On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg jay...@gmail.com wrote: IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis. This is rank hyperbole. Oh, I love you too. The MediaWiki deployment train delivers new software to all projects every week. One stage is to non-Wikipedia projects, which actually get new software *first.* Then in a second stage is for all Wikipedias simultaneously. So the default behavior for rollouts, if all you do is merge your code and wait, is that English Wikipedia gets basically no special treatment..[1] That is unrelated; I am talking about 'features', which you address below... Now, for larger feature rollouts like VisualEditor or MediaViewer, the testing stage and eventual launch set their own special schedule. We have used English Wikipedia as a testing ground a lot in the past, which is natural when you consider a variety of factors.[2] That doesn't mean we haven't worked hard to test things out with non-English projects. I urge the WMF to rethink using English Wikipedia as their testing ground, as using it as the natural choice results in 'bad' designs and community engagement around deployment. One of the more recent WMF products: https://www.mediawiki.org/wiki/Extension:PageTriage An important note is that some of the configuration and code is specific to the English-language Wikipedia's workflows and as it's constructed now the extension is pretty much impossible to internationalize: developing a universal, stripped-down version is on our to-do list. (See bugzilla:48552.) [bugzilla 48552 was created May 2013, and prioritised as Lowest by James Forrester, and no change since.] A lot of what I am suggesting is found in: https://meta.wikimedia.org/wiki/User:Okeyes_(WMF)/Localising_page_curation Flow is going to be a very major deploy. Do not make decisions about that deployment based on which language your engineers use at the water cooler or in commit messages. Employ the right people now to assist in a gradual deploy to communities that are ready for the pain involved. My guess is the English Wikipedia community would prefer to know that Flow has been accepted on quite a few projects before it commences any migration. But maybe I am wrong; maybe that community will want to be a testing ground. Will you ask them? -- 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] Next steps regarding WMF-community disputes about deployments
On 5 September 2014 17:25, John Mark Vandenberg jay...@gmail.com wrote: One of the more recent WMF products: https://www.mediawiki.org/wiki/Extension:PageTriage An important note is that some of the configuration and code is specific to the English-language Wikipedia's workflows and as it's constructed now the extension is pretty much impossible to internationalize: developing a universal, stripped-down version is on our to-do list. (See bugzilla:48552.) [bugzilla 48552 was created May 2013, and prioritised as Lowest by James Forrester, and no change since.] As a quick note, I prioritised it on behalf of the team who owned the product based on asking them; it's not my product, so it's not my call as to what the priority should be… J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ 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
Actually, Tim, you're not giving me credit for all the other mistakes I made. :D FWIW, lessons have been learned, and there is a new version in the works. But many people on this list have specifically said that they don't want to talk about Offwiki, and we should respect their wishes. I did make a big mistake that's relevant to this thread when I deployed Liquid Threads on a project that shall remain nameless ;): I didn't look in to it enough to know that it would essentially take over all talk pages. I thought I had sandboxed it on a single page. I accidentally surprised my users with it, and they did not like it. I think there is a lot of value and promise in Flow. But it is a huge paradigm shift for onwiki communication, and it must not surprise users under any circumstances. Maybe someone has the right figure handy, but I wouldn't be surprised if, after archives are added up, there is more discussion across all wikis than content. If so, one might argue that this is a bigger change than VE and it certainly dwarfs the impact that most editors experience from the MV rollout. The WMF '''must''' get this one right. And that's not possible without our help. When I see that a problem I care about needs to be solved, my first question is what can I do to help? Telling others what they can do is just too easy; after all, it's not like I commit to making an effort in doing so. So, starting with myself, I'd say the first step is figuring out what the community's expectations are in building and rolling out the release. How can I help prevent the WMF's simply making a death march to a debacle by ignoring our expectations? Maybe organizing our thoughts might help. Here's a start to a list based on stuff I've read here so far: 1) The WMF should not only involve the community in setting feature priority, but commit to honoring community sentiment when it is expressed overwhelmingly on any given feature. A very rough example would be something like if there are 250 more increase priority votes than decrease priority votes, the feature would be bumped up. 2) Priorities should be fully transparent to the community, and they should mean something. For example, all must-haves must be implemented before any should-haves are worked on. 3) User studies should be invoked to convince the community that something is of value to users who may not have as much experience, and not offered as an excuse while shoving features down the community's throat. 4) (My own addition, here) A mechanism to make it easy to gather community feedback and quantify community sentiment '''in one place per feature''' should be set up. No hopping from onwiki to bugzilla to trello to whatever the WMF engineering team decides they want to use next. If the WMF wants to use a new tool, it should integrate with the toolset we're already used to IMO so that information doesn't get lost behind links. ,Wil On Fri, Sep 5, 2014 at 2:43 PM, Tim Davenport shoehu...@gmail.com wrote: I really don't like the way that people are referring to Flow as a done deal with an inevitable roll out. Nothing remotely close to workable software has been produced, no case has been made that the purported problems being addressed by this top-down software project are valid issues in the community, the range of unintended effects that will be cause by the mass archiving of talk pages and move to a new flashy system hasn't been properly assessed. With Visual Editor, there was a clear need for WYSIWYG capabilities — although the software rolled out was grossly inadequate and the roll out process hamhanded (not to say incompetent). With Media Viewer, at least there is a clear benefit to a certain percentage of WP readers to offset the inconveniences resulting from mildly inadequate software. With Flow we are looking at the potential of grossly inadequate software with no apparent saving graces other than the fact that the old software is old and the new software will be new and that things will look nice. If this is done wrong, it will be a catastrophe for WMF far bigger than what happened with VE. Wil Sinclair, an enthusiast for the LiquidThreads/Flow mechanism for talk pages, is in an excellent position to give us some A/B numbers for participation at his site, with in without LiquidThreads being imposed from above. How did that work out with participation levels at the OffWiki site, Mr. Sinclair? How many very active editors has the convenient LiquidThreads mechanism generated for your site? How many edits have taken place in the month after LiquidThreads was installed over community objections versus the month before it was installed? Has the clean up process been easy reconverting to MediaWiki without the LiquidThreads extension? Bottom line: OffWiki site participation was blown up by a unilateral move to LiquidThreads by the tech department. Observe and learn. Tim Davenport Carrite on WP /// Randy from Boise on WPO
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Risker, what do you think might get us all back on track for Flow? Should the WMF consider a reset of the project and proceed only after making specific and enforceable commitments to work with the community? Is a total rewrite in order? Should we go completely tabla rasa on it and revisit whether we need something like this at all? ,Wil On Fri, Sep 5, 2014 at 10:58 AM, Risker risker...@gmail.com wrote: I think there have been some pretty strong indications over the years that the current talk page system needs to be improved. However, there's been little discussion at all about whether Flow is that improvement. I have been following the development for quite a while, and it really looks like the system was developed backwards: essential functions for effective discussion that already exist and are used on a daily basis were not included in the initial designs, while the design incorporated plenty of bells and whistles that were considered desirable (although the reasons for desirability weren't necessarily universally held or particularly clear). This has resulted in a huge amount of re-engineering to incorporate (some of the) needed functions , and a lot of downplaying of the feedback given because the feedback has conflicted with the bells and whistles of the original design. There is also the fact that it would add another completely different user interface to the editing process, which increases barriers for existing users but even more so for new users. In other words, the issues with Flow are so deeply rooted in its core design and philosophy that it may not be possible to come up with a product that is actually useful on the projects we have to replace the discussion system we have. It seems that the Flow team has assembled the ingredients to make a chocolate cake with the hope that it will be a suitable replacement for vegetable stew. Risker/Anne On 5 September 2014 13:29, Wil Sinclair w...@wllm.com wrote: This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle: 1) Is the WMF working with the community as closely and substantially as possible to make sure Flow is ready for primetime? 2) Is the community preparing itself for a major change, not only in interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces? I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it. What can we do to make the Flow rollout as smooth as starting '''now'''? ,Wil On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier m...@uberbox.org wrote: On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote: On 25.08.2014 06:07, Marc A. Pelletier wrote: FLOW? Last I checked, Flow isn't deployed except as experiments in a handful of places, and is still in active deployment. But you're correct that this would constitute a replacement rather than a new method alongside the old. A long, long overdue and desperately needed replacement -- but a replacement nonetheless. That also explains the very deliberate development and feedback loop. -- 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 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@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,
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Wil, the tl;dr here is Philosophical beliefs aren't an effective underpinning for good software design. Start over. It's taken me a while to piece together much from the early discussions about Flow and figure out how we got to where we are now. It's my opinion that the root of the problem is that, much as the WMF wants to move toward being a software or tech organization, it really doesn't have very much history or experience in the kind of ground-up software design and deployment that is conducive to successful implementation. Tech organizations seeking to redevelop a core function normally start by gathering extensive data on the current system, identifying key functions that must be incorporated into the new system, understanding how the current system is used, what its strengths and weaknesses are, and ensuring that even early iterations will at least include the key functions and strengths from the soon-to-be-deprecated system. This baseline background research was never really done before investing in the development of Flow. Instead, Flow very much comes across as software being designed according to philosophical principles rather than function. The major deficiencies that have long been identified in the current discussion system (and that can be addressed by technology) are all able to be addressed in MediaWiki software or by extensions. Automatic signatures have been done by bots for years; indenting could be added to the editing function gadget and moved to an extension; much work has already been done on graceful resolution of edit conflicts. The ability to watchlist an individual thread or section of a page is more challenging but, I have been told, still possible. Several of the features identified as must-do have turned out not to quite work out. Automatic signature (something that is currently functional on Flow, but is not customizable) turns out to be more of a challenge when users are widely known by a signature line that doesn't match their username, and there is no method by which users can add an explanatory note to their signature such as formerly known as User:Whatever. The more efficient indenting has reduced possible indents to three levels, without exception; even in simple discussions, it's pretty clear that hasn't really worked out as it's often difficult to figure out who is responding to which post. Rigid predictable technical restrictions on who can edit what has resulted in inability to remove posts that are obviously unsuitable (there's no undo or revert function), replaced with a hide function that can only be applied by certain users that's practically a red flag for people to look-see what the problem edit is. With broader early discussion, some of these would probably have been fleshed out before getting this far. At the core is whether or not there is value in developing a discussion system that is radically divorced from any other interface used by the system. This is a philosophical question, and doesn't actually have that much to do with technology - and this conversation has never really taken place anywhere but by a bunch of guys who are into making cool software and, often as not, have little interest in the kinds of discussions that normally occur on Wikimedia projects. There has certainly never really been a discussion with the broader community about what would better serve in discussions. More importantly, some of the core assumptions and goals upon which Flow has been built[1] have very little to do with technology at all - plenty of research indicates that new users are driven away by the nature of discussions rather than the technological challenges of participation - and the lack of active broad community consultation means that the development team really doesn't know what's working well, what's problematic, and what kind of efficiencies experienced users are looking for. There's absolutely no basis to believe that Flow is in any way likely to encourage [more] *meaningful conversations* that support collaboration. (I'd love to see what kind of metrics would be used to assess the meaningfulness of conversations!) And the other key issue is a complete lack of recognition that the more UIs a new user needs to learn to develop competency, the lower the likelihood that they'll actually be able to develop the necessary skills to become fully functioning members of the editing community. The Wikimedia family has largely bought in to the necessity to introduce a WYSIWYG editing interface (that would be VisualEditor), and to recognize that wikitext editing needs to remain in existence as well. Adding a third one whose primary purpose will be to talk about the content being created using the other two is counterintuitive at best. Risker/Anne [1] https://www.mediawiki.org/wiki/Flow On 5 September 2014 21:53, Wil Sinclair w...@wllm.com wrote: Risker, what do you think might get us all back on track for Flow? Should the WMF
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Hoi, Maybe... but it assumes that we have plenty of time and work sequently. Both are not the case and as it is, the framework is broken.to the extend that people refuse to use it. So yes, ideally you want to fix many issues nicely and in a collaborative manner. At the same time our readers are disappearing from our old platform and new editors are not happening on the old platform. The question is very much to what extend we can suffer all the baggage and backlog from the past. The question is very much what to do when we do not have that 80% on a subject that stops other developments. Thanks, GerardM On 3 September 2014 21:58, Isarra Yos zhoris...@gmail.com wrote: On 02/09/14 11:46, Marc A. Pelletier wrote: On 09/02/2014 02:52 AM, Yann Forget wrote: OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth? In the best of worlds, that would have been ideal. Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single references/ onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario. I have. It's a lot of work to set up and keep on track, and can take a goodly long while to get going at all, but when it succeeds, it's totally AWESOME. Wasn't on Wikimedia, but should be totally doable here, too, provided the time, energy, and utter insanity required. Principles are the same. -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 ___ 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, Maybe... but it assumes that we have plenty of time and work sequently. Both are not the case and as it is, the framework is broken.to the extend that people refuse to use it. So yes, ideally you want to fix many issues nicely and in a collaborative manner. At the same time our readers are disappearing from our old platform and new editors are not happening on the old platform. Open source has a lot of benefits. Delivering quality software '''on a schedule''' is not one of them. But it can be done. We did it with Zend Framework with quarterly major releases. We also turned community sentiment around after the negative reaction to 1.0, which was released right before I joined Zend. I'd say that the most impactful thing we did to right the ship was hearing people out wherever they chose to discuss ZF. We monitored all channels of communication and responded to frustrations as quickly as possible. Most of our comments boiled down to: You're right. We have a problem here. Will you help us fix it? In other words, we made sure we walked the walk so that we could invite others to walk with us. And the constructive critics figured out that walking is more fun/satisfying than all the talking. Of course, that meant we walked away from some critics who weren't interested in being constructive. We never looked back. I believe this community can also turn all this dysfunction and stress in to something positive. So, let's start walking; here's a proposal/challenge for those who think Media Viewer isn't worthy: Take all that time you're investing in petitioning the community and use it to build something better than Media Viewer. A lot of you have already identified pain points in MV and some solutions have also been put forward; so, if you are not planning to get involved in the project that the WMF has set up for whatever reasons, join us in building what Media Viewer should be without the complications of dealing with the WMF. If it turns out to be a better solution than Media Viewer, then I suggest we create a petition to replace MV with the community's solution. That's the kind of positive, action-oriented petition I can sign. I'll even kick it off. We can start listing the requirements for the Worthy Media Viewer on this page: https://meta.wikimedia.org/wiki/WorthyMV. So, who's ready to walk? ,Wil ___ 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
Hi, Thanks for your message. I think it is honest and useful. 2014-09-01 20:40 GMT+05:30 Marc A. Pelletier m...@uberbox.org: ... 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. OK, I could buy that. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth? How is it that the old saying goes? 'We've always done things this way' is the most dangerous statement in any language? -- Marc Regards, Yann ___ 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/02/2014 02:52 AM, Yann Forget wrote: OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth? In the best of worlds, that would have been ideal. Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single references/ onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario. Perhaps the problem is more fundamental than this, and we're only seeing symptoms. I don't know. But I /do/ know that waiting until every edge case is handled before deploying (attempted) improvements to the site is doomed to failure. If only because most of the edge case won't even be /findable/ until the software is in place so that it can't work even in principle. IMO, in practice, get it working for the general case and most of the obvious edge cases is a reasonable standard; and I'm pretty sure that MV qualified under that metric (and VE didn't). I suppose much of my frustration over the MV keruffle is borne out of a reaction I see much too often for my taste: editors yelling OMG, look, image X isn't properly attributed/licensed/etc in MV! Burn it with fire!!! rather than figuring out why X's image page isn't properly parsed and /fixing/ it (and possibly an underlying template that could fix dozen/hundred others in one fell swoop).I'm pretty sure that if half as much effort had been spent fixing issues as was attempting to kill MV, its fail rate would already be at statistical anomaly levels. .. but my inner cynic is also pretty sure that many of the loudest voices wanting to get rid of MV ostensibly because of its failings don't actually /want/ those failings to be fixed because being able to say It's broken rather than I don't like it sounds much more rational. -- 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
I don't think people yell MediaViewer is broken as much as they yell MediaViewer broke my workflow!. The problem is that no one cares about some editor's personal workflow, so maybe we should be documenting use cases that could be used for new old editors and developers alike On Tue, Sep 2, 2014 at 7:46 AM, Marc A. Pelletier m...@uberbox.org wrote: On 09/02/2014 02:52 AM, Yann Forget wrote: OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth? In the best of worlds, that would have been ideal. Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single references/ onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario. Perhaps the problem is more fundamental than this, and we're only seeing symptoms. I don't know. But I /do/ know that waiting until every edge case is handled before deploying (attempted) improvements to the site is doomed to failure. If only because most of the edge case won't even be /findable/ until the software is in place so that it can't work even in principle. IMO, in practice, get it working for the general case and most of the obvious edge cases is a reasonable standard; and I'm pretty sure that MV qualified under that metric (and VE didn't). I suppose much of my frustration over the MV keruffle is borne out of a reaction I see much too often for my taste: editors yelling OMG, look, image X isn't properly attributed/licensed/etc in MV! Burn it with fire!!! rather than figuring out why X's image page isn't properly parsed and /fixing/ it (and possibly an underlying template that could fix dozen/hundred others in one fell swoop).I'm pretty sure that if half as much effort had been spent fixing issues as was attempting to kill MV, its fail rate would already be at statistical anomaly levels. .. but my inner cynic is also pretty sure that many of the loudest voices wanting to get rid of MV ostensibly because of its failings don't actually /want/ those failings to be fixed because being able to say It's broken rather than I don't like it sounds much more rational. -- 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
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
I generally agree with your analysis Marc, notwithstanding that there is blame to share on all sides - not just users who point to broken edge cases. The (quite predictable) behaviour you mention is why I was quite fond of the way the usability initiative from several years ago (the team that built the Vector skin) operated. They made it very easy to opt-in AND out of the beta version of their work. They also made it very clear that when the proportion of people who stayed in reached a certain level (If I recall correctly it was 80% and certainly not 95%+), that would signal that the software had reached a certain level of acceptance, and that a sufficient number of edge-cases had been addressed. Until that point they would focus on working with the people who has tried the beta but had turned it OFF, to identify their personal edge cases - in the hope this would fix other people's problems. Much like you described. The key here in my opinion is: - clear communication about what state constitutes success (e.g. When 80% of people who have opted in have STAYED opted-in) - clear communication about the progress towards that state (e.g. Showing the success factor in the little statistics on the beta features tab, and showing how close we are to that.) - only moving to the next stage when that state has been reached, (not a fixed schedule but it is ready when it is ready, not before) - making it easy to try, and withdraw from, new things, always starting with opt-in before making it opt-out. Since the usability initiative there has now been introduced the beta preferences function for editors to test new software and provide feedback. I would like to see this used more consistently and with more clarity about what stage of beta the individual elements within that system are at. Currently all I know is that there is a list of items and that there is an absolute number of users for each item (e.g. 1,234 people are using this.) Would it be difficult to make it show what proportion of people who have tried any given beta feature are STILL using it? That would give an indicator of popularity/acceptance at least. -Liam / Wittylama. On Tuesday, 2 September 2014, Marc A. Pelletier m...@uberbox.org wrote: On 09/02/2014 02:52 AM, Yann Forget wrote: OK, I could buy that [fixing image pages]. But then why not fixing that *first*, so that any MV implementation coming afterwards would be smooth? In the best of worlds, that would have been ideal. Now, no doubt I'm going to be branded a cynic for this, but have you ever /tried/ to standardize something on a project? Obviously, my frame of reference is the English Wikipedia and not Commons; but in a world where there exists at least six distinct templates whose primary function is to transclude a single references/ onto a page and where any attempt to standardize to one of them unfailingly results in edit wars, that doesn't seem like a plausible scenario. Perhaps the problem is more fundamental than this, and we're only seeing symptoms. I don't know. But I /do/ know that waiting until every edge case is handled before deploying (attempted) improvements to the site is doomed to failure. If only because most of the edge case won't even be /findable/ until the software is in place so that it can't work even in principle. IMO, in practice, get it working for the general case and most of the obvious edge cases is a reasonable standard; and I'm pretty sure that MV qualified under that metric (and VE didn't). I suppose much of my frustration over the MV keruffle is borne out of a reaction I see much too often for my taste: editors yelling OMG, look, image X isn't properly attributed/licensed/etc in MV! Burn it with fire!!! rather than figuring out why X's image page isn't properly parsed and /fixing/ it (and possibly an underlying template that could fix dozen/hundred others in one fell swoop).I'm pretty sure that if half as much effort had been spent fixing issues as was attempting to kill MV, its fail rate would already be at statistical anomaly levels. .. but my inner cynic is also pretty sure that many of the loudest voices wanting to get rid of MV ostensibly because of its failings don't actually /want/ those failings to be fixed because being able to say It's broken rather than I don't like it sounds much more rational. -- 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 javascript:; ?subject=unsubscribe -- wittylama.com Peace, love metadata ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe:
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On Mon, Sep 1, 2014 at 11:44 AM, Fæ fae...@gmail.com wrote: 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? More than that, we should actually have the license data (and other stuff like attribution and descriptions) in a Wikidata-like structure instead of messing with parsing templates at all. The page for that is https://commons.wikimedia.org/wiki/Commons:Structured_data. Please do participate in that process. That really should have been done first instead of the CommonsMetadata extension, in my personal opinion. ___ 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/02/2014 10:35 AM, Liam Wyatt wrote: The key here in my opinion is: - clear communication about what state constitutes success (e.g. When 80% of people who have opted in have STAYED opted-in) - clear communication about the progress towards that state (e.g. Showing the success factor in the little statistics on the beta features tab, and showing how close we are to that.) - only moving to the next stage when that state has been reached, (not a fixed schedule but it is ready when it is ready, not before) - making it easy to try, and withdraw from, new things, always starting with opt-in before making it opt-out. This sounds sane indeed. +1 from me, at the very least. Note how VE did pretty much the opposite of that, and that was a disaster (the rollout, not VE itself). -- 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 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 Wikimedia-l
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
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:
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Hi all, Thank you Erik for your mail. It shows that the WMF is willing to discuss rather than to impose its solution. I am really shocked that the dispute reaches that level of confrontation, and although some community members have a hard stance, this is largely due to WMF actions, specially the creation of the superprotect right. This is the worst possible step the WMF could make to find a solution for this issue. Initially I was quite neutral about the MediaWiever, but I became increasingly skeptical. IMO it is hardly a priority, even for readers. Even if I am a long term contributor of Wikimedia projects, I am also a heavy reader of Wikipedia. I think that if a feature is refused in masse for the most active contributors, there is something wrong either in the feature itself, or in the way it is proposed to the projects. The WMF can certainly bring useful new additions in term of software development, but the implementation has to be done in a partnership with volunteer contributors. I cannot understand that the WMF in spite of its multi-million dollars budget is not able to convince volunteer contributors that the new feature is beneficial to the projects, either because it is technically very good, or that even with some shortcomings, it would improve the reading experience. I am quite willing to test beta software, and I think there is no urgency to impose the MediaWiever now to everybody. I could be done after some time, when all issues have been sorted out. In term of media management, the most urgent and important thing is to fix the UploadWizard. Viewing images with Mediawiki may not be optimal, but it is not broken. The UploadWizard is broken. Regards, Yann 2014-08-20 0:42 GMT+05:30 Erik Moeller e...@wikimedia.org: Hi folks, This is a response to Martin's note here: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html .. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward. I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it. I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page. Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a better hack to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint. Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer. We’ve been listening to feedback, and we’ve come to the following conclusions: - We intend to undertake a review of our present processes immediately and propose a new approach that allows for feedback at more critical and relevant junctures in the next 90 days. This will be a transparent process that includes your voices. - As the WMF, we need to improve the process for managing changes that impact all users. That includes the MediaWiki: namespace. For WMF to fulfill its role of leading consistent improvements to the user experience across Wikimedia projects, we need to be able to review code and manage deployments. This can be done in partnership with trusted volunteers, but WMF needs to be able to make an ultimate determination after receiving community feedback regarding production changes that impact all users. - We are prepared to unprotect MediaWiki:Common.js on German Wikipedia and enter constructive, open-ended conversations about the way forward, provided we can mutually agree to do so on the basis of the current consistent configuration -- for now. We would like to request a moratorium on any attempts to disable the feature during this conflict
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Legal position: I have seen it claimed by legal and repeated here by Erik that the reasonableness criteria means that we do not have to worry about the CCBYSA-3.0 clause that says all copyright holders need equal attribution. This is simply not so: The credit required by this Section 4(c) may be implemented *in any reasonable manner; provided, however, that *in the case of a Adaptation or Collection,* at a minimum such credit will appear*, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and* in a manner at least as prominent as the credits for the other contributing authors*. There is no wriggle room here. * provided however that* means the following is compulsory, and not subject to the lenience of the previous phraseology. On 31 August 2014 16:59, Yann Forget yan...@gmail.com wrote: Hi all, Thank you Erik for your mail. It shows that the WMF is willing to discuss rather than to impose its solution. I am really shocked that the dispute reaches that level of confrontation, and although some community members have a hard stance, this is largely due to WMF actions, specially the creation of the superprotect right. This is the worst possible step the WMF could make to find a solution for this issue. Initially I was quite neutral about the MediaWiever, but I became increasingly skeptical. IMO it is hardly a priority, even for readers. Even if I am a long term contributor of Wikimedia projects, I am also a heavy reader of Wikipedia. I think that if a feature is refused in masse for the most active contributors, there is something wrong either in the feature itself, or in the way it is proposed to the projects. The WMF can certainly bring useful new additions in term of software development, but the implementation has to be done in a partnership with volunteer contributors. I cannot understand that the WMF in spite of its multi-million dollars budget is not able to convince volunteer contributors that the new feature is beneficial to the projects, either because it is technically very good, or that even with some shortcomings, it would improve the reading experience. I am quite willing to test beta software, and I think there is no urgency to impose the MediaWiever now to everybody. I could be done after some time, when all issues have been sorted out. In term of media management, the most urgent and important thing is to fix the UploadWizard. Viewing images with Mediawiki may not be optimal, but it is not broken. The UploadWizard is broken. Regards, Yann 2014-08-20 0:42 GMT+05:30 Erik Moeller e...@wikimedia.org: Hi folks, This is a response to Martin's note here: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html .. and also a more general update on the next steps regarding disputes about deployments. As you may have seen, Lila has also posted an update to her talk page, here: https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together I want to use this opportunity to respond to Martin's and other people's criticisms, and to talk about next steps from WMF’s perspective following discussions with Lila and the team. I’m also sending a copy of this note to all the stewards, to better involve them in the process going forward. I am -- genuinely -- sorry that this escalation occurred. We would have preferred to avoid it. I would like to recap how we find ourselves in this situation: As early as July, we stated that the Wikimedia Foundation reserves the right to determine the final configuration of the MediaViewer feature, and we explicitly included MediaWiki: namespace hacks in that statement. [1] When an admin implemented a hack to disable MediaViewer, another local admin reverted the edit. The original admin reinstated it. We then reverted it with a clear warning that we may limit editability of the page. [2] The original admin reinstated the hack. This is when we protected the page. Because all admins have equal access to the MediaWiki: namespace, short of desysopping, there are few mechanisms to actually prevent edit wars about the user experience for millions of readers. Desysopping actions could have gotten just as messy -- and we felt that waiting for a better hack to come along (the likeliest eventual outcome of doing nothing) or disabling the feature ourselves would not be any better, either from a process or outcome standpoint. Our processes clearly need to be improved to avoid these situations in the future. We recognize that simply rejecting a community request rather than resolving a conflict together is not the right answer. We’ve been listening to feedback, and we’ve come to the following conclusions: - We intend to undertake a review of our present processes immediately and propose a new approach that allows for feedback at more critical and relevant junctures in
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
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 ___ 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, Once people decide to leave, the situation is quite stark. There are those that do and there are those that do not. In my previous mail it should have been clear that I described the situation after the departure of many malcontents. That IS a bi-polar state obviously. That is not to say that the desktop is not important. That is not to say that the tooling people use for advanced tasks is not important. The point is very much that in a changing environment, tools that rely on a stable environment are not stable by definition.You cannot insist on such stability either. You cannot even insist that the tools that are usable are well designed and easily adaptable to change. Take for instance gadgets. A successful gadget it copied from Wiki to Wiki and in the process it needs to be localised and preferably it should take advantage of any future development. Work has been done to accomplish internationalisation and a more centralised development model. Once this is finished one gadget may exist on hundreds of wikis. That is a maintenance scenario. Another disaster (IMHO) is that the wikidatafication of Commons is NOT the wikidatafication of multi-media files. The point is NOT that Commons needs to be done first, the point is that once Commons is done, all other Wikis who have local uploads of multi-media files need to be wikidatified as well. There is NO reason why the result of the compromises reached in the Commons process will obviously fit elsewhere.When it is clear from the start that Commons is ONLY the first to be wikidatified, there is a better chance of getting involvement from people who feel strongly about the reasons why their Wiki does not upload to Commons. Their involvement will be a reality check to the Commoners that their POV is exactly that. The Multimedia Viewer did a good job at showing the extend to which local edge cases like the German templates Fabrice mentioned in a recent list of accomplishments pose problems for central development. They exist, they need to be fixed and preferably only once. If not they will change in the future again. Several volunteers like Roan became employees of the WMF exactly because they were pivotal in the dissemination of technology. When you look at the work they do, bringing thing back together IS one aspect of their accomplishments. Things will break and when we do not want drama again and again, we need to embrace change and accept that particularly high end tools will break down regularly. My experience at Labs shows exactly that and it shows that as things get better organised downtime becomes less of an issue. It also shows that as our environment becomes more stable, the tools become more sophisticated and consequently more in need of a well architected environment. What we have is the old problem of retro fitting architecture where chaos reigned supreme. We can do this and this we is most definitely an invitation to every Wikimedian. Thanks, GerardM On 28 August 2014 14:50, ; ) b...@gmx.at wrote: Hey Jane, as the desktop is sometimes characterised only as a legacy input device for old power editors, while the reading is done from mobile devices, often in the form of mash-ups and geo-apps, why is a compromise so hard to achieve? One solution that pops up would be to cache the content (as most useful wikipedia apps do anyway) in a light mobile version, while allowing an existing group of useful contributors their little island. This feeling of belonging makes those editors do all the dirty jobs noone wants to do on a regular basis - most of it fact and copyright checks that make the content so good it is useful to readers and keeps them coming back. You could create a newbie-friendly version with rich text editing optimised for different devices, more customisation in an easy way... if we are realistic that would be the way to go anyway, as you can start out much easier and with less baggage - and would be able to target groups on an individual basis in the process, too. When they evolve in the (bitter-vet) power users and editors, they can switch to the still more useful but less pretty interfaces for large data manipulation, that the desktop offers. Shouldn't the focus be on the readers that read the content AND the editors that produce interesting content to make readers come back? Gerard in this regard seems to have a somehow bi-polar view of this process with his us - them characterisation (the community that remains with the WMF will lose all of the separatists). They will just no longer do the hard stuff, if they feel that they are not welcome - and finding such people is hard, really hard (speaking as a long-term gutenberg proof-reader). cheers, g Thursday, August 28, 2014, 1:56:38 PM, you wrote: I agree with Gerard, and would add that a good portion of the new
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On 8/28/14, 2:55 PM, Jane Darnell wrote: You can start by asking around in your own circle of aquaintance, and I'll bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know are married and though their household contains a desktop, the desktop is owned and operated by their husband, not them. This kind of analysis varies quite widely by country and community, so I would be wary of making wide generalizations. You say that most of the women I know are married, but your experience would be unusual here (Denmark), because the hard statistics show that most adult women (and men) in the country are not married. Clearly other countries' statistics (and statistics for demographic subsets of the same) will show other numbers. Best, 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] Next steps regarding WMF-community disputes about deployments
On 30/08/2014, Mark delir...@hackish.org wrote: On 8/28/14, 2:55 PM, Jane Darnell wrote: You can start by asking around in your own circle of aquaintance, and I'll bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know are married and though their household contains a desktop, the desktop is owned and operated by their husband, not them. This kind of analysis varies quite widely by country and community, so I would be wary of making wide generalizations. You say that most of the women I know are married, but your experience would be unusual here (Denmark), because the hard statistics show that most adult women (and men) in the country are not married. Clearly other countries' statistics (and statistics for demographic subsets of the same) will show other numbers. Best, Mark I know widowers, unmarried people and same-sex married couples and almost no heterosexual married couples; hetero marriage seems a lot less popular these days. All the women I know either have their own machine or are uninterested in accessing the internet. I honestly cannot think of any women in my circle of friends and acquaintances that rely on a husband or partner to access the internet, it is something I would find truly weird and would worry that the husband was being over-controlling. Though I have one friend that relies on free public internet for his access for cost reasons. I have a relative stuck long term in a London hospital where they charge her 7 quid a day for internet access, which she cannot afford so she relies on visitors to do stuff on the internet and will spend her days reading books instead; I find that particularly shocking and I have never heard of Wikimedia being a champion for the right to free internet in hospitals - in the 1st world, that should be a lot easier to negotiate than the internet zero stuff in the developing world. 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
WMF update: https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov_(WMF)diff=9665238oldid=9664457 Gerard, I agree that a forked wiki could have collaborations with WMF. But having separate hosting and legal ownership would create new headaches and risks. I hope WMF takes a cooperative and democratic approach so that we can work in harmony without forking. There will almost always be people unhappy with major decisions. We should aim for consensus, not necessarily unanimous decisions. Recently it seemed to me that the consensus was leaning toward beginning a fork for at least DEWP. This is not a small subset of people who are upset with WMF. Perhaps someone can explain what is so alarming about our readership stats and how MV is likely to improve our readership stats. To me the disappointing active editor stats are the biggest worry. Thanks, Pine On Aug 26, 2014 3:14 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Actually the issue is no longer only that. It is also very much about how a subset of people high jack the conversation by their uncompromising stance. When they feel they might leave, I personally prefer it when they stop their posturing and decide either way. When they want to stay, they do not need to be welcomed, they are part of us. When they go, they are welcome and they can take with them everything we have in the sense of data and software. It is then for them to show that their proof is in their pudding. In the mean time WMF will continue to engage in best practices both technically and socially and when they cook something nice, what is on offer is there for the eating as well. As far as I am concerned, put up or shut up. It has been advertised widely that bugs will be squashed. It is also advertised widely that changes will be considered as long as they are reasonable and do not interfere with our prime directive. Again, it is about the readers not super users. Thanks, GerardM On 25 August 2014 11:16, Pine W wiki.p...@gmail.com wrote: The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also the matter of licensing information. I'm not aware of where thermonuclear was was threatened. There were, and continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production and made default. That needs to be addressed, and the fact that the problems with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her to transform WMF and I am glad that there seems to be agreement that Product will be an early subject of transformation. I have reservations about forking for reasons that I can explain if necessary. It would be a lot easier if WMF would transform itself, starting with Product, and Lila appears to intend to make this happen. I hope that the processes for Product will be democratic and consensus-based. Grantmaking has already demonstrated the effectiveness of community-based decision making with FDC and IEGCom, and I hope to see a similar model emerge for Product. If it doesn't, there is enough anger in the community, especially on DEWP, that a fork is possible. The community is smart enough collectively to figure out a way to make a fork happen, and some of us have been discussing the mechanics of how this would work. We could do it, but reforming WMF is preferable. I hope that Lila can and will do this. Internal transofmration is preferable to replacing WMF. Pine ___ 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 https://meta.wikimedia.org/wiki/Mailing_lists/guidelineswikimedi...@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, Such separate hostings and ownership would not be that much of a risk to the WMF. The challenges will be first and foremost with the separatists; then again it is firmly their choice. There will be benefits on both sides as well. The community that remains with the WMF will lose all of the separatists and they will sadly see some of them go. It will allow for the influx of new people and new ideas. The people that go will get a reality check; they will find out to what extend the things they fought battles over are actually worth it. I am sure that both communities will benefit. When the people who talk about going their own way rethink their stance and start considering the other side of the coin it may lead to an equilibrium. However, the Visual Editor is not the only thing that will change the look and feel there is so much more happening and at that, a single community only considering its own is in effect a cul de sac. When numbers of readers are to be our main worry, it should be obvious by now that both for editing and reading they are happening on the mobile, the tablet. This is were our new readers are happening. Maybe not necessarily in Europe but certainly in the global south. They have by definition a different mode of operandi and consequently much of our current bickering is only distracting from putting our efforts in welcoming our newbies and building a full fledged environment for them. Thanks, GerardM On 28 August 2014 09:34, Pine W wiki.p...@gmail.com wrote: WMF update: https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov_(WMF)diff=9665238oldid=9664457 Gerard, I agree that a forked wiki could have collaborations with WMF. But having separate hosting and legal ownership would create new headaches and risks. I hope WMF takes a cooperative and democratic approach so that we can work in harmony without forking. There will almost always be people unhappy with major decisions. We should aim for consensus, not necessarily unanimous decisions. Recently it seemed to me that the consensus was leaning toward beginning a fork for at least DEWP. This is not a small subset of people who are upset with WMF. Perhaps someone can explain what is so alarming about our readership stats and how MV is likely to improve our readership stats. To me the disappointing active editor stats are the biggest worry. Thanks, Pine On Aug 26, 2014 3:14 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Actually the issue is no longer only that. It is also very much about how a subset of people high jack the conversation by their uncompromising stance. When they feel they might leave, I personally prefer it when they stop their posturing and decide either way. When they want to stay, they do not need to be welcomed, they are part of us. When they go, they are welcome and they can take with them everything we have in the sense of data and software. It is then for them to show that their proof is in their pudding. In the mean time WMF will continue to engage in best practices both technically and socially and when they cook something nice, what is on offer is there for the eating as well. As far as I am concerned, put up or shut up. It has been advertised widely that bugs will be squashed. It is also advertised widely that changes will be considered as long as they are reasonable and do not interfere with our prime directive. Again, it is about the readers not super users. Thanks, GerardM On 25 August 2014 11:16, Pine W wiki.p...@gmail.com wrote: The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also the matter of licensing information. I'm not aware of where thermonuclear was was threatened. There were, and continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production and made default. That needs to be addressed, and the fact that the problems with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her to transform WMF and I am glad that there seems to be agreement that Product will be an early subject of transformation. I have reservations about forking for reasons that I can explain if necessary. It would be a lot easier if WMF would transform itself, starting with Product, and Lila appears to intend to make this happen. I hope that the processes for Product will be democratic and consensus-based. Grantmaking has already demonstrated the effectiveness of community-based decision making with FDC and IEGCom, and I hope to see a similar model emerge for Product. If it doesn't, there is enough anger in the community, especially on
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
I agree with Gerard, and would add that a good portion of the new readers and missing female editors do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the first edit experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure). Sent from my iPad On Aug 28, 2014, at 4:30 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Such separate hostings and ownership would not be that much of a risk to the WMF. The challenges will be first and foremost with the separatists; then again it is firmly their choice. There will be benefits on both sides as well. The community that remains with the WMF will lose all of the separatists and they will sadly see some of them go. It will allow for the influx of new people and new ideas. The people that go will get a reality check; they will find out to what extend the things they fought battles over are actually worth it. I am sure that both communities will benefit. When the people who talk about going their own way rethink their stance and start considering the other side of the coin it may lead to an equilibrium. However, the Visual Editor is not the only thing that will change the look and feel there is so much more happening and at that, a single community only considering its own is in effect a cul de sac. When numbers of readers are to be our main worry, it should be obvious by now that both for editing and reading they are happening on the mobile, the tablet. This is were our new readers are happening. Maybe not necessarily in Europe but certainly in the global south. They have by definition a different mode of operandi and consequently much of our current bickering is only distracting from putting our efforts in welcoming our newbies and building a full fledged environment for them. Thanks, GerardM On 28 August 2014 09:34, Pine W wiki.p...@gmail.com wrote: WMF update: https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov_(WMF)diff=9665238oldid=9664457 Gerard, I agree that a forked wiki could have collaborations with WMF. But having separate hosting and legal ownership would create new headaches and risks. I hope WMF takes a cooperative and democratic approach so that we can work in harmony without forking. There will almost always be people unhappy with major decisions. We should aim for consensus, not necessarily unanimous decisions. Recently it seemed to me that the consensus was leaning toward beginning a fork for at least DEWP. This is not a small subset of people who are upset with WMF. Perhaps someone can explain what is so alarming about our readership stats and how MV is likely to improve our readership stats. To me the disappointing active editor stats are the biggest worry. Thanks, Pine On Aug 26, 2014 3:14 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Actually the issue is no longer only that. It is also very much about how a subset of people high jack the conversation by their uncompromising stance. When they feel they might leave, I personally prefer it when they stop their posturing and decide either way. When they want to stay, they do not need to be welcomed, they are part of us. When they go, they are welcome and they can take with them everything we have in the sense of data and software. It is then for them to show that their proof is in their pudding. In the mean time WMF will continue to engage in best practices both technically and socially and when they cook something nice, what is on offer is there for the eating as well. As far as I am concerned, put up or shut up. It has been advertised widely that bugs will be squashed. It is also advertised widely that changes will be considered as long as they are reasonable and do not interfere with our prime directive. Again, it is about the readers not super users. Thanks, GerardM On 25 August 2014 11:16, Pine W wiki.p...@gmail.com wrote: The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also the matter of licensing information. I'm not aware of where thermonuclear was was threatened. There were, and continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production and made default. That needs to be addressed, and the fact that the problems with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her to transform WMF and I am glad that there seems to be agreement that Product will be an early subject of transformation. I have reservations about forking for reasons that I can explain if
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
On 28 August 2014 12:56, Jane Darnell jane...@gmail.com wrote: I agree with Gerard, and would add that a good portion of the new readers and missing female editors do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the first edit experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure). mechanics of how this would work. We could do it, but reforming WMF is Every year we see many expensive surveys and funded research on women and Wikipedia, so presumably there are some verifiable statistics to support Jane's assertion that a significant difference between readers of Wikipedia is that men are significantly more likely to own or have access to a desktop compared to women that they might edit from. Can someone provide a link to the research that demonstrates this is more than apocryphal? Thanks, 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
Hey Jane, as the desktop is sometimes characterised only as a legacy input device for old power editors, while the reading is done from mobile devices, often in the form of mash-ups and geo-apps, why is a compromise so hard to achieve? One solution that pops up would be to cache the content (as most useful wikipedia apps do anyway) in a light mobile version, while allowing an existing group of useful contributors their little island. This feeling of belonging makes those editors do all the dirty jobs noone wants to do on a regular basis - most of it fact and copyright checks that make the content so good it is useful to readers and keeps them coming back. You could create a newbie-friendly version with rich text editing optimised for different devices, more customisation in an easy way... if we are realistic that would be the way to go anyway, as you can start out much easier and with less baggage - and would be able to target groups on an individual basis in the process, too. When they evolve in the (bitter-vet) power users and editors, they can switch to the still more useful but less pretty interfaces for large data manipulation, that the desktop offers. Shouldn't the focus be on the readers that read the content AND the editors that produce interesting content to make readers come back? Gerard in this regard seems to have a somehow bi-polar view of this process with his us - them characterisation (the community that remains with the WMF will lose all of the separatists). They will just no longer do the hard stuff, if they feel that they are not welcome - and finding such people is hard, really hard (speaking as a long-term gutenberg proof-reader). cheers, g Thursday, August 28, 2014, 1:56:38 PM, you wrote: I agree with Gerard, and would add that a good portion of the new readers and missing female editors do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the first edit experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure). Sent from my iPad On Aug 28, 2014, at 4:30 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Such separate hostings and ownership would not be that much of a risk to the WMF. The challenges will be first and foremost with the separatists; then again it is firmly their choice. There will be benefits on both sides as well. The community that remains with the WMF will lose all of the separatists and they will sadly see some of them go. It will allow for the influx of new people and new ideas. The people that go will get a reality check; they will find out to what extend the things they fought battles over are actually worth it. I am sure that both communities will benefit. When the people who talk about going their own way rethink their stance and start considering the other side of the coin it may lead to an equilibrium. However, the Visual Editor is not the only thing that will change the look and feel there is so much more happening and at that, a single community only considering its own is in effect a cul de sac. When numbers of readers are to be our main worry, it should be obvious by now that both for editing and reading they are happening on the mobile, the tablet. This is were our new readers are happening. Maybe not necessarily in Europe but certainly in the global south. They have by definition a different mode of operandi and consequently much of our current bickering is only distracting from putting our efforts in welcoming our newbies and building a full fledged environment for them. Thanks, GerardM ___ 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
You can start by asking around in your own circle of aquaintance, and I'll bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know are married and though their household contains a desktop, the desktop is owned and operated by their husband, not them. In any official questionaire served to them however, they are probably asked whether their household has one, not whether they themselves are the primary user of one. On Thu, Aug 28, 2014 at 8:29 AM, Fæ fae...@gmail.com wrote: On 28 August 2014 12:56, Jane Darnell jane...@gmail.com wrote: I agree with Gerard, and would add that a good portion of the new readers and missing female editors do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the first edit experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure). mechanics of how this would work. We could do it, but reforming WMF is Every year we see many expensive surveys and funded research on women and Wikipedia, so presumably there are some verifiable statistics to support Jane's assertion that a significant difference between readers of Wikipedia is that men are significantly more likely to own or have access to a desktop compared to women that they might edit from. Can someone provide a link to the research that demonstrates this is more than apocryphal? Thanks, 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 ___ 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 Thu, Aug 28, 2014 at 6:55 AM, Jane Darnell jane...@gmail.com wrote: You can start by asking around in your own circle of aquaintance, and I'll bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know are married and though their household contains a desktop, the desktop is owned and operated by their husband, not them. I use (primarily) my carbon-fiber beast of a desktop, with my wife using primarily a laptop. The use of desktop to (presumably) refer to laptops is very confusing here, and would make accurate data gathering more difficult, not less. We both use a tablet and/or phone, but only when away from the real machines or for very quick stuff. Doing real work on a tablet/phone is a pain in the ass, not just on Wikipedia but for anything. If I have a decent amount of text to type, I'll take a real keyboard and two monitors, not one keyboard taking up half of a 4 screen, thanks very much. I can't even imagine trying to make a significant edit to an article on a phone, no matter how good we make the interface. Even in a visual editor, articles require the entry of a lot of text, not the Facebook-style I'm here, having a great time! That's a usage pattern that's very common with couples in my experience. It's apparently not in yours. That's why the plural of anecdote is not evidence. In any official questionaire served to them however, they are probably asked whether their household has one, not whether they themselves are the primary user of one. Why would they be? If we're trying to determine use patterns, it's silly to ask about the simple presence of something, but that's easy to fix. What device do you primarily use when accessing the Internet? (Alternatively, or as a followup, What type of device do you routinely use to access the Internet? Check all that apply.) [ ] A desktop computer [ ] A laptop or notebook computer [ ] A tablet or smartphone Not that hard to design a question that addresses the user directly, by not just access to a given device but actual use of it. If we need that data, we ought to actually gather it. On Thu, Aug 28, 2014 at 8:29 AM, Fæ fae...@gmail.com wrote: On 28 August 2014 12:56, Jane Darnell jane...@gmail.com wrote: I agree with Gerard, and would add that a good portion of the new readers and missing female editors do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the first edit experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure). mechanics of how this would work. We could do it, but reforming WMF is Every year we see many expensive surveys and funded research on women and Wikipedia, so presumably there are some verifiable statistics to support Jane's assertion that a significant difference between readers of Wikipedia is that men are significantly more likely to own or have access to a desktop compared to women that they might edit from. Can someone provide a link to the research that demonstrates this is more than apocryphal? Thanks, 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 ___ 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 should explain that I am a resident of the Netherlands, where we have a central statistics bureau which includes census statistics that you can query for free and download your own datasets in xls format. As a data analyst I have spent lots of time gathering such data and reporting on it in Microsoft Excel, which is still my tool of choice. I frequently read news stories about published reports that misinterpret data and I sometimes will check the cited data against published open data sources. I base my conclusions on that experience as well as my personal experience. It may also be helpful to explain that many of my friends are or were stay-at-home moms. I agree that most of the questions served in public surveys do not seem to be formulated by data analysts. I am proud to say that after a rocky start I can finally edit Wikipedia and Wikimedia Commons on my iPad, but I couldn't tell you what I did to set it up. I have successfully uploaded several photos with my android app to Wiki Loves Monuments. I do know that I tried to make an edit on someone else's iPhone this week and was stopped short by the mobile interface. On Thu, Aug 28, 2014 at 9:35 AM, Todd Allen toddmal...@gmail.com wrote: On Thu, Aug 28, 2014 at 6:55 AM, Jane Darnell jane...@gmail.com wrote: You can start by asking around in your own circle of aquaintance, and I'll bet that such research will make you quickly realize that hard stats will be very hard to discover, since in my circle, most of the women I know are married and though their household contains a desktop, the desktop is owned and operated by their husband, not them. I use (primarily) my carbon-fiber beast of a desktop, with my wife using primarily a laptop. The use of desktop to (presumably) refer to laptops is very confusing here, and would make accurate data gathering more difficult, not less. We both use a tablet and/or phone, but only when away from the real machines or for very quick stuff. Doing real work on a tablet/phone is a pain in the ass, not just on Wikipedia but for anything. If I have a decent amount of text to type, I'll take a real keyboard and two monitors, not one keyboard taking up half of a 4 screen, thanks very much. I can't even imagine trying to make a significant edit to an article on a phone, no matter how good we make the interface. Even in a visual editor, articles require the entry of a lot of text, not the Facebook-style I'm here, having a great time! That's a usage pattern that's very common with couples in my experience. It's apparently not in yours. That's why the plural of anecdote is not evidence. In any official questionaire served to them however, they are probably asked whether their household has one, not whether they themselves are the primary user of one. Why would they be? If we're trying to determine use patterns, it's silly to ask about the simple presence of something, but that's easy to fix. What device do you primarily use when accessing the Internet? (Alternatively, or as a followup, What type of device do you routinely use to access the Internet? Check all that apply.) [ ] A desktop computer [ ] A laptop or notebook computer [ ] A tablet or smartphone Not that hard to design a question that addresses the user directly, by not just access to a given device but actual use of it. If we need that data, we ought to actually gather it. On Thu, Aug 28, 2014 at 8:29 AM, Fæ fae...@gmail.com wrote: On 28 August 2014 12:56, Jane Darnell jane...@gmail.com wrote: I agree with Gerard, and would add that a good portion of the new readers and missing female editors do not own or operate a desktop and are only available on mobile and tablet, so this is not only where the new readers are, but also where the first edit experience is for most women (and sadly, a corollary to that is that they don't try again after their first edit failure). mechanics of how this would work. We could do it, but reforming WMF is Every year we see many expensive surveys and funded research on women and Wikipedia, so presumably there are some verifiable statistics to support Jane's assertion that a significant difference between readers of Wikipedia is that men are significantly more likely to own or have access to a desktop compared to women that they might edit from. Can someone provide a link to the research that demonstrates this is more than apocryphal? Thanks, 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
What the heck is a design community at all, and why does their opinion count, when WMF uses every opportunity to claim it is super-unfair to claim that the community wants anything? 2014-08-27 6:49 GMT+02:00 geni geni...@gmail.com: On 27 August 2014 05:16, Erik Moeller e...@wikimedia.org wrote: And the design community is taking notice: https://news.layervault.com/stories/31897-wikipedia-already-looks-great--just-add-m-on-desktop We already know the design community doesn't like the edit button. Was there any reason you thought we should pay attention to their opinion? -- geni ___ 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, Actually the issue is no longer only that. It is also very much about how a subset of people high jack the conversation by their uncompromising stance. When they feel they might leave, I personally prefer it when they stop their posturing and decide either way. When they want to stay, they do not need to be welcomed, they are part of us. When they go, they are welcome and they can take with them everything we have in the sense of data and software. It is then for them to show that their proof is in their pudding. In the mean time WMF will continue to engage in best practices both technically and socially and when they cook something nice, what is on offer is there for the eating as well. As far as I am concerned, put up or shut up. It has been advertised widely that bugs will be squashed. It is also advertised widely that changes will be considered as long as they are reasonable and do not interfere with our prime directive. Again, it is about the readers not super users. Thanks, GerardM On 25 August 2014 11:16, Pine W wiki.p...@gmail.com wrote: The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also the matter of licensing information. I'm not aware of where thermonuclear was was threatened. There were, and continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production and made default. That needs to be addressed, and the fact that the problems with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her to transform WMF and I am glad that there seems to be agreement that Product will be an early subject of transformation. I have reservations about forking for reasons that I can explain if necessary. It would be a lot easier if WMF would transform itself, starting with Product, and Lila appears to intend to make this happen. I hope that the processes for Product will be democratic and consensus-based. Grantmaking has already demonstrated the effectiveness of community-based decision making with FDC and IEGCom, and I hope to see a similar model emerge for Product. If it doesn't, there is enough anger in the community, especially on DEWP, that a fork is possible. The community is smart enough collectively to figure out a way to make a fork happen, and some of us have been discussing the mechanics of how this would work. We could do it, but reforming WMF is preferable. I hope that Lila can and will do this. Internal transofmration is preferable to replacing WMF. Pine ___ 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
On Thu, Aug 21, 2014 at 10:35 PM, Erik Moeller e...@wikimedia.org wrote: If you take a look at the mobile experience in a desktop browser, you'll find it not so different from many redesigns - large, readable text, narrower measure, deliberately chosen typography, minimal clutter, easier access to footnotes, etc. http://en.m.wikipedia.org/wiki/Liber_Eliensis And the design community is taking notice: https://news.layervault.com/stories/31897-wikipedia-already-looks-great--just-add-m-on-desktop -- 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] Next steps regarding WMF-community disputes about deployments
On 27 August 2014 05:16, Erik Moeller e...@wikimedia.org wrote: And the design community is taking notice: https://news.layervault.com/stories/31897-wikipedia-already-looks-great--just-add-m-on-desktop We already know the design community doesn't like the edit button. Was there any reason you thought we should pay attention to their opinion? -- geni ___ 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 26 August 2014 09:39, Erik Moeller e...@wikimedia.org wrote: First, I think it's worthwhile in these discussions - in a context of a project where consensus is important - to remember that there are actually many different perspectives on Media Viewer in the community. Even in German Wikipedia, 72 community members voted _against_ disabling Media Viewer Hey you are the one currently ignoring 664 German wikipedians. Thats not logically consistent with objecting to people ignoring smaller numbers. (more in absolute terms, incidentally, than voted for disabling it on English Wikipedia's RFC). You want en to stick a link in sitenotice and up the numbers? -- geni ___ 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, Given that it is pathetically easy to opt out of the MultimediaViewer, the amount of vitriol spouted by some is way out of proportion to the problem. If you do not want it, opt out. But thermonuclear was was threatened, people were to lose their job over this. No the excuses are too little and too late. When people think that the change is not good for them opt out. What was said was a disgrace. It has never been in doubt that problems would be tackled. Finally do not expect that much maintenance will be done on what is so lightly discarded. It is fine for you to stay with your Internet 6. Improvements and subsequent development is just not for you. Thanks, GerardM On 25 August 2014 05:19, Pine W wiki.p...@gmail.com wrote: I have heard very few people say don't ever change the interface. I have heard people say don't force an interface change on me that I don't think is an improvement. VE was a good example. The sentiment of the community wasn't that VE''s concept is wrong, it's that the implementation and rollout had major deficiencies. The MV issue is larger than than the usual editor-focused interface change because it impacts readers as well as editors, and there were issues with the display of licenses to readers. Personally I feel that the MV issues are fixable but the rollout should have been handled differently, and I am glad that the community and WMF both want to avoid repeating rollout problems again and again. Pine On Sun, Aug 24, 2014 at 4:48 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, In the metrics meeting, a presentation was given that showed that mobile editing is really starting to happen. It is happening to the extend where new editors are predominantly mobile editors. When I asked my question do we need to keep you happy I specifically targeted the vitriolic parts of our community. In my experience it it the part that is conservative, not willing to listen, not open to change and not willing to consider what is important to others.At Wikimania one of the presenters indicated that he was willing to contribute to Wikidata. This was not accepted because someone in the community is really involved in this subject and he had to have a say. This was one major person probably walking away for ever who is hugely important in science and open data. The user interface for selecting fonts is abysmal because the community decided that what was implemented looked cluttered. Only seven percent of the world population is dyslexic and they do NOT find Wikipedia easier to read as a result. Really, what is important to some people in the community is not necessarily beneficial at all. The lack of conversation the ease of making demands and not appreciating that our aim is to share in the sum of all knowledge means that many retarded points of view abound. Erik indicated that he is willing to talk and come to a workable compromise. However, we do need change and we need it badly. When this is not understood, I am sorry to say, those who fail to understand this are a problem, a problem that is increasingly cancelling out their future value. Thanks, Gerard On 24 August 2014 12:49, Dariusz Jemielniak dar...@alk.edu.pl wrote: hi, On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Now what do we aim to achieve? Keeping you happy or making sure we have a public ??? simply put: both. We need readers just as much as we need the free labor of editors/volunteers. I don't think it makes any sense to have a discussion about the wasted millions. First, in software development there is always some inevitable waste, just because of the nature of this endeavor. Second, many projects which start with mixed reception are getting better (and I have high hope that the visual editor is one of them!). Third, for an IT organization of this caliber and traffic, as well as the budget, there are impressive results in many areas (including, but not limited to, mobile website - at least for viewers, as editing is a different story). The real problem here, in my view, is creating an organizational framework that will allow to incorporate the community much more into planning, early development, alpha and beta testing, and finally implementation of all new features and tools (in a way which does not rely on IT schedules only, but also on feedback from the communities). It is up to WMF to create and provide such framework, as our community as a whole does not have any institutionalized representation or voice (which is part of the issue; one the one hand it is easy to discard whatever people from the community say, as they are random individuals, and on the other it must be deeply frustrating to never be sure what the community reaction will be). Some
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
The issue is not just that individual users may want to opt out, it's whether it should be activated by default for readers. There is also the matter of licensing information. I'm not aware of where thermonuclear was was threatened. There were, and continues to be, discussion about forking. MV is merely the latest occurrence of products with major problems being pushed into production and made default. That needs to be addressed, and the fact that the problems with MV happened after AFT5 and VE *and* after the creation of the Engineering Community Liaisons suggests deep, long-term problems with product development. I believe that Lila said that the Board wants her to transform WMF and I am glad that there seems to be agreement that Product will be an early subject of transformation. I have reservations about forking for reasons that I can explain if necessary. It would be a lot easier if WMF would transform itself, starting with Product, and Lila appears to intend to make this happen. I hope that the processes for Product will be democratic and consensus-based. Grantmaking has already demonstrated the effectiveness of community-based decision making with FDC and IEGCom, and I hope to see a similar model emerge for Product. If it doesn't, there is enough anger in the community, especially on DEWP, that a fork is possible. The community is smart enough collectively to figure out a way to make a fork happen, and some of us have been discussing the mechanics of how this would work. We could do it, but reforming WMF is preferable. I hope that Lila can and will do this. Internal transofmration is preferable to replacing WMF. Pine ___ 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, 25 Aug 2014, at 13:19, Pine W wrote: I have heard very few people say don't ever change the interface. I have heard people say don't force an interface change on me that I don't think is an improvement. VE was a good example. The sentiment of the community wasn't that VE''s concept is wrong, it's that the implementation and rollout had major deficiencies. The MV issue is larger than than the usual editor-focused interface change because it impacts readers as well as editors, and there were issues with the display of licenses to readers. Personally I feel that the MV issues are fixable but the rollout should have been handled differently, and I am glad that the community and WMF both want to avoid repeating rollout problems again and again. Pine This instance is not new; https://meta.wikimedia.org/wiki/Limits_to_configuration_changes is a historical list of similar pattern in the relationship. They already told you that they are doing this to not lose readers, so that fundraising keeps working. Tops you can do is, like the WMF folks remarked earlier, is have community work on what it needs from the bottom up grassroots etc. A first step here, I believe, is have the Teams track bugs in the open; from my own experience, the Flow and Multimedia folks track bugs somewhere else where I can't even view or comment (and even if I could, it being different from Bugzilla would make things harder). I'm not sure what about migration to Phabricator, but I think it's an operations style of thing (I'm yet to figure out how to get involved, but it'd make it easier for anyone to work on the new features - they are really documented on-wiki (thankfully they only internalise only bug tracking atm), although so far only in English mostly). 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] Next steps regarding WMF-community disputes about deployments
from my own experience, the Flow and Multimedia folks track bugs somewhere else where I can't even view or comment Bugs and tasks are public for the Multimedia team. If you mean bugs in the bastardized sense of the term which is things filed in bugzilla, then yes, the Multimedia team doesn't usually file building/refactoring tasks in bugzilla, we use mingle instead, which is public and can be commented on by everyone: http://ur1.ca/i1x3g We regularly link to our mingle cards on our mailing list updates, it's never been a secret area. I find that the mailing list is a better place for discussion, though, and we summarize in regular threads what tasks we're working on or planning to work on. In practice that's what's always happened anyway, people interested in what we're up to will reply to the detailed mailing list updates rather than comment on Mingle. Probably because Mingle's comment support is terrible. As for actual bugs (defects) on products the Multimedia team is responsible for, they are currently tracked on bugzilla like everything else. It can happen ocassionally that we fix a bug and forget to file it in bugzilla, but generally speaking a bug/defect tracked in Mingle has a bugzilla counterpart. The existing disconnect and the fact that we sometimes forget to file a counterpart is one of the reasons we want to have a unified tool to do all the things people currently use bugzilla, mingle and trello for. Our team will be one of the first to migrate to phabricator when the migration starts, because it will allow us to treat tasks, workload and defects in a single place. It will also give a much clearer view of what's going on to casual observers. The only reason why our team uses Mingle instead of Bugzilla for building tasks and triage is that Bugzilla offers no workload management and is often a poor fit for things that aren't defects. We're definitely not using Mingle to get things out of view (since it's public and regularly linked to), it's just that in the status quo Bugzilla alone didn't offer what we needed. I'm sure other teams use Trello and other tools for similar reasons. This is all coming from needs not covered by Bugzilla and we know very well how much that sucks in various ways, including the introduction of signup hurdles for people who want to interact with us, and the lack of discoverability, despite linking to Mingle every time we can. We certainly hope that the move to phabricator will make help people see and comment on what we're doing. Feeling like we're the only ones active on a particular tool is unhealthy for our projects, that's definitely not what we're looking for with phabricator, on the contrary. On Mon, Aug 25, 2014 at 6:19 AM, svetlana svetl...@fastmail.com.au wrote: On Mon, 25 Aug 2014, at 13:19, Pine W wrote: I have heard very few people say don't ever change the interface. I have heard people say don't force an interface change on me that I don't think is an improvement. VE was a good example. The sentiment of the community wasn't that VE''s concept is wrong, it's that the implementation and rollout had major deficiencies. The MV issue is larger than than the usual editor-focused interface change because it impacts readers as well as editors, and there were issues with the display of licenses to readers. Personally I feel that the MV issues are fixable but the rollout should have been handled differently, and I am glad that the community and WMF both want to avoid repeating rollout problems again and again. Pine This instance is not new; https://meta.wikimedia.org/wiki/Limits_to_configuration_changes is a historical list of similar pattern in the relationship. They already told you that they are doing this to not lose readers, so that fundraising keeps working. Tops you can do is, like the WMF folks remarked earlier, is have community work on what it needs from the bottom up grassroots etc. A first step here, I believe, is have the Teams track bugs in the open; from my own experience, the Flow and Multimedia folks track bugs somewhere else where I can't even view or comment (and even if I could, it being different from Bugzilla would make things harder). I'm not sure what about migration to Phabricator, but I think it's an operations style of thing (I'm yet to figure out how to get involved, but it'd make it easier for anyone to work on the new features - they are really documented on-wiki (thankfully they only internalise only bug tracking atm), although so far only in English mostly). svetlana ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list,
Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments
Hoi, I am so happy that you know so well that all the millions have been wasted. As so often, an opinion is just that. When you want to learn about the effect of the development done, it may be useful to look a bit further afield. Mobile is one area where the development proves really effective. Without it our numbers of readers would be down. It is also where the number of new editors are happening. When your idea of editing Wikipedia is business as usual, you have lost many people because the experience is awful. So when I am to accept your argument that the framework is wrong. I will agree with you when it means that we migrate from the awful framework we have used for too long. It is exactly the Visual Editor and the Media Viewer that make sense to our users. Commons as it is is so bad as an experience that people like me who are committed to WMF do not use it. Now what do we aim to achieve? Keeping you happy or making sure we have a public ??? Thanks, GerardM On 22 August 2014 13:05, Henning Schlottmann h.schlottm...@gmx.net wrote: On 22.08.2014 09:22, Erik Moeller wrote: - The MediaViewer rollout was very smooth until the deployments to German Wikipedia, English Wikipedia and Wikimedia Commons. There could be many reasons for that -- but it's a fact nonetheless. I do see little evidence that users in other communities are especially unhappy about the feature (leaving aside the politics of it now). I would be very curious what reason people do attribute that difference to, however (understanding that Commons is very different from the Wikipedia use case). This may or may not correlate with a deep commitment to a) the licenses, b) quality. - The criticism isn't just about that -- it's about a large number of mostly individually small issues. Generally, the idea that we effectively munge some of the metadata by displaying a machine-readable subset below the fold is viewed very negatively, because 1) it doesn't reflect all the available information, 2) it makes it harder for users to discover the File: page, and potentially edit it. If it does not reflect the license information it is broken. The license is paramount. We can not accept any kind of software that hands out reuse information that does not display the photographer's name and the license (with link to the license text). We do not want a default setting, that does not show extensive descriptions, map legends, image annotations and the like. All that is content we created for the readers. You must not block our readers from this content. MV is broken. It is not ready to be deployed. Not by far. Take it back and fix it. In theory I can see a working MV. I can even imagine a working Visual Editor, but am very skeptical about it. I can not imagine Flow to work, ever. This one needs to be abandoned now. Eric, your department has an abysmal record. You have wasted millions on software that started with the wrong framework and is not working after years and years of development. Please think about yourself, not about the communities if you want to understand about the conflicts at hand. Henning ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
