Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pete Forsyth]

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 
wrote:

> On Thu, Apr 23, 2015 at 11:03 AM, Pine W  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Aleksey Bilogur]

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"  wrote:

> On 25 April 2015 at 04:11, David Goodman  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,
> 
___
Wikimedia-l mailing list, 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

[David Gerard]

On 25 April 2015 at 04:11, David Goodman  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[David Goodman]

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  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* 
>
>
>
>
>
>
> *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 
> wrote:
>
> > On Thu, Apr 23, 2015 at 11:03 AM, Pine W  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,
> > 
> >
> ___

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pine W]

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* 






*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 
wrote:

> On Thu, Apr 23, 2015 at 11:03 AM, Pine W  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,
> 
>
___
Wikimedia-l mailing list, 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

[Pete Forsyth]

On Thu, Apr 23, 2015 at 11:03 AM, Pine W  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pine W]

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* 






*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 
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  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" 
> 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
> >  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,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Aleksey Bilogur]

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 
wrote:

> James Alexander
> Community Advocacy
> Wikimedia Foundation
> (415) 839-6885 x6716 @jamesofur
>
> On Thu, Apr 23, 2015 at 11:03 AM, Pine W  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"  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
>  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,
> 
>
___
Wikimedia-l mailing list, 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

[James Alexander]

James Alexander
Community Advocacy
Wikimedia Foundation
(415) 839-6885 x6716 @jamesofur

On Thu, Apr 23, 2015 at 11:03 AM, Pine W  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"  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
 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Aleksey Bilogur]

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  wrote:

> Hi Pete,
>
> Philippe is on vacation, so I'm forwarding this to Rachel.
>
> Pine
> On Apr 22, 2015 11:59 PM, "Pete Forsyth"  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 
> > 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"  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  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 
> > >> 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 
> > >> 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

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pine W]

Hi Pete,

Philippe is on vacation, so I'm forwarding this to Rachel.

Pine
On Apr 22, 2015 11:59 PM, "Pete Forsyth"  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 
> 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"  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  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 
> >> 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 
> >> 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,
> >> > > >  >> ?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

[Pete Forsyth]

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  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"  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  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 
>> 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 
>> 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,
>> > > > > ?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
>> ,
>> > > 
>> > >
>> >
>> >
>> >
>> > --
>> > 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

[Gergo Tisza]

On Sat, Sep 6, 2014 at 8:13 AM, Erik Moeller  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Diego Moya]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Amir E. Aharoni]

2014-09-07 4:17 GMT+03:00 Risker :
> 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Gerard Meijssen]

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  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

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pine W]

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  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,
> 
>
___
Wikimedia-l mailing list, 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 Sinclair]

> 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[John Mark Vandenberg]

On Sun, Sep 7, 2014 at 12:18 PM, Romaine Wiki  wrote:
> 2014-09-06 1:07 GMT+02:00 Steven Walling :
>
>> On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg 
>> 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Romaine Wiki]

2014-09-06 1:07 GMT+02:00 Steven Walling :

> On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg 
> 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Risker]

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  wrote:

> On Fri, Sep 5, 2014 at 10:42 PM, Risker  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

[Marc A. Pelletier]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Yaroslav M. Blanter]

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  
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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Gerard Meijssen]

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  wrote:

> On 06.09.2014 19:06, Marc A. Pelletier wrote:
>
>> On 09/06/2014 12:34 PM, Isarra Yos 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
>
>
>
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Yaroslav M. Blanter]

On 06.09.2014 19:06, Marc A. Pelletier wrote:

On 09/06/2014 12:34 PM, Isarra Yos 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


___
Wikimedia-l mailing list, 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

[Todd Allen]

Marc,

Wanting to "keep the newbies away" is hardly a common reason for people's
opposition to Flow. Someone might've said such a thing, but to paint that
as the reason for opposition for even a significant minority is totally
inaccurate.

You can, of course, say that all the other reasons given are irrational,
though I wouldn't agree. But dismissing them by setting up a (rather
ridiculous) straw man is not helpful.


On Sat, Sep 6, 2014 at 11:06 AM, 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).
>
> Very many people, myself included, believe that a wiki page is an
> *atrocious* medium for discussion.  It obfuscates who is talking to whom
> under layers of markup, can make discussion flow (see what I did here?)
> impossible to divine unless you are an old hand, and is otherwise
> nearly-impossible for most newbies to partake in.
>
> Hell, I've been around for over ten years and on large volume
> discussions (you know, the ones we *want* lots of participation in),
> commenting is a pain at best and I /still/ end up having to occasionally
> have to peruse diffs just to figure out who said what in which order.
>
> I've yet to find a rational motivation for expressing desire for that
> horrid mess other than "it keeps the newbies away".  And yes, that
> rationale *has* been offered.  More than once.  In so many words.
>
> 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
>
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Isarra Yos]

On 06/09/14 17:06, 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).

Very many people, myself included, believe that a wiki page is an
*atrocious* medium for discussion.  It obfuscates who is talking to whom
under layers of markup, can make discussion flow (see what I did here?)
impossible to divine unless you are an old hand, and is otherwise
nearly-impossible for most newbies to partake in.

Hell, I've been around for over ten years and on large volume
discussions (you know, the ones we *want* lots of participation in),
commenting is a pain at best and I /still/ end up having to occasionally
have to peruse diffs just to figure out who said what in which order.

I've yet to find a rational motivation for expressing desire for that
horrid mess other than "it keeps the newbies away".  And yes, that
rationale *has* been offered.  More than once.  In so many words.

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


Where did I say wiki pages are a good discussion medium?

-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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Marc A. Pelletier]

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).

Very many people, myself included, believe that a wiki page is an
*atrocious* medium for discussion.  It obfuscates who is talking to whom
under layers of markup, can make discussion flow (see what I did here?)
impossible to divine unless you are an old hand, and is otherwise
nearly-impossible for most newbies to partake in.

Hell, I've been around for over ten years and on large volume
discussions (you know, the ones we *want* lots of participation in),
commenting is a pain at best and I /still/ end up having to occasionally
have to peruse diffs just to figure out who said what in which order.

I've yet to find a rational motivation for expressing desire for that
horrid mess other than "it keeps the newbies away".  And yes, that
rationale *has* been offered.  More than once.  In so many words.

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


___
Wikimedia-l mailing list, 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

[Isarra Yos]

On 06/09/14 07:41, Erik Moeller wrote:

On Sat, Sep 6, 2014 at 12:23 AM, Isarra Yos  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[David Gerard]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Fæ]

On 06/09/2014, Isarra Yos  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Erik Moeller]

On Sat, Sep 6, 2014 at 12:23 AM, Isarra Yos  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Isarra Yos]

On 06/09/14 06:13, Erik Moeller wrote:

On Fri, Sep 5, 2014 at 10:42 PM, Risker  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 editable
(

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Gerard Meijssen]

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  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,
> 
>
_

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Erik Moeller]

On Fri, Sep 5, 2014 at 11:41 PM, Pine W  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pine W]

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  wrote:

> On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller  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,
> 
>
___
Wikimedia-l mailing list, 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

[Erik Moeller]

On Fri, Sep 5, 2014 at 11:13 PM, Erik Moeller  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Erik Moeller]

On Fri, Sep 5, 2014 at 10:42 PM, Risker  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 noti

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Risker]

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  wrote:

> Risker, what do you think might get us all back on track for Flow?
> Shou

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Wil Sinclair]

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  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  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 
>> 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,
>> 
>>
>> ___
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> Wikimedia-l@lists.wikimedia.org
>> 
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> 
>>
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@list

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Wil Sinclair]

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  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
> Carr

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[James Forrester]

On 5 September 2014 17:25, John Mark Vandenberg  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[John Mark Vandenberg]

On Sat, Sep 6, 2014 at 9:07 AM, Steven Walling  wrote:
> On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg 
> 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pine W]

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 
wrote:

> On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg 
> 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,
> 
>
___
Wikimedia-l mailing list, 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

[Steven Walling]

On Fri, Sep 5, 2014 at 1:48 PM, John Mark Vandenberg 
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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Tim Davenport]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[John Mark Vandenberg]

On Sat, Sep 6, 2014 at 3:29 AM, 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?
>
> ...
>
> 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Wil Sinclair]

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  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Risker]

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  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 
> 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,
> 
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> 
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Wil Sinclair]

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  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  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,
>> 
>>
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> 

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Wil Sinclair]

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  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, 
> 

___
Wikimedia-l mailing list, 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

[Andreas Kolbe]

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  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,
> 
>
___
Wikimedia-l mailing list, 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

[Marc A. Pelletier]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Yaroslav M. Blanter]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Wil Sinclair]

> 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Gerard Meijssen]

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  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 "" 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,
> 
>
___
Wikimedia-l mailing list, 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

[Marc A. Pelletier]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Brad Jorsch (Anomie)]

On Mon, Sep 1, 2014 at 11:44 AM, Fæ  wrote:

> On 01/09/2014, Marc A. Pelletier  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Liam Wyatt]

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  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 "" 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,
>  ?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.

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Jane Darnell]

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  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 "" 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,
> 
>
___
Wikimedia-l mailing list, 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

[Marc A. Pelletier]

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 "" 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Yann Forget]

Hi,

Thanks for your message. I think it is honest and useful.

2014-09-01 20:40 GMT+05:30 Marc A. Pelletier :
...
>
> 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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Richard Farmbrough]

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  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"  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  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 
> 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 
> > 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,
> > > > >  ?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,
> > > > 
> > > >
> > >
> > >
> > >
> > > --
> > > Joe Decker
> > > www.joedecker.net
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pete Forsyth]

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"  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  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  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 
> 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,
> > > > 
> > > >
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > 
> > >
> >
> >
> >
> > --
> > 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,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Risker]

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  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  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  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,
> > > 
> > >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> >
>
>
>
> --
> 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,
> 
>
___
Wikimedia-l mailing list, 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

[Joe Decker]

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  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  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,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



-- 
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

[Todd Allen]

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  wrote:

>
>
>
> > On Sep 1, 2014, at 8:45 AM, Todd Allen  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,
> 
>
___
Wikimedia-l mailing list, 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

[Pete Forsyth]

On Sep 1, 2014 3:21 PM, "Philippe Beaudette" 
wrote:
>
> > On Sep 1, 2014, at 8:45 AM, Todd Allen  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Philippe Beaudette]

> On Sep 1, 2014, at 8:45 AM, Todd Allen  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Ziko van Dijk]

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 :
> 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, 
> 

___
Wikimedia-l mailing list, 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

[Gerard Meijssen]

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  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" 
> 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 
> > wrote:
> >
> > > On Aug 31, 2014 11:46 PM, "Pine W"  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,
> > > 
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > 
> > >
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://l

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Abd ulRahman Lomax]

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 
>To: Wikimedia Mailing List  
>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 
>wrote:
>
>> On Aug 31, 2014 11:46 PM, "Pine W"  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

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Abd ulRahman Lomax]

"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 
>To: Wikimedia Mailing List  
>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

[David Gerard]

On 1 September 2014 17:57, Martijn Hoekstra  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Marc A. Pelletier]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Martijn Hoekstra]

On Sep 1, 2014 5:10 PM, "Marc A. Pelletier"  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Marc A. Pelletier]

On 09/01/2014 11:45 AM, Todd Allen wrote:
> On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Todd Allen]

On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier  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 alwa

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Fæ]

On 01/09/2014, Marc A. Pelletier  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Marc A. Pelletier]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Craig Franklin]

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 
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 
> wrote:
>
> > On Aug 31, 2014 11:46 PM, "Pine W"  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,
> > 
> > ___
> > Wikimedia-l mailin

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pine W]

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" 
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 
> wrote:
>
> > On Aug 31, 2014 11:46 PM, "Pine W"  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,
> > 
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, 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

[Gerard Meijssen]

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 
wrote:

> On Aug 31, 2014 11:46 PM, "Pine W"  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,
> 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Martijn Hoekstra]

On Aug 31, 2014 11:46 PM, "Pine W"  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,

___
Wikimedia-l mailing list, 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

[Pine W]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Richard Farmbrough]

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  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 :
> > 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
> 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Yann Forget]

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 :
> 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

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Gerard Meijssen]

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, ; )  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 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Fæ]

On 30/08/2014, Mark  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Mark]

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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Jane Darnell]

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  wrote:

> On Thu, Aug 28, 2014 at 6:55 AM, 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.
>
>
> 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æ  wrote:
> >
> > > On 28 August 2014 12:56, Jane Darnell  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,
> > > 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Todd Allen]

On Thu, Aug 28, 2014 at 6:55 AM, 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.


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æ  wrote:
>
> > On 28 August 2014 12:56, Jane Darnell  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,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Jane Darnell]

Hi g,
Thanks for calling me an old power editor. I suggest you try to make an
edit to a WIkimedia project of choice (e.g. add a photo to an existing
article) on a desktop, then do the same on a mobile smartphone, and then
report back here.
Jane


On Thu, Aug 28, 2014 at 8:50 AM, ; )  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
> > 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
> >  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Jane Darnell]

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æ  wrote:

> On 28 August 2014 12:56, Jane Darnell  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,
> 
>
___
Wikimedia-l mailing list, 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

[; )]

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
>  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Fæ]

On 28 August 2014 12:56, Jane Darnell  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, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Jane Darnell]

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  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  wrote:
> 
>> WMF update:
>> 
>> https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov_(WMF)&diff=9665238&oldid=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" 
>> 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  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 agreemen

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Gerard Meijssen]

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  wrote:

> WMF update:
>
> https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov_(WMF)&diff=9665238&oldid=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" 
> 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  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 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[Pine W]

WMF update:
https://meta.wikimedia.org/w/index.php?title=User_talk:LilaTretikov_(WMF)&diff=9665238&oldid=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" 
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  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,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> 
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

[MF-Warburg]

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 :

> On 27 August 2014 05:16, Erik Moeller  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,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,