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

classic Classic list List threaded Threaded
146 messages Options
12345678
Reply | Threaded
Open this post in threaded view
|

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

Gerard Meijssen-3
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 <[hidden email]>
wrote:

> On Aug 31, 2014 11:46 PM, "Pine W" <[hidden email]> 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
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]>
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 <[hidden email]>
> wrote:
>
> > On Aug 31, 2014 11:46 PM, "Pine W" <[hidden email]> 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
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Craig Franklin
In reply to this post by Gerard Meijssen-3
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 <[hidden email]>
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 <[hidden email]>
> wrote:
>
> > On Aug 31, 2014 11:46 PM, "Pine W" <[hidden email]> 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
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Marc-Andre
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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Fæ
On 01/09/2014, Marc A. Pelletier <[hidden email]> 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
--
[hidden email] https://commons.wikimedia.org/wiki/User:Fae

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Todd Allen
In reply to this post by Marc-Andre
On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier <[hidden email]> wrote:

> Warning, tl;dr rant below in which live my personal opinion.
>
> On 09/01/2014 08:00 AM, Craig Franklin wrote:
> > fter the catastrophic
> > aborted launch of the Visual Editor, complete with numerous bugs that
> > should have been picked up in even a cursory unit testing scheme or
> > regression testing scheme prior to being deployed to a productive
> > environment, there's not a good deal of faith left.
>
> That /was/ a bad botch; and (IMO) the reason why that happened is that
> someone set a hard deploy date that should never have been set in stone
> and then held to it even though VE was clearly not ready.  (It is *now*
> at a point with rollout would have been plausible).
>
> Clearly nobody at WMF Engineering is going to do *that* again.
>

We've heard that before.

>
> But I also don't think that was causative in any way; the tension
> between WMF holding the reins to the servers and (part of) the
> communities was the same years before that.  ACCTRIAL anyone?
>

Sure, for reasons I'll get to below. That contradicts the rest of what you
said here.


>
> The fundamental issue is that the WMF is attempting to provide some
> direction, and the communities do not want any (for various and
> divergent reasons).
>

I don't think it's that the communities don't want any direction. It's that
large, open projects historically managed by their volunteers are not
amenable to top-down, authoritarian direction. All that will do is start
fights, to the detriment of everyone and especially to the detriment of
said projects. None of us are out a paycheck if we scale back our activity
or walk away in disgust.


>
> I side with the WMF in this; not because they sign my paycheck (I'm in
> Ops - I have zero to do with dev work) but because I've been a
> Wikipedian for >10 years and I *see* that the communities have no
> capacity for change - or that what little change manages to gather
> micro-consensus is local and often shortsighted.  The projects are
> directionless, and it shows in the increasing stagnation and calcification.
>

That's contradicted by, among other things, ACTRIAL as mentioned above. The
en.wp community came to a clear consensus for a major change, and the WMF
shrugged and said "Nah, rather not." When treated that way, do you think
the community has much appetite to continue discussing necessary changes
when the last time was a significant effort ultimately ending in futility,
not because of a failure on the community's part, but because of WMF's
refusal to listen?


>
> Are all the attempts by the WMF at providing direction successes?  Not
> even close.  Some of the things they tried ranged from merely misguided
> to downright daft (also IMO, obviously).
>
> The process *does* need community engagement.  That'd seriously
> increases the value of what (and how) the WMF does things, and likely
> reduce the number of bad ideas from the outset.
>

As above, that's not going to happen if that engagement continues to result
in brushoffs. Look at Flow. One overwhelming message is "We don't want it
at all" (and that demands real consideration, not dismissive comments about
"resistance to change" and "power users"), but when asked what could at
least make it better, the answers of "Preserve ability for anyone to
refactor posts as needed, don't restrict to admins" and "Don't limit
indentation" have fallen on deaf ears. Again, if there's no one listening,
people are not going to continue talking to what by all appearances is a
brick wall.


>
> But the community engagement it needs is one that is done in good faith;
> something which I have yet to see more than exceptions here and there.
> It also needs fewer reactionnary hotheads.  Editing sucks.  Reading is
> lacking.  Most of the tooling is crap.  That X editors have gotten used
> to it and have implemented piles of workarounds doesn't justify keeping
> the old shit around.
>

Maybe. I don't really think it's crap. Reflinks wasn't crap. That doesn't
mean we can't do better, but we need to do actually better, not just "We
need to do something, this is something, so do it!"

Regardless, same again: That needs to be met with good faith on the other
side, to stop just plowing ahead when everyone's saying "WAIT, there's
serious problems here!". Engagement doesn't work if it's the classic
"suggestions box" positioned directly over a garbage can.


>
> MV is a perfect example.  99% of the problems it objectively has (we
> ignore here matters of taste) derive from the difficulty of parsing the
> multitude overcomplicated templates living on File: pages to work around
> the fact that a wikitext page is complete and utter crap at storing
> metadata.  It's not an argument against MV, it's an argument for getting
> rid of the horrid way we handle File: pages with ad-hoc workarounds.
> The *correct* solution is to fix the damn image pages, not to remove MV.
>
> How is it that the old saying goes?  "'We've always done things this
> way' is the most dangerous statement in any language?"
>

Change for the sake of change can easily be as dangerous. I think most
agree that some changes are necessary. As above, one of the historical
blowups was when the en.wp community came to clear consensus, asked for a
change, and just got a dismissive WONTFIX. If you want to drive engagement,
show real willingness to respond to that engagement with actions and real
changes, not yet another promise to do better next time, we really really
mean it now. Sometimes, that might mean doing things the person doing them
doesn't personally agree with.


>
> -- Marc
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Marc-Andre
On 09/01/2014 11:45 AM, Todd Allen wrote:
> On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier <[hidden email]> 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 waaaay
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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Martijn Hoekstra
In reply to this post by Marc-Andre
On Sep 1, 2014 5:10 PM, "Marc A. Pelletier" <[hidden email]> 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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Marc-Andre
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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

David Gerard-2
In reply to this post by Martijn Hoekstra
On 1 September 2014 17:57, Martijn Hoekstra <[hidden email]> 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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Abd ulRahman Lomax
In reply to this post by Craig Franklin
"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 <[hidden email]>
>To: Wikimedia Mailing List <[hidden email]>
>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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Abd ulRahman Lomax
In reply to this post by Gerard Meijssen-3
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 <[hidden email]>
>To: Wikimedia Mailing List <[hidden email]>
>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 <[hidden email]>
>wrote:
>
>> On Aug 31, 2014 11:46 PM, "Pine W" <[hidden email]> 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
>> > [hidden email]
>> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:[hidden email]?subject=unsubscribe>
>
>
>
>
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> [hidden email]
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:[hidden email]?subject=unsubscribe>
>>
>_______________________________________________
>Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>[hidden email]
>Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Gerard Meijssen-3
In reply to this post by Pine W
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 <[hidden email]> 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" <[hidden email]>
> 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 <[hidden email]>
> > wrote:
> >
> > > On Aug 31, 2014 11:46 PM, "Pine W" <[hidden email]> 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
> > > > [hidden email]
> > > > Unsubscribe:
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Ziko van Dijk-3
In reply to this post by Marc-Andre
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 <[hidden email]>:

> 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
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Philippe Beaudette-2
In reply to this post by Todd Allen



> On Sep 1, 2014, at 8:45 AM, Todd Allen <[hidden email]> 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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Pete Forsyth-2
On Sep 1, 2014 3:21 PM, "Philippe Beaudette" <[hidden email]>
wrote:
>
> > On Sep 1, 2014, at 8:45 AM, Todd Allen <[hidden email]> 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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Todd Allen
In reply to this post by Philippe Beaudette-2
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 <[hidden email]
> wrote:

>
>
>
> > On Sep 1, 2014, at 8:45 AM, Todd Allen <[hidden email]> 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
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <
> [hidden email]
> > wrote:
>
> >
> >
> >
> > > On Sep 1, 2014, at 8:45 AM, Todd Allen <[hidden email]> 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
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>



--
Joe Decker
www.joedecker.net
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <
> > [hidden email]
> > > wrote:
> >
> > >
> > >
> > >
> > > > On Sep 1, 2014, at 8:45 AM, Todd Allen <[hidden email]> 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
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
>
>
>
> --
> Joe Decker
> www.joedecker.net
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

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

Pete Forsyth-2
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <
> > > [hidden email]
> > > > wrote:
> > >
> > > >
> > > >
> > > >
> > > > > On Sep 1, 2014, at 8:45 AM, Todd Allen <[hidden email]>
> 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
> > > > [hidden email]
> > > > Unsubscribe:
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > > <mailto:[hidden email]?subject=unsubscribe>
> > > >
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > >
> >
> >
> >
> > --
> > Joe Decker
> > www.joedecker.net
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
12345678