Mailing List Archive

1 2 3 4 5 6  View All
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <pbeaudette@wikimedia.org
> wrote:

>
>
>
> > On Sep 1, 2014, at 8:45 AM, Todd Allen <toddmallen@gmail.com> wrote:
> >
> > That's contradicted by, among other things, ACTRIAL as mentioned above.
> The
> > en.wp community came to a clear consensus for a major change, and the WMF
> > shrugged and said "Nah, rather not."
>
> That's... Not exactly what I remember happening there. What I remember was
> that a pretty good number (~500) of enwiki community members came together
> and agreed on a problem, and one plan for how to fix it and asked the WMF
> to implement it. The WMF evaluated it, and saw a threat to a basic project
> value. WMF then asked "what's the problem you're actually trying to
> solve?", and proposed and built a set of tools to directly address that
> problem without compromising the core value of openness. And it seems to
> have worked out pretty well because I haven't heard a ton of complaints
> about that problem since.
>
> ______________________
> Philippe Beaudette
> Director, Community Advocacy
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <toddmallen@gmail.com> wrote:

> That's the issue I cited above. You haven't heard more complaints, because
> the complaint was pointless the first time and took a massive effort to
> produce.
>
> The underlying issue isn't fixed. We're still drowning in crap and spam
> from people who never have the slightest intent of editing helpfully, and
> those who are newbies who genuinely want to help but need guidance get
> caught in the crossfire aimed at the vandals and spammers. It is relatively
> rare that when a genuinely new editor's first edit is a creation, it is the
> creation of an appropriate article on a workable subject, and that's
> normally more by dumb luck than them having actual knowledge that they
> should do it.
>
> So, consider that a complaint. The proposed fix didn't work, and most
> people at the time didn't figure it would work, but it was clearly the best
> we were going to get.
>
>
> On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette <
> pbeaudette@wikimedia.org
> > wrote:
>
> >
> >
> >
> > > On Sep 1, 2014, at 8:45 AM, Todd Allen <toddmallen@gmail.com> wrote:
> > >
> > > That's contradicted by, among other things, ACTRIAL as mentioned above.
> > The
> > > en.wp community came to a clear consensus for a major change, and the
> WMF
> > > shrugged and said "Nah, rather not."
> >
> > That's... Not exactly what I remember happening there. What I remember
> was
> > that a pretty good number (~500) of enwiki community members came
> together
> > and agreed on a problem, and one plan for how to fix it and asked the
> WMF
> > to implement it. The WMF evaluated it, and saw a threat to a basic
> project
> > value. WMF then asked "what's the problem you're actually trying to
> > solve?", and proposed and built a set of tools to directly address that
> > problem without compromising the core value of openness. And it seems to
> > have worked out pretty well because I haven't heard a ton of complaints
> > about that problem since.
> >
> > ______________________
> > Philippe Beaudette
> > Director, Community Advocacy
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>



--
Joe Decker
www.joedecker.net
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <joedecker@gmail.com> wrote:

> This, to the best of my knowledge, represents the entirety of the WMF's
> response to ACTRIAL. To the extent that there was additional feedback
> given, it was not given at WP:ACTRIAL, nor any other venue I am aware of.
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
>
> --Joe
>
>
> On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen <toddmallen@gmail.com> wrote:
>
> > That's the issue I cited above. You haven't heard more complaints,
> because
> > the complaint was pointless the first time and took a massive effort to
> > produce.
> >
> > The underlying issue isn't fixed. We're still drowning in crap and spam
> > from people who never have the slightest intent of editing helpfully, and
> > those who are newbies who genuinely want to help but need guidance get
> > caught in the crossfire aimed at the vandals and spammers. It is
> relatively
> > rare that when a genuinely new editor's first edit is a creation, it is
> the
> > creation of an appropriate article on a workable subject, and that's
> > normally more by dumb luck than them having actual knowledge that they
> > should do it.
> >
> > So, consider that a complaint. The proposed fix didn't work, and most
> > people at the time didn't figure it would work, but it was clearly the
> best
> > we were going to get.
> >
> >
> > On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette <
> > pbeaudette@wikimedia.org
> > > wrote:
> >
> > >
> > >
> > >
> > > > On Sep 1, 2014, at 8:45 AM, Todd Allen <toddmallen@gmail.com> wrote:
> > > >
> > > > That's contradicted by, among other things, ACTRIAL as mentioned
> above.
> > > The
> > > > en.wp community came to a clear consensus for a major change, and the
> > WMF
> > > > shrugged and said "Nah, rather not."
> > >
> > > That's... Not exactly what I remember happening there. What I remember
> > was
> > > that a pretty good number (~500) of enwiki community members came
> > together
> > > and agreed on a problem, and one plan for how to fix it and asked the
> > WMF
> > > to implement it. The WMF evaluated it, and saw a threat to a basic
> > project
> > > value. WMF then asked "what's the problem you're actually trying to
> > > solve?", and proposed and built a set of tools to directly address that
> > > problem without compromising the core value of openness. And it seems
> to
> > > have worked out pretty well because I haven't heard a ton of complaints
> > > about that problem since.
> > >
> > > ______________________
> > > Philippe Beaudette
> > > Director, Community Advocacy
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
>
>
>
> --
> Joe Decker
> www.joedecker.net
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
I hope that's not the feature Philippe meant, but maybe. For my clients and
students I think it's generally caused more confusion than it's solved,
since now they have an additional layer of bureaucracy to navigate (AFC).
Is there any data suggesting that's been a net improvement for new users?

Pete
On Sep 1, 2014 4:38 PM, "Risker" <risker.wp@gmail.com> wrote:

> Wasn't the creation of the DRAFT namespace at least in part a response to
> concerns raised at ACTRIAL, in particular new, poorly developed articles
> showing up in mainspace?
>
> Risker/Anne
>
>
> On 1 September 2014 19:08, Joe Decker <joedecker@gmail.com> wrote:
>
> > This, to the best of my knowledge, represents the entirety of the WMF's
> > response to ACTRIAL. To the extent that there was additional feedback
> > given, it was not given at WP:ACTRIAL, nor any other venue I am aware of.
> >
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
> >
> > --Joe
> >
> >
> > On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen <toddmallen@gmail.com> wrote:
> >
> > > That's the issue I cited above. You haven't heard more complaints,
> > because
> > > the complaint was pointless the first time and took a massive effort to
> > > produce.
> > >
> > > The underlying issue isn't fixed. We're still drowning in crap and spam
> > > from people who never have the slightest intent of editing helpfully,
> and
> > > those who are newbies who genuinely want to help but need guidance get
> > > caught in the crossfire aimed at the vandals and spammers. It is
> > relatively
> > > rare that when a genuinely new editor's first edit is a creation, it is
> > the
> > > creation of an appropriate article on a workable subject, and that's
> > > normally more by dumb luck than them having actual knowledge that they
> > > should do it.
> > >
> > > So, consider that a complaint. The proposed fix didn't work, and most
> > > people at the time didn't figure it would work, but it was clearly the
> > best
> > > we were going to get.
> > >
> > >
> > > On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette <
> > > pbeaudette@wikimedia.org
> > > > wrote:
> > >
> > > >
> > > >
> > > >
> > > > > On Sep 1, 2014, at 8:45 AM, Todd Allen <toddmallen@gmail.com>
> wrote:
> > > > >
> > > > > That's contradicted by, among other things, ACTRIAL as mentioned
> > above.
> > > > The
> > > > > en.wp community came to a clear consensus for a major change, and
> the
> > > WMF
> > > > > shrugged and said "Nah, rather not."
> > > >
> > > > That's... Not exactly what I remember happening there. What I
> remember
> > > was
> > > > that a pretty good number (~500) of enwiki community members came
> > > together
> > > > and agreed on a problem, and one plan for how to fix it and asked
> the
> > > WMF
> > > > to implement it. The WMF evaluated it, and saw a threat to a basic
> > > project
> > > > value. WMF then asked "what's the problem you're actually trying to
> > > > solve?", and proposed and built a set of tools to directly address
> that
> > > > problem without compromising the core value of openness. And it seems
> > to
> > > > have worked out pretty well because I haven't heard a ton of
> complaints
> > > > about that problem since.
> > > >
> > > > ______________________
> > > > Philippe Beaudette
> > > > Director, Community Advocacy
> > > > _______________________________________________
> > > > Wikimedia-l mailing list, guidelines at:
> > > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > > Wikimedia-l@lists.wikimedia.org
> > > > Unsubscribe:
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > > >
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > >
> >
> >
> >
> > --
> > Joe Decker
> > www.joedecker.net
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <peteforsyth@gmail.com> wrote:

> I hope that's not the feature Philippe meant, but maybe. For my clients and
> students I think it's generally caused more confusion than it's solved,
> since now they have an additional layer of bureaucracy to navigate (AFC).
> Is there any data suggesting that's been a net improvement for new users?
>
> Pete
> On Sep 1, 2014 4:38 PM, "Risker" <risker.wp@gmail.com> wrote:
>
> > Wasn't the creation of the DRAFT namespace at least in part a response to
> > concerns raised at ACTRIAL, in particular new, poorly developed articles
> > showing up in mainspace?
> >
> > Risker/Anne
> >
> >
> > On 1 September 2014 19:08, Joe Decker <joedecker@gmail.com> wrote:
> >
> > > This, to the best of my knowledge, represents the entirety of the WMF's
> > > response to ACTRIAL. To the extent that there was additional feedback
> > > given, it was not given at WP:ACTRIAL, nor any other venue I am aware
> of.
> > >
> > > https://bugzilla.wikimedia.org/show_bug.cgi?id=30208
> > >
> > > --Joe
> > >
> > >
> > > On Mon, Sep 1, 2014 at 3:44 PM, Todd Allen <toddmallen@gmail.com>
> wrote:
> > >
> > > > That's the issue I cited above. You haven't heard more complaints,
> > > because
> > > > the complaint was pointless the first time and took a massive effort
> to
> > > > produce.
> > > >
> > > > The underlying issue isn't fixed. We're still drowning in crap and
> spam
> > > > from people who never have the slightest intent of editing helpfully,
> > and
> > > > those who are newbies who genuinely want to help but need guidance
> get
> > > > caught in the crossfire aimed at the vandals and spammers. It is
> > > relatively
> > > > rare that when a genuinely new editor's first edit is a creation, it
> is
> > > the
> > > > creation of an appropriate article on a workable subject, and that's
> > > > normally more by dumb luck than them having actual knowledge that
> they
> > > > should do it.
> > > >
> > > > So, consider that a complaint. The proposed fix didn't work, and most
> > > > people at the time didn't figure it would work, but it was clearly
> the
> > > best
> > > > we were going to get.
> > > >
> > > >
> > > > On Mon, Sep 1, 2014 at 4:20 PM, Philippe Beaudette <
> > > > pbeaudette@wikimedia.org
> > > > > wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > > On Sep 1, 2014, at 8:45 AM, Todd Allen <toddmallen@gmail.com>
> > wrote:
> > > > > >
> > > > > > That's contradicted by, among other things, ACTRIAL as mentioned
> > > above.
> > > > > The
> > > > > > en.wp community came to a clear consensus for a major change, and
> > the
> > > > WMF
> > > > > > shrugged and said "Nah, rather not."
> > > > >
> > > > > That's... Not exactly what I remember happening there. What I
> > remember
> > > > was
> > > > > that a pretty good number (~500) of enwiki community members came
> > > > together
> > > > > and agreed on a problem, and one plan for how to fix it and asked
> > the
> > > > WMF
> > > > > to implement it. The WMF evaluated it, and saw a threat to a basic
> > > > project
> > > > > value. WMF then asked "what's the problem you're actually trying to
> > > > > solve?", and proposed and built a set of tools to directly address
> > that
> > > > > problem without compromising the core value of openness. And it
> seems
> > > to
> > > > > have worked out pretty well because I haven't heard a ton of
> > complaints
> > > > > about that problem since.
> > > > >
> > > > > ______________________
> > > > > Philippe Beaudette
> > > > > Director, Community Advocacy
> > > > > _______________________________________________
> > > > > Wikimedia-l mailing list, guidelines at:
> > > > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > > > Wikimedia-l@lists.wikimedia.org
> > > > > Unsubscribe:
> > https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > > > <mailto:wikimedia-l-request@lists.wikimedia.org
> ?subject=unsubscribe>
> > > > >
> > > > _______________________________________________
> > > > Wikimedia-l mailing list, guidelines at:
> > > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > > Wikimedia-l@lists.wikimedia.org
> > > > Unsubscribe:
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > > >
> > >
> > >
> > >
> > > --
> > > Joe Decker
> > > www.joedecker.net
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>



--
Landline (UK) 01780 757 250
Mobile (UK) 0798 1995 792
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Hi,

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

2014-09-01 20:40 GMT+05:30 Marc A. Pelletier <marc@uberbox.org>:
...
>
> MV is a perfect example. 99% of the problems it objectively has (we
> ignore here matters of taste) derive from the difficulty of parsing the
> multitude overcomplicated templates living on File: pages to work around
> the fact that a wikitext page is complete and utter crap at storing
> metadata. It's not an argument against MV, it's an argument for getting
> rid of the horrid way we handle File: pages with ad-hoc workarounds.
> The *correct* solution is to fix the damn image pages, not to remove MV.

OK, I could buy that. But then why not fixing that *first*, so that
any MV implementation coming afterwards would be smooth?

> How is it that the old saying goes? "'We've always done things this
> way' is the most dangerous statement in any language?"
>
> -- Marc

Regards,

Yann

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 09/02/2014 02:52 AM, Yann Forget wrote:
> OK, I could buy that [fixing image pages]. But then why not
> fixing that *first*, so that
> any MV implementation coming afterwards would be smooth?

In the best of worlds, that would have been ideal.

Now, no doubt I'm going to be branded a cynic for this, but have you
ever /tried/ to standardize something on a project? Obviously, my frame
of reference is the English Wikipedia and not Commons; but in a world
where there exists at least six distinct templates whose primary
function is to transclude a single "<references/>" onto a page and where
any attempt to standardize to one of them unfailingly results in edit
wars, that doesn't seem like a plausible scenario.

Perhaps the problem is more fundamental than this, and we're only seeing
symptoms. I don't know.

But I /do/ know that waiting until every edge case is handled before
deploying (attempted) improvements to the site is doomed to failure. If
only because most of the edge case won't even be /findable/ until the
software is in place so that it can't work even in principle.

IMO, in practice, "get it working for the general case and most of the
obvious edge cases" is a reasonable standard; and I'm pretty sure that
MV qualified under that metric (and VE didn't).

I suppose much of my frustration over the MV keruffle is borne out of a
reaction I see much too often for my taste: editors yelling "OMG, look,
image X isn't properly attributed/licensed/etc in MV! Burn it with
fire!!!" rather than figuring out why X's image page isn't properly
parsed and /fixing/ it (and possibly an underlying template that could
fix dozen/hundred others in one fell swoop).I'm pretty sure that if half
as much effort had been spent fixing issues as was attempting to kill
MV, its fail rate would already be at "statistical anomaly" levels.

.. but my inner cynic is also pretty sure that many of the loudest
voices wanting to get rid of MV ostensibly because of its failings don't
actually /want/ those failings to be fixed because being able to say
"It's broken" rather than "I don't like it" sounds much more rational.

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <marc@uberbox.org> wrote:

> On 09/02/2014 02:52 AM, Yann Forget wrote:
> > OK, I could buy that [fixing image pages]. But then why not
> > fixing that *first*, so that
> > any MV implementation coming afterwards would be smooth?
>
> In the best of worlds, that would have been ideal.
>
> Now, no doubt I'm going to be branded a cynic for this, but have you
> ever /tried/ to standardize something on a project? Obviously, my frame
> of reference is the English Wikipedia and not Commons; but in a world
> where there exists at least six distinct templates whose primary
> function is to transclude a single "<references/>" onto a page and where
> any attempt to standardize to one of them unfailingly results in edit
> wars, that doesn't seem like a plausible scenario.
>
> Perhaps the problem is more fundamental than this, and we're only seeing
> symptoms. I don't know.
>
> But I /do/ know that waiting until every edge case is handled before
> deploying (attempted) improvements to the site is doomed to failure. If
> only because most of the edge case won't even be /findable/ until the
> software is in place so that it can't work even in principle.
>
> IMO, in practice, "get it working for the general case and most of the
> obvious edge cases" is a reasonable standard; and I'm pretty sure that
> MV qualified under that metric (and VE didn't).
>
> I suppose much of my frustration over the MV keruffle is borne out of a
> reaction I see much too often for my taste: editors yelling "OMG, look,
> image X isn't properly attributed/licensed/etc in MV! Burn it with
> fire!!!" rather than figuring out why X's image page isn't properly
> parsed and /fixing/ it (and possibly an underlying template that could
> fix dozen/hundred others in one fell swoop).I'm pretty sure that if half
> as much effort had been spent fixing issues as was attempting to kill
> MV, its fail rate would already be at "statistical anomaly" levels.
>
> .. but my inner cynic is also pretty sure that many of the loudest
> voices wanting to get rid of MV ostensibly because of its failings don't
> actually /want/ those failings to be fixed because being able to say
> "It's broken" rather than "I don't like it" sounds much more rational.
>
> -- Marc
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <marc@uberbox.org> wrote:

> On 09/02/2014 02:52 AM, Yann Forget wrote:
> > OK, I could buy that [fixing image pages]. But then why not
> > fixing that *first*, so that
> > any MV implementation coming afterwards would be smooth?
>
> In the best of worlds, that would have been ideal.
>
> Now, no doubt I'm going to be branded a cynic for this, but have you
> ever /tried/ to standardize something on a project? Obviously, my frame
> of reference is the English Wikipedia and not Commons; but in a world
> where there exists at least six distinct templates whose primary
> function is to transclude a single "<references/>" onto a page and where
> any attempt to standardize to one of them unfailingly results in edit
> wars, that doesn't seem like a plausible scenario.
>
> Perhaps the problem is more fundamental than this, and we're only seeing
> symptoms. I don't know.
>
> But I /do/ know that waiting until every edge case is handled before
> deploying (attempted) improvements to the site is doomed to failure. If
> only because most of the edge case won't even be /findable/ until the
> software is in place so that it can't work even in principle.
>
> IMO, in practice, "get it working for the general case and most of the
> obvious edge cases" is a reasonable standard; and I'm pretty sure that
> MV qualified under that metric (and VE didn't).
>
> I suppose much of my frustration over the MV keruffle is borne out of a
> reaction I see much too often for my taste: editors yelling "OMG, look,
> image X isn't properly attributed/licensed/etc in MV! Burn it with
> fire!!!" rather than figuring out why X's image page isn't properly
> parsed and /fixing/ it (and possibly an underlying template that could
> fix dozen/hundred others in one fell swoop).I'm pretty sure that if half
> as much effort had been spent fixing issues as was attempting to kill
> MV, its fail rate would already be at "statistical anomaly" levels.
>
> .. but my inner cynic is also pretty sure that many of the loudest
> voices wanting to get rid of MV ostensibly because of its failings don't
> actually /want/ those failings to be fixed because being able to say
> "It's broken" rather than "I don't like it" sounds much more rational.
>
> -- Marc
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org <javascript:;>
> ?subject=unsubscribe>



--
wittylama.com
Peace, love & metadata
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On Mon, Sep 1, 2014 at 11:44 AM, Fæ <faewik@gmail.com> wrote:

> On 01/09/2014, Marc A. Pelletier <marc@uberbox.org> wrote:
> ...
> > metadata. It's not an argument against MV, it's an argument for getting
> > rid of the horrid way we handle File: pages with ad-hoc workarounds.
> > The *correct* solution is to fix the damn image pages, not to remove MV.
> ...
>
> So, can you link me to a positive proposal to do the elemental
> foundation of this, and point to a realistic (and Foundation
> supported) proposal to the community to standardize licence templates
> on Commons?
>

More than that, we should actually have the license data (and other stuff
like attribution and descriptions) in a Wikidata-like structure instead of
messing with parsing templates at all. The page for that is
https://commons.wikimedia.org/wiki/Commons:Structured_data. Please do
participate in that process.

That really should have been done first instead of the CommonsMetadata
extension, in my personal opinion.
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 09/02/2014 10:35 AM, Liam Wyatt wrote:
> The key here in my opinion is:
> - clear communication about what state constitutes "success" (e.g. "When
> 80% of people who have opted in have STAYED opted-in")
> - clear communication about the progress towards that state (e.g. Showing
> the "success" factor in the little statistics on the "beta features" tab,
> and showing how close we are to that.)
> - only moving to the next stage when that state has been reached, (not a
> fixed schedule but "it is ready when it is ready, not before")
> - making it easy to try, and withdraw from, new things, always starting
> with opt-in before making it opt-out.

This sounds sane indeed. +1 from me, at the very least. Note how VE
did pretty much the opposite of that, and that was a disaster (the
rollout, not VE itself).

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 02/09/14 11:46, Marc A. Pelletier wrote:
> On 09/02/2014 02:52 AM, Yann Forget wrote:
>> OK, I could buy that [fixing image pages]. But then why not
>> fixing that *first*, so that
>> any MV implementation coming afterwards would be smooth?
> In the best of worlds, that would have been ideal.
>
> Now, no doubt I'm going to be branded a cynic for this, but have you
> ever /tried/ to standardize something on a project? Obviously, my frame
> of reference is the English Wikipedia and not Commons; but in a world
> where there exists at least six distinct templates whose primary
> function is to transclude a single "<references/>" onto a page and where
> any attempt to standardize to one of them unfailingly results in edit
> wars, that doesn't seem like a plausible scenario.

I have. It's a lot of work to set up and keep on track, and can take a
goodly long while to get going at all, but when it succeeds, it's
totally AWESOME.

Wasn't on Wikimedia, but should be totally doable here, too, provided
the time, energy, and utter insanity required. Principles are the same.

-I

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On Wed, Sep 3, 2014 at 12:58 PM, Isarra Yos <zhorishna@gmail.com> wrote:

> On 02/09/14 11:46, Marc A. Pelletier wrote:
>
>> On 09/02/2014 02:52 AM, Yann Forget wrote:
>>
>>> OK, I could buy that [fixing image pages]. But then why not
>>> fixing that *first*, so that
>>> any MV implementation coming afterwards would be smooth?
>>>
>> In the best of worlds, that would have been ideal.
>>
>> Now, no doubt I'm going to be branded a cynic for this, but have you
>> ever /tried/ to standardize something on a project? Obviously, my frame
>> of reference is the English Wikipedia and not Commons; but in a world
>> where there exists at least six distinct templates whose primary
>> function is to transclude a single "<references/>" onto a page and where
>> any attempt to standardize to one of them unfailingly results in edit
>> wars, that doesn't seem like a plausible scenario.
>>
>
> I have. It's a lot of work to set up and keep on track, and can take a
> goodly long while to get going at all, but when it succeeds, it's totally
> AWESOME.
>
> Wasn't on Wikimedia, but should be totally doable here, too, provided the
> time, energy, and utter insanity required. Principles are the same.


+1

The Wikimedia Foundation operates in a world in which incredible efforts at
collaboration, consensus-building, and creating standards in complex
environments happens *every day* -- but, that doesn't fit in too well with
the preferred narrative of "our community is impossible to wrangle." Maybe
that is why the lessons get ignored?

Pete
[[User:Peteforsyth]]
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
The Technology Committee would be well positioned to help create standards
across projects. Also, if there is a need to have a common set of features
across projects, I would prefer to have the Technology Committee make those
decisions. By doing so, the principles of democracy and consensus would
apply, and the benefits of features commonality could still be achieved.

Marc, thank you for speaking candidly.

Pine


On Wed, Sep 3, 2014 at 1:01 PM, Pete Forsyth <peteforsyth@gmail.com> wrote:

> On Wed, Sep 3, 2014 at 12:58 PM, Isarra Yos <zhorishna@gmail.com> wrote:
>
> > On 02/09/14 11:46, Marc A. Pelletier wrote:
> >
> >> On 09/02/2014 02:52 AM, Yann Forget wrote:
> >>
> >>> OK, I could buy that [fixing image pages]. But then why not
> >>> fixing that *first*, so that
> >>> any MV implementation coming afterwards would be smooth?
> >>>
> >> In the best of worlds, that would have been ideal.
> >>
> >> Now, no doubt I'm going to be branded a cynic for this, but have you
> >> ever /tried/ to standardize something on a project? Obviously, my frame
> >> of reference is the English Wikipedia and not Commons; but in a world
> >> where there exists at least six distinct templates whose primary
> >> function is to transclude a single "<references/>" onto a page and where
> >> any attempt to standardize to one of them unfailingly results in edit
> >> wars, that doesn't seem like a plausible scenario.
> >>
> >
> > I have. It's a lot of work to set up and keep on track, and can take a
> > goodly long while to get going at all, but when it succeeds, it's totally
> > AWESOME.
> >
> > Wasn't on Wikimedia, but should be totally doable here, too, provided the
> > time, energy, and utter insanity required. Principles are the same.
>
>
> +1
>
> The Wikimedia Foundation operates in a world in which incredible efforts at
> collaboration, consensus-building, and creating standards in complex
> environments happens *every day* -- but, that doesn't fit in too well with
> the preferred narrative of "our community is impossible to wrangle." Maybe
> that is why the lessons get ignored?
>
> Pete
> [[User:Peteforsyth]]
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <zhorishna@gmail.com> wrote:

> On 02/09/14 11:46, Marc A. Pelletier wrote:
>
>> On 09/02/2014 02:52 AM, Yann Forget wrote:
>>
>>> OK, I could buy that [fixing image pages]. But then why not
>>> fixing that *first*, so that
>>> any MV implementation coming afterwards would be smooth?
>>>
>> In the best of worlds, that would have been ideal.
>>
>> Now, no doubt I'm going to be branded a cynic for this, but have you
>> ever /tried/ to standardize something on a project? Obviously, my frame
>> of reference is the English Wikipedia and not Commons; but in a world
>> where there exists at least six distinct templates whose primary
>> function is to transclude a single "<references/>" onto a page and where
>> any attempt to standardize to one of them unfailingly results in edit
>> wars, that doesn't seem like a plausible scenario.
>>
>
> I have. It's a lot of work to set up and keep on track, and can take a
> goodly long while to get going at all, but when it succeeds, it's totally
> AWESOME.
>
> Wasn't on Wikimedia, but should be totally doable here, too, provided the
> time, energy, and utter insanity required. Principles are the same.
>
> -I
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
> Hoi,
> Maybe... but it assumes that we have plenty of time and work sequently.
> Both are not the case and as it is, the framework is broken.to the extend
> that people refuse to use it. So yes, ideally you want to fix many issues
> nicely and in a collaborative manner. At the same time our readers are
> disappearing from our old platform and new editors are not happening on the
> old platform.

Open source has a lot of benefits. Delivering quality software '''on a
schedule''' is not one of them. But it can be done. We did it with
Zend Framework with quarterly major releases. We also turned community
sentiment around after the negative reaction to 1.0, which was
released right before I joined Zend.

I'd say that the most impactful thing we did to right the ship was
hearing people out wherever they chose to discuss ZF. We monitored all
channels of communication and responded to frustrations as quickly as
possible. Most of our comments boiled down to:

"You're right. We have a problem here. Will you help us fix it?"

In other words, we made sure we walked the walk so that we could
invite others to walk with us. And the constructive critics figured
out that walking is more fun/satisfying than all the talking. Of
course, that meant we walked away from some critics who weren't
interested in being constructive. We never looked back.

I believe this community can also turn all this dysfunction and stress
in to something positive. So, let's start walking; here's a
proposal/challenge for those who think Media Viewer isn't worthy:

Take all that time you're investing in petitioning the community and
use it to build something better than Media Viewer. A lot of you have
already identified pain points in MV and some solutions have also been
put forward; so, if you are not planning to get involved in the
project that the WMF has set up for whatever reasons, join us in
building what Media Viewer should be without the complications of
dealing with the WMF. If it turns out to be a better solution than
Media Viewer, then I suggest we create a petition to replace MV with
the community's solution. That's the kind of positive, action-oriented
petition I can sign.

I'll even kick it off. We can start listing the requirements for the
Worthy Media Viewer on this page:
https://meta.wikimedia.org/wiki/WorthyMV.

So, who's ready to walk?

,Wil

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 25.08.2014 06:07, Marc A. Pelletier wrote:
> On 08/24/2014 11:19 PM, Pine W wrote:
>> I have
>> heard people say "don't force an interface change on me that I don't
>> think
>> is an improvement."
>
> I do not recall a recent interface change deployment that wasn't
> accompanied with, at the very least, some method of opting out. Did I
> miss one?
>
> -- Marc
>

FLOW?

Unless you count leaving the project as opt-out.

Cheers
Yaroslav

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
> On 25.08.2014 06:07, Marc A. Pelletier wrote:
> FLOW?

Last I checked, Flow isn't deployed except as experiments in a handful
of places, and is still in active deployment.

But you're correct that this would constitute a replacement rather than
a new method alongside the old. A long, long overdue and desperately
needed replacement -- but a replacement nonetheless.

That also explains the very deliberate development and feedback loop.

-- Marc



_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <marc@uberbox.org> wrote:

> On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
> > On 25.08.2014 06:07, Marc A. Pelletier wrote:
> > FLOW?
>
> Last I checked, Flow isn't deployed except as experiments in a handful
> of places, and is still in active deployment.
>
> But you're correct that this would constitute a replacement rather than
> a new method alongside the old. A long, long overdue and desperately
> needed replacement -- but a replacement nonetheless.
>
> That also explains the very deliberate development and feedback loop.
>
> -- Marc
>
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <marc@uberbox.org> wrote:
> On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
>> On 25.08.2014 06:07, Marc A. Pelletier wrote:
>> FLOW?
>
> Last I checked, Flow isn't deployed except as experiments in a handful
> of places, and is still in active deployment.
>
> But you're correct that this would constitute a replacement rather than
> a new method alongside the old. A long, long overdue and desperately
> needed replacement -- but a replacement nonetheless.
>
> That also explains the very deliberate development and feedback loop.
>
> -- Marc
>
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <jayen466@gmail.com> wrote:
> I'm not sure the term "loop" is appropriate. So far, I see little evidence
> that feedback provided [1] is making any appreciable difference.
>
> [1] https://en.wikipedia.org/wiki/Wikipedia_talk:Flow
>
>
> On Fri, Sep 5, 2014 at 5:34 PM, Marc A. Pelletier <marc@uberbox.org> wrote:
>
>> On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
>> > On 25.08.2014 06:07, Marc A. Pelletier wrote:
>> > FLOW?
>>
>> Last I checked, Flow isn't deployed except as experiments in a handful
>> of places, and is still in active deployment.
>>
>> But you're correct that this would constitute a replacement rather than
>> a new method alongside the old. A long, long overdue and desperately
>> needed replacement -- but a replacement nonetheless.
>>
>> That also explains the very deliberate development and feedback loop.
>>
>> -- Marc
>>
>>
>>
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> Wikimedia-l@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
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 <wllm@wllm.com> wrote:

> This somewhat circuitously brings us back to the subject. We have a
> chance to rollout Flow the right way. There are some questions that
> come to mind that might tell us if we're headed for a big win or a
> bigger debacle:
>
> 1) Is the WMF working with the community as closely and substantially
> as possible to make sure Flow is ready for primetime?
>
> 2) Is the community preparing itself for a major change, not only in
> interface, but to some degree in wiki-philosophy about how discussions
> are conducted- not to mention the notion that, while wiki software can
> do almost anything involving asynchronous online communication, it
> can't do everything as well as other interfaces?
>
> I think Flow will be particularly challenging. I deployed Liquid
> Threads on another site. I liked the threaded interface, as did
> others. But overall it was roundly rejected because it was harder to
> search (I only found out you have to add the namespace to the
> searchable namespace in LocalSettings.php later), and it invasively
> took over all discussion pages, among other headache. Problems like
> these could easily be addressed before a rollout, but they should be
> addressed as early as possible. It is notable, however, that the more
> our users used it, the more they seemed to like it.
>
> What can we do to make the Flow rollout as smooth as starting '''now'''?
>
> ,Wil
>
> On Fri, Sep 5, 2014 at 9:34 AM, Marc A. Pelletier <marc@uberbox.org>
> wrote:
> > On 09/05/2014 11:12 AM, Yaroslav M. Blanter wrote:
> >> On 25.08.2014 06:07, Marc A. Pelletier wrote:
> >> FLOW?
> >
> > Last I checked, Flow isn't deployed except as experiments in a handful
> > of places, and is still in active deployment.
> >
> > But you're correct that this would constitute a replacement rather than
> > a new method alongside the old. A long, long overdue and desperately
> > needed replacement -- but a replacement nonetheless.
> >
> > That also explains the very deliberate development and feedback loop.
> >
> > -- Marc
> >
> >
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> <https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org>
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Interesting. What I'm noticing in both this discussion and the
discussions around MV is that a lot of us think that the solution has
value, but the features are not prioritized well. I don't have much
experience with Trello, but I know of lots of other tools (Bugzilla is
one, I believe) that can support discussions from the community per
feature/bug and have a "voting" feature.

I don't support RfC's on full systems. If we get to this point we've
all been doing it wrong for far too long to have an easy fix. But I
think that RfC-like discussions on every individual feature make a lot
of sense. And I think that one of the biggest steps the WMF can take
is to base prioritization of features on such "RfC"'s in a
well-defined and well-understood way. IMO, user studies are important,
but they'd be better used to '''convince''' the community that
something is useful from a perspective that may be very different from
a very experienced user's, rather than force features down our
throats.

I know that this is already happening to some degree. But is the WMF
'''obligated''' to prioritize features based on community feedback?

As a separate question, would we find it easier to do this onwiki, and
are there extensions that we can build with the WMF to facilitate such
discussions and feature management? Or we cool with the tools we
already have?

,Wil

On Fri, Sep 5, 2014 at 10:58 AM, Risker <risker.wp@gmail.com> wrote:
> I think there have been some pretty strong indications over the years that
> the current talk page system needs to be improved. However, there's been
> little discussion at all about whether Flow is that improvement. I have
> been following the development for quite a while, and it really looks like
> the system was developed backwards: essential functions for effective
> discussion that already exist and are used on a daily basis were not
> included in the initial designs, while the design incorporated plenty of
> bells and whistles that were considered desirable (although the reasons for
> desirability weren't necessarily universally held or particularly clear).
> This has resulted in a huge amount of re-engineering to incorporate (some
> of the) needed functions , and a lot of downplaying of the feedback given
> because the feedback has conflicted with the "bells and whistles" of the
> original design. There is also the fact that it would add another
> completely different user interface to the editing process, which increases
> barriers for existing users but even more so for new users.
>
> In other words, the issues with Flow are so deeply rooted in its core
> design and philosophy that it may not be possible to come up with a product
> that is actually useful on the projects we have to replace the discussion
> system we have. It seems that the Flow team has assembled the ingredients
> to make a chocolate cake with the hope that it will be a suitable
> replacement for vegetable stew.
>
> Risker/Anne

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On Sat, Sep 6, 2014 at 3:29 AM, Wil Sinclair <wllm@wllm.com> wrote:
> This somewhat circuitously brings us back to the subject. We have a
> chance to rollout Flow the right way. There are some questions that
> come to mind that might tell us if we're headed for a big win or a
> bigger debacle:
>
> 1) Is the WMF working with the community as closely and substantially
> as possible to make sure Flow is ready for primetime?
>
> ...
>
> What can we do to make the Flow rollout as smooth as starting '''now'''?

IMO the WMF should stop focusing on English Wikipedia as a target
deploy site, and stop allowing its product management team and WMF
staff in general to be salesman for it - it is scaring the community
that all WMF staff seem to be so heavily vested in this 'product' as
the salvation of the wikis.

Risker's assessment of the design problems is spot on. As such, a
typical WMF-style big bang deploy of Flow is going to be the most
almighty bang the WMF has ever seen. And the community is rightly
worried that 2015 is going to be the year that WMF forces Flow onto
the projects using its typical deploy methodology.

Start development of a rollout plan, and gain consent from the
communities on that rollout plan.

After rollout on MediaWiki has stablised, Meta-Wiki should be high on
the deploy list, as should any wiki which has LQT enabled by community
request. Until discussion-focused wikis, such as Meta, universally
*likes* Flow, trialling it or rolling it out onto any
'work'/content-focused wiki without community consent is silly. Until
it is satisfactorily deployed onto at least one non-English language
content project, it shouldnt be deployed onto English Wikipedia, as it
is safe to assume that the design will be too English Wikipedia
specific, and will fail badly on non-English projects, becoming
another WMF tool which looks nice on English Wikipedia but other
projects cant have it because it is designed wrong.

Allow project level opt-out of the Flow rollout plan. Focus on the
projects that want it, and find/employ community advocates with the
necessary language skills for the projects at the top of the rollout
plan. They need to start work *now*. They need to document existing
project workflows, talking with bot operators and site admins
especially when developing a migration plan. Bot and gadget software
will need to be re-engineered *before* the deploy.

--
John Vandenberg

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
I really don't like the way that people are referring to Flow as a done
deal with an inevitable roll out. Nothing remotely close to workable
software has been produced, no case has been made that the purported
problems being addressed by this top-down software project are valid issues
in the community, the range of unintended effects that will be cause by the
mass archiving of talk pages and move to a new "flashy" system hasn't been
properly assessed.

With Visual Editor, there was a clear need for WYSIWYG capabilities —
although the software rolled out was grossly inadequate and the roll out
process hamhanded (not to say incompetent). With Media Viewer, at least
there is a clear benefit to a certain percentage of WP readers to offset
the inconveniences resulting from mildly inadequate software. With Flow we
are looking at the potential of grossly inadequate software with no
apparent "saving graces" other than the fact that the old software is old
and the new software will be new and that things will look nice.

If this is done wrong, it will be a catastrophe for WMF far bigger than
what happened with VE.

Wil Sinclair, an enthusiast for the LiquidThreads/Flow mechanism for talk
pages, is in an excellent position to give us some A/B numbers for
participation at his site, with in without LiquidThreads being imposed from
above.

How did that work out with participation levels at the OffWiki site, Mr.
Sinclair?

How many very active editors has the convenient LiquidThreads mechanism
generated for your site?

How many edits have taken place in the month after LiquidThreads was
installed over "community" objections versus the month before it was
installed?

Has the clean up process been easy reconverting to MediaWiki without the
LiquidThreads extension?

Bottom line: OffWiki site participation was blown up by a unilateral move
to LiquidThreads by the "tech department."

Observe and learn.

Tim Davenport
Carrite on WP /// Randy from Boise on WPO
Corvallis, OR




=======

Wil Sinclair wrote:
>>This somewhat circuitously brings us back to the subject. We have a
chance to rollout Flow the right way. There are some questions that
come to mind that might tell us if we're headed for a big win or a
bigger debacle:

>>1) Is the WMF working with the community as closely and substantially
as possible to make sure Flow is ready for primetime?

>>2) Is the community preparing itself for a major change, not only in
interface, but to some degree in wiki-philosophy about how discussions
are conducted- not to mention the notion that, while wiki software can
do almost anything involving asynchronous online communication, it
can't do everything as well as other interfaces?

>>I think Flow will be particularly challenging. I deployed Liquid
Threads on another site. I liked the threaded interface, as did
others. But overall it was roundly rejected because it was harder to
search (I only found out you have to add the namespace to the
searchable namespace in LocalSettings.php later), and it invasively
took over all discussion pages, among other headache. Problems like
these could easily be addressed before a rollout, but they should be
addressed as early as possible. It is notable, however, that the more
our users used it, the more they seemed to like it.

>>What can we do to make the Flow rollout as smooth as starting '''now'''?

,Wil
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

1 2 3 4 5 6  View All