Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Cuenca]

Gerard,

Citizenship in the digital world is more flexible than in the real world,
but that doesn't mean that it doesn't exist or that it cannot be
characterized. It is just a matter of providing a conceptual framework for
defining rights, obligations, etc. and it avoids precisely that a person,
or a group of people, or part or the community, or a sub-community, or any
of the several communities, overtakes a decision-making process that
belongs to the whole.

The terms of use can be considered a first approach to this tough problem,
and it has many interesting keywords: "Part of our mission is to", "You are
free to", "Under the following conditions", "With the understanding that".
Unfortunately it just a "terms of use", not a "terms of community".

If such a thing came into being, there you could state: "Part of our
mission is to promote a healthy collaboration between ourselves, you are
free to represent yourself and others in our community, under the condition
that they have provided you explicit consent and that you respect the
interests of non-represented users, with the understanding that we work for
the benefit of all humanity and not only for our own."

Cheers,
Micru


On Fri, Aug 15, 2014 at 12:27 PM, Gerard Meijssen  wrote:

> Hoi,
> David, who is the community and how do you get members of the community
> recognise and respect the decisions it does not like that are taken on
> their behalf by "its" representatives. We do not have one community, we
> have many. The interests people aim for are diverse and all too often
> contradictory..
>
> Really, in the past one part of the community insisted that it ALWAYS
> requires to be able to have the deciding influence for "its" project.. That
> clearly pains the picture for me.
> Thanks,
>   GerardM
>
>
> On 15 August 2014 10:17, David Cuenca  wrote:
>
> > On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating <
> > chriskeatingw...@gmail.com>
> > wrote:
> >
> > > how should this be solved?
> > >
> > > To me it's saying that no matter who is informed, the WMF can never
> > expect
> > > that their work won't be overruled.
> > >
> > > That is problematic (regardless of who has the final authority)
> >
> >
> > A first step would be to abide to the principles of Open Process
> > http://meatballwiki.org/wiki/OpenProcess
> >
> > Namely:
> >
> >- Transparency - all communications and decisions are public and
> >archived, so anyone interested may get all information
> >- No time constraints - all decisions (democratic or not) are
> suggested
> >or announced a reasonable timespan before they become effective. So
> > there
> >is still time for discussion and even last minute intervention.
> >- Participation - in principle (this opens the chance for restrictions
> >in case of problems) anyone is welcome to participate (discussions,
> >decisions *and* work)
> >- * Reflection and reversibility - any decision may be reversed if the
> >results are not as expected. *
> >- Tolerance - any system or process should have the flexibility in the
> >application of its - necessary - rules
> >- Sharing and collaborating on visible and accessible goals and
> >resources
> >
> > Then a second step would be to engage the community, not only as
> something
> > that has to be "managed", but as an equal partner that has to take up
> > responsibilities and who is able to affect decisions. This of course
> means
> > a paradigm shift moving away from "community liaisons" and into the realm
> > of helping contributors to constitute themselves enabling them to take
> up a
> > shared ownership role without the need of a formal organization.
> >
> > I don't think the wmf is entirely responsible for making this happen,
> there
> > is also have to be a general will to embody such a spirit without
> resorting
> > to staff, hierarchies, or votes. The problem is that most of us live in a
> > world that doesn't work this way, and the attached structural flaws are
> > imported, when there is no need to.
> >
> > Anyhow, that should be something to speak about when the tensions have
> been
> > defused.
> >
> > Cheers,
> > Micru
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



-- 
Etiamsi omnes, ego non
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Gerard Meijssen]

Hoi,
David, who is the community and how do you get members of the community
recognise and respect the decisions it does not like that are taken on
their behalf by "its" representatives. We do not have one community, we
have many. The interests people aim for are diverse and all too often
contradictory..

Really, in the past one part of the community insisted that it ALWAYS
requires to be able to have the deciding influence for "its" project.. That
clearly pains the picture for me.
Thanks,
  GerardM


On 15 August 2014 10:17, David Cuenca  wrote:

> On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating <
> chriskeatingw...@gmail.com>
> wrote:
>
> > how should this be solved?
> >
> > To me it's saying that no matter who is informed, the WMF can never
> expect
> > that their work won't be overruled.
> >
> > That is problematic (regardless of who has the final authority)
>
>
> A first step would be to abide to the principles of Open Process
> http://meatballwiki.org/wiki/OpenProcess
>
> Namely:
>
>- Transparency - all communications and decisions are public and
>archived, so anyone interested may get all information
>- No time constraints - all decisions (democratic or not) are suggested
>or announced a reasonable timespan before they become effective. So
> there
>is still time for discussion and even last minute intervention.
>- Participation - in principle (this opens the chance for restrictions
>in case of problems) anyone is welcome to participate (discussions,
>decisions *and* work)
>- * Reflection and reversibility - any decision may be reversed if the
>results are not as expected. *
>- Tolerance - any system or process should have the flexibility in the
>application of its - necessary - rules
>- Sharing and collaborating on visible and accessible goals and
>resources
>
> Then a second step would be to engage the community, not only as something
> that has to be "managed", but as an equal partner that has to take up
> responsibilities and who is able to affect decisions. This of course means
> a paradigm shift moving away from "community liaisons" and into the realm
> of helping contributors to constitute themselves enabling them to take up a
> shared ownership role without the need of a formal organization.
>
> I don't think the wmf is entirely responsible for making this happen, there
> is also have to be a general will to embody such a spirit without resorting
> to staff, hierarchies, or votes. The problem is that most of us live in a
> world that doesn't work this way, and the attached structural flaws are
> imported, when there is no need to.
>
> Anyhow, that should be something to speak about when the tensions have been
> defused.
>
> Cheers,
> Micru
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Cuenca]

On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating 
wrote:

> how should this be solved?
>
> To me it's saying that no matter who is informed, the WMF can never expect
> that their work won't be overruled.
>
> That is problematic (regardless of who has the final authority)


A first step would be to abide to the principles of Open Process
http://meatballwiki.org/wiki/OpenProcess

Namely:

   - Transparency - all communications and decisions are public and
   archived, so anyone interested may get all information
   - No time constraints - all decisions (democratic or not) are suggested
   or announced a reasonable timespan before they become effective. So there
   is still time for discussion and even last minute intervention.
   - Participation - in principle (this opens the chance for restrictions
   in case of problems) anyone is welcome to participate (discussions,
   decisions *and* work)
   - * Reflection and reversibility - any decision may be reversed if the
   results are not as expected. *
   - Tolerance - any system or process should have the flexibility in the
   application of its - necessary - rules
   - Sharing and collaborating on visible and accessible goals and
   resources

Then a second step would be to engage the community, not only as something
that has to be "managed", but as an equal partner that has to take up
responsibilities and who is able to affect decisions. This of course means
a paradigm shift moving away from "community liaisons" and into the realm
of helping contributors to constitute themselves enabling them to take up a
shared ownership role without the need of a formal organization.

I don't think the wmf is entirely responsible for making this happen, there
is also have to be a general will to embody such a spirit without resorting
to staff, hierarchies, or votes. The problem is that most of us live in a
world that doesn't work this way, and the attached structural flaws are
imported, when there is no need to.

Anyhow, that should be something to speak about when the tensions have been
defused.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Mark]

On 8/14/14, 3:35 PM, David Gerard wrote:

On 14 August 2014 13:56, David Cuenca  wrote:


It would be more sensible to let contributors participate in the tech
roadmap in more formal and empowered way than now, because without that
early participation there is no possibility for later consensus.


A pattern we see over and over is that the developers talk at length
about what they're working on in several venues, then it's released
and people claiming to speak for the community claim they were not
adequately consulted. Pretty much no matter what steps were taken to
do so, and what new steps are taken to do so. Because there's always
someone who claims their own lack of interest is someone else's fault.


I actually have not found the "beta feature" feedback pages to be very 
responsive. Is that what you had in mind? I've made an attempt to be on 
top of these things and discuss them before the rollout, lest I come to 
the party late and unhelpfully. But the beta-feature talk pages are full 
of people with questions and problems and no responses or solutions, or 
really any signs of life from anyone in a position to do anything.


On the plus side, I was driven by this frustration to figure out what 
"git" and "gerrit" are. A simple bug in December rendered the beta 
"Nearby" feature completely unusable for weeks. There were many comments 
on the Talk page for that feature complaining that it had semi-recently 
become completely broken. But nobody seemed to be acknowledging, 
explaining, or making any effort to fix it. I eventually dug into the 
matter and discovered that the recently introduced problem was obvious 
and the fix was literally a 2-line patch. Then I spent about 1000x more 
time than it took to author the 2-line patch to figure out how to submit 
these two lines through git/gerrit bureaucracy. But being sufficiently 
annoyed, I did manage to submit a patch, which was eventually applied, 
and after some delay that fixed the brokenness. But that experience led 
me to believe that nobody is really paying attention to beta feedback!


-Mark


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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Fri, 15 Aug 2014, at 09:47, svetlana wrote:
> On Thu, 14 Aug 2014, at 23:35, David Gerard wrote:
> > On 14 August 2014 13:56, David Cuenca  wrote:
> > 
> > > It would be more sensible to let contributors participate in the tech
> > > roadmap in more formal and empowered way than now, because without that
> > > early participation there is no possibility for later consensus.
> > 
> > 
> > A pattern we see over and over is that the developers talk at length
> > about what they're working on in several venues, then it's released
> > and people claiming to speak for the community claim they were not
> > adequately consulted. Pretty much no matter what steps were taken to
> > do so, and what new steps are taken to do so. Because there's always
> > someone who claims their own lack of interest is someone else's fault.
> > 
> > 
> > - d.
> 
> How could presence of interest help people to fix media viewer?
> From its early beta testing, I wrote numerous feedback about how going 
> fullscreen is a misleading redundant step.

confusing wording; i mean: they still coded it to go fullscreen nomatter what
i wanted them to have a dialog of sorts instead

> It was not implemented.
> What more interest could I have?
> 
> It's not like I care about this too much, but I'm curious as to what you 
> expect me to be able to do to display my "interest".
> 
> svetlana

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Thu, 14 Aug 2014, at 23:35, David Gerard wrote:
> On 14 August 2014 13:56, David Cuenca  wrote:
> 
> > It would be more sensible to let contributors participate in the tech
> > roadmap in more formal and empowered way than now, because without that
> > early participation there is no possibility for later consensus.
> 
> 
> A pattern we see over and over is that the developers talk at length
> about what they're working on in several venues, then it's released
> and people claiming to speak for the community claim they were not
> adequately consulted. Pretty much no matter what steps were taken to
> do so, and what new steps are taken to do so. Because there's always
> someone who claims their own lack of interest is someone else's fault.
> 
> 
> - d.

How could presence of interest help people to fix media viewer?
From its early beta testing, I wrote numerous feedback about how going 
fullscreen is a misleading redundant step.
It was not implemented.
What more interest could I have?

It's not like I care about this too much, but I'm curious as to what you expect 
me to be able to do to display my "interest".

svetlana

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Isarra Yos]

On 14/08/14 16:07, Yaroslav M. Blanter wrote:
This is actually not correct. Take pending changes on the English 
Wikipedia as an example - people used to complain a lot on how RfC's 
were closed, but this is the business of the community. I have never 
heard anybody complaining that the trial sucked, or that PC itself 
does not work properly. There was a discussion, there was a trial, 
everything was properly announced, and everything from the 
developers's side was done perfectly or close to perfectly.


Take Phase I Wikidata - this is smth I was actively participating in 
and watched it from the close distance. Everything went smoothly, with 
the Hungarian Wikipedia trial starting first, the Italian Wikipedia a 
bit later, when feedback was taken into account, and then other 
Wikipedias followed. Again, no problem with the developers whatsoever.


Now compare this with VE, AFT, Mediaviewer, and Flow will be probably 
the next disaster of a comprable scale - despite the fact that WMF is 
pretty open about Flow, and there are many people answering questions 
basically in real time.


Cheers
Yaroslav


It may be that specific teams, not just legal and whatnot but also 
including within engineering itself, are better at handling this sort of 
thing than others. Have there been any patterns with how well things go 
depending on who is involved? If so, perhaps the others could learn from 
them...


-I

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Chris Keating]

On 14 Aug 2014 14:50, "David Cuenca"  wrote:
>
> On Thu, Aug 14, 2014 at 3:35 PM, David Gerard  wrote:
>
> > A pattern we see over and over is that the developers talk at length
> > about what they're working on in several venues, then it's released
> > and people claiming to speak for the community claim they were not
> > adequately consulted. Pretty much no matter what steps were taken to
> > do so, and what new steps are taken to do so. Because there's always
> > someone who claims their own lack of interest is someone else's fault.
> >
>
> Talking in several venues about what one is doing cannot be considered
> consensus building. Actually it is the opposite, because it is an
extrinsic
> change and as such it cannot be appropriated by any ad-hoc community. Even
> worse, it gives developers the wrong impression that they are working
under
> general approval, when actually they might be communicating only with the
> people that normally would accept their project, but not the ones that
> normally would reject it.

how should this be solved?

To me it's saying that no matter who is informed, the WMF can never expect
that their work won't be overruled.

That is problematic (regardless of who has the final authority)


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

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Gerard]

On 14 August 2014 20:27, Marc A. Pelletier  wrote:
> On 08/14/2014 02:36 PM, David Gerard wrote:

>> So locally-editable site JavaScript, for locally-important gadgets and
>> so forth, is in fact something that's needed.

> That seems reasonable, but it's less clear to me that this should be
> bundled with / part of the 'editinterface' right, at least as it is
> currently managed (the ability to be able to change wording of system
> message is only related to being able to change javascript/CSS by way of
> hysterical raisins).
> Regardless of which process, in the end, is adopted to make management
> of sitewide customization to javascript etc, separating that from
> "normal" editinterface seems to me to be prerequisite.


This is true, but prerequisite to what? What I'm saying is that
switching off local scripting in general until [unspecified condition]
is met is going to be an immediately bad thing for every WMF wiki that
doesn't get lots of WMF attention, which is most of them. So that's a
thing that shouldn't be done just because admins on two wikis are
acting like my daughter just before I withdraw her computer access.


- d.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Marc A. Pelletier]

On 08/14/2014 02:36 PM, David Gerard wrote:
> So locally-editable site JavaScript, for locally-important gadgets and
> so forth, is in fact something that's needed.

That seems reasonable, but it's less clear to me that this should be
bundled with / part of the 'editinterface' right, at least as it is
currently managed (the ability to be able to change wording of system
message is only related to being able to change javascript/CSS by way of
hysterical raisins).

Regardless of which process, in the end, is adopted to make management
of sitewide customization to javascript etc, separating that from
"normal" editinterface seems to me to be prerequisite.

-- Marc


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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Gerard]

On 14 August 2014 16:27, Richard Farmbrough  wrote:

> 3.  The ongoing question of software development.  The WMF is supposed to "to
> empower and engage" the communities to  disseminate content "effectively
> and globally."  It is not supposed to run with its own agenda.  Bugs and
> feature requests by the community are allowed to stand unattended for years
> - one was closed (WONTFIX) because of an off-hand comment made by a dev on
> a mailing list!  Meanwhile "nice to have" features absorb apparently huge
> amounts of financial and staff resoruces. In the style re-work, extensive
> feedback was solicited and provided - and ignored when it didin't suit.
> (Notably a/b testing, mixing serif and sans, and using typefaces where the
> glyphs are more distinct)


Although I concur with Erik's and WMF's actions in this particular
case (and I really don't see how it could have worked out any other
way), it's worth noting for the general case that local communities
*do* need to be able to add local enhancements to MediaWiki - because
the developers, WMF and volunteer, simply don't scale. This has been
observable even for simple administrative actions that happen to
require shell use, let alone adding new functionality.

So locally-editable site JavaScript, for locally-important gadgets and
so forth, is in fact something that's needed. This particularly
applies to non-Wikipedia wikis that get no paid developer attention
from WMF.

Of course, in an ideal world this would be later reviewed and possibly
centralised. But blocking it in general will immediately make
Wikimedia sites worse, not better, in important ways.


- d.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Yaroslav M. Blanter]

On 14.08.2014 15:35, David Gerard wrote:

On 14 August 2014 13:56, David Cuenca  wrote:


It would be more sensible to let contributors participate in the tech
roadmap in more formal and empowered way than now, because without 
that

early participation there is no possibility for later consensus.



A pattern we see over and over is that the developers talk at length
about what they're working on in several venues, then it's released
and people claiming to speak for the community claim they were not
adequately consulted. Pretty much no matter what steps were taken to
do so, and what new steps are taken to do so. Because there's always
someone who claims their own lack of interest is someone else's fault.


- d.



This is actually not correct. Take pending changes on the English 
Wikipedia as an example - people used to complain a lot on how RfC's 
were closed, but this is the business of the community. I have never 
heard anybody complaining that the trial sucked, or that PC itself does 
not work properly. There was a discussion, there was a trial, everything 
was properly announced, and everything from the developers's side was 
done perfectly or close to perfectly.


Take Phase I Wikidata - this is smth I was actively participating in 
and watched it from the close distance. Everything went smoothly, with 
the Hungarian Wikipedia trial starting first, the Italian Wikipedia a 
bit later, when feedback was taken into account, and then other 
Wikipedias followed. Again, no problem with the developers whatsoever.


Now compare this with VE, AFT, Mediaviewer, and Flow will be probably 
the next disaster of a comprable scale - despite the fact that WMF is 
pretty open about Flow, and there are many people answering questions 
basically in real time.


Cheers
Yaroslav

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Richard Farmbrough]

Erik said:

>We are very open to continuing the discussion about how the feature
>should be configured, how it should be improved, and how it should be
>integrated in the site experience

The message that is being given, though is, to quote Mathilda "I'm smart;
you're dumb; I'm big, you're little; *I'm right, you're wrong*, and there's
nothing you can do about it."

And this continues in this post.  Assuming for example that those who do
not opt-out "support" the media viewer.

Let me just make my position on the media viewer clear, since I am being
uncharacteristically vocal on this subject.  I am undecided, but I think it
is probably a good thing.  However when I hear respected communities saying
there are functional and legal problems, I am inclined to believe them.  I
support therefore the "not-yet" faction.  Personally I find it irritating
(and at the same time potentially very cool), but I keep it on because I
want to see what the bulk of our readers see.

So there are interconnecting layers of issues here - and I think they are
clear, but I will lay them out in case we are talking at cross purposes.

1. Erik's actions.  This sort of thing happens a lot on on-line communities
(and elsewhere - see the Crimea!)  and I did not get too excited about the
socially inept blundering on en:WP.  But to repeat the same script on
German Wikipedia within a few days shows a lack of wisdom unbecoming to
"Deputy Director".

2. The specific question of Media Viewer.  That I believe can be resolved,
and is all about "not yet", it should never have been allowed to cause
drama. I would like to see some metrics for the value delivered by the
Media Viewer, though, rather than "Flikr does it, it must be good".  I am
disappointed after a mostly unusable Visual Editor was released with
content breaking bugs that another project is being forced down the same
path - Erik's comment "That's no way to develop software" rings rather
hollow in this context.

3.  The ongoing question of software development.  The WMF is supposed to "to
empower and engage" the communities to  disseminate content "effectively
and globally."  It is not supposed to run with its own agenda.  Bugs and
feature requests by the community are allowed to stand unattended for years
- one was closed (WONTFIX) because of an off-hand comment made by a dev on
a mailing list!  Meanwhile "nice to have" features absorb apparently huge
amounts of financial and staff resoruces. In the style re-work, extensive
feedback was solicited and provided - and ignored when it didin't suit.
(Notably a/b testing, mixing serif and sans, and using typefaces where the
glyphs are more distinct)

4. The culture at the Foundation needs to be more focussed on collaborative
and collegial work with the communities. The Foundation  is an essential
part of the Movement, if it did not exist it would be necessary to invent
it.  However it is not the senior partner, certainly not in terms of age or
resource, and, due to the open licensing, not in content.  To work
effectively with the community the Foundation needs to consider the
community as its customer, be responsive to its needs and wants, in this
way it can deliver on its charitable objectives.

Note: This does not mean a namby-pamby relationship, but rather a robust
one, where evidence based decisions can be made jointly and collegialy.
Indeed one value add from having an organisation like the WMF is the
resource to gather significant evidence on usability, readability,
accessibility, clarity, interrogability and so forth.


On 14 August 2014 14:35, David Gerard  wrote:

> On 14 August 2014 13:56, David Cuenca  wrote:
>
> > It would be more sensible to let contributors participate in the tech
> > roadmap in more formal and empowered way than now, because without that
> > early participation there is no possibility for later consensus.
>
>
> A pattern we see over and over is that the developers talk at length
> about what they're working on in several venues, then it's released
> and people claiming to speak for the community claim they were not
> adequately consulted. Pretty much no matter what steps were taken to
> do so, and what new steps are taken to do so. Because there's always
> someone who claims their own lack of interest is someone else's fault.
>
>
> - d.
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Cuenca]

On Thu, Aug 14, 2014 at 3:35 PM, David Gerard  wrote:

> A pattern we see over and over is that the developers talk at length
> about what they're working on in several venues, then it's released
> and people claiming to speak for the community claim they were not
> adequately consulted. Pretty much no matter what steps were taken to
> do so, and what new steps are taken to do so. Because there's always
> someone who claims their own lack of interest is someone else's fault.
>

Talking in several venues about what one is doing cannot be considered
consensus building. Actually it is the opposite, because it is an extrinsic
change and as such it cannot be appropriated by any ad-hoc community. Even
worse, it gives developers the wrong impression that they are working under
general approval, when actually they might be communicating only with the
people that normally would accept their project, but not the ones that
normally would reject it.

It is of course impossible to involve everyone, but the more voices are
included the better represented will be the interests of the ones that are
not present.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Todd Allen]

On Aug 14, 2014 3:58 AM, "Erik Moeller"  wrote:
>
> On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride  wrote:
> > Is there anything that the German Wikipedia could do to convince you to
> > disable MediaViewer there? Some percentage of active users showing up to
> > say so? Some percentage of users (logged-in or otherwise) disabling the
> > feature? (Presumably we can get stats of some kind.)
>
> We are very open to continuing the discussion about how the feature
> should be configured, how it should be improved, and how it should be
> integrated in the site experience. Ideally we'd like to minimize
> inconsistencies between wikis (because for readers who speak more than
> one language, it's just a single site), so changes that help alleviate
> conflict or disagreement should ideally also be of the kind that in
> general are welcomed and wanted.
>

Provided they're what you would have done anyway. Otherwise, they're
"welcomed" with WONTFIX and superprotection.

> On the subject of opt-out numbers, you can see them here:
>
http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-graphs-tab
>
> As you can see, the recent drama has contributed to a significant
> increase in opt-out events. Pre-vote, about 17% of very active (>100
> edit/month) users had disabled MMV. This is about the same number of
> people who ultimately voted no, BTW, about 200. Post-vote it was 20%.
> Since then it has climbed to 23%. In contrast, about 30% of that same
> user group still use Monobook.
>

I'm glad you know why people choose to opt out. I don't see that in the
data you cited, how was that data gathered?

> I think those numbers can and should reasonably inform the default for
> logged in users, for sure. I don't think they should be used to
> determine the default for readers.
>

What should inform the default for "readers" are the communities who care
enough about those readers to volunteer millions of hours per month
generating, curating, and protecting the world's largest ever educational
work for the benefit of those very same readers. Yet WMF dismisses and
belittles those volunteers as "power users" who couldn't care less, but
hey, WE know best, now get out of our way or else!

Then, of all things, the next question is "Gee, why can't we retain good
editors and attract new ones?"

> In general, though, let's talk. The overarching principle we're not
> going to budge on is that this process is really not acceptable:
>
> 1) The UI changes
> 2) A subset of users is upset and organizes a poll/vote
> 3) The poll/vote closes with a request to undo said UI Change and a
> request is filed
> 4) WMF offers compromise or says no
> 5) A local hack is used to undo said UI change
>

Nor is this:

1) The UI changes
2) A given project rejects or requests modification to the change
3) WMF crams it right down their throat regardless.
4) Local admins do what they can to implement the consensus, as they are
selected by the community to do.
5) WMF throws a fit and threatens those admins or gives itself "super"
authority.

In your scenario, it's unacceptable that we ever reach step 5. The
community, not the WMF, must be the final authority on each project.

> That's no way to develop software, and that's no way to work together.
> If you want a WMF that slavishly implements RFCs or votes to disable
> features upon request, you'll need to petition to replace more than
> just one person. In fact, you should petition to reduce the staff
> dramatically, find an administrative ED who has no opinion on what to
> do, and exclusively focus on platform-level improvements and requests
> that clearly have community backing.
>

If there were a mechanism for a vote of no confidence, I think you'd see
exactly that take place right now. But yes, if the current WMF will not
back down from this position, we need a better one, and one with far less
power to provide a temptation for abuse. That is not a desirable outcome,
but it seems a necessary one more each day.

Except in cases where legal issues are at play, WMF must not overrule local
communities.

> This is not the org we want to be.

That's unfortunate. We have always operated as a community centered and
consensus driven project, and that has worked not only well but stunningly
well.

I am hopeful and optimistic that
> there are enough admins and regular editors who believe in a vision of
> improving the user experience iteratively, and working together
> through conflict, that we can in future entirely rely on local admins
> to prevent the kind of JS hacks we've seen here, working towards a
> proper code review and deployment mechanism that further alleviates
> the risk of escalations. Mind you, we made it very clear in this case
> ahead of time that JS hacks were unacceptable, we attempted a revert
> and a very explicit warning.
>

And we made it clear ignoring the results was unacceptable. If you want to
stop escalations, don't handwave away the people who day to day run the
projects. T

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Gerard]

On 14 August 2014 13:56, David Cuenca  wrote:

> It would be more sensible to let contributors participate in the tech
> roadmap in more formal and empowered way than now, because without that
> early participation there is no possibility for later consensus.


A pattern we see over and over is that the developers talk at length
about what they're working on in several venues, then it's released
and people claiming to speak for the community claim they were not
adequately consulted. Pretty much no matter what steps were taken to
do so, and what new steps are taken to do so. Because there's always
someone who claims their own lack of interest is someone else's fault.


- d.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Cuenca]

Erik,

I'm impartial about the mediaviewer, but I have the feeling that this is a
recurring a pattern:
1) contributors ask for some change to improve their experience or the
reader's experience
2) their request is ignored because either it doesn't fit in the big
picture, or there is no mechanism for them to voice a request other than to
fill a bugzilla or start a rfc that will be gathering dust till the end of
the days
3) the changes are implemented anyhow in a hackish way, or not implemented
at all
4) technical debt builds up until there is the need to find a stable
solution
5) the wmf steps in with a good technical solution, or comes up with some
unrequested neat feature, but without gathering grassroots support
6) some editors are presented the tool, nobody complains because it is a
feature still in development
7) the feature is rolled out hoping it will be accepted -> if it is not ->
conflict

It would be more sensible to let contributors participate in the tech
roadmap in more formal and empowered way than now, because without that
early participation there is no possibility for later consensus. After the
experience with the Wikisource Community User Group, I can say that with
some effort promoting dialogue at international level, it is possible for
the community to come up with a set of priorities and that builds up
legitimacy. However that is all for nothing if that consensus has no impact
in the development plan.

Besides there seems to be a communication barrier between the contributors
and the wmf that shouldn't be there, and I don't think the best way to
remove it is to add more privileges or constraints, because that makes the
barrier higher, not lower.

TBH, I hope that the compromise options that you are drafting stop this
drama, but it is also important to learn from how it came to be, so it
doesn't repeat again.

Cheers,
Micru



On Thu, Aug 14, 2014 at 11:57 AM, Erik Moeller  wrote:

> On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride  wrote:
> > Is there anything that the German Wikipedia could do to convince you to
> > disable MediaViewer there? Some percentage of active users showing up to
> > say so? Some percentage of users (logged-in or otherwise) disabling the
> > feature? (Presumably we can get stats of some kind.)
>
> We are very open to continuing the discussion about how the feature
> should be configured, how it should be improved, and how it should be
> integrated in the site experience. Ideally we'd like to minimize
> inconsistencies between wikis (because for readers who speak more than
> one language, it's just a single site), so changes that help alleviate
> conflict or disagreement should ideally also be of the kind that in
> general are welcomed and wanted.
>
> On the subject of opt-out numbers, you can see them here:
>
> http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-graphs-tab
>
> As you can see, the recent drama has contributed to a significant
> increase in opt-out events. Pre-vote, about 17% of very active (>100
> edit/month) users had disabled MMV. This is about the same number of
> people who ultimately voted no, BTW, about 200. Post-vote it was 20%.
> Since then it has climbed to 23%. In contrast, about 30% of that same
> user group still use Monobook.
>
> I think those numbers can and should reasonably inform the default for
> logged in users, for sure. I don't think they should be used to
> determine the default for readers.
>
> In general, though, let's talk. The overarching principle we're not
> going to budge on is that this process is really not acceptable:
>
> 1) The UI changes
> 2) A subset of users is upset and organizes a poll/vote
> 3) The poll/vote closes with a request to undo said UI Change and a
> request is filed
> 4) WMF offers compromise or says no
> 5) A local hack is used to undo said UI change
>
> That's no way to develop software, and that's no way to work together.
> If you want a WMF that slavishly implements RFCs or votes to disable
> features upon request, you'll need to petition to replace more than
> just one person. In fact, you should petition to reduce the staff
> dramatically, find an administrative ED who has no opinion on what to
> do, and exclusively focus on platform-level improvements and requests
> that clearly have community backing.
>
> This is not the org we want to be. I am hopeful and optimistic that
> there are enough admins and regular editors who believe in a vision of
> improving the user experience iteratively, and working together
> through conflict, that we can in future entirely rely on local admins
> to prevent the kind of JS hacks we've seen here, working towards a
> proper code review and deployment mechanism that further alleviates
> the risk of escalations. Mind you, we made it very clear in this case
> ahead of time that JS hacks were unacceptable, we attempted a revert
> and a very explicit warning.
>
> None of us love drama. We've been punting on this issue for a long
> time, living w

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Erik Moeller]

On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride  wrote:
> Is there anything that the German Wikipedia could do to convince you to
> disable MediaViewer there? Some percentage of active users showing up to
> say so? Some percentage of users (logged-in or otherwise) disabling the
> feature? (Presumably we can get stats of some kind.)

We are very open to continuing the discussion about how the feature
should be configured, how it should be improved, and how it should be
integrated in the site experience. Ideally we'd like to minimize
inconsistencies between wikis (because for readers who speak more than
one language, it's just a single site), so changes that help alleviate
conflict or disagreement should ideally also be of the kind that in
general are welcomed and wanted.

On the subject of opt-out numbers, you can see them here:
http://multimedia-metrics.wmflabs.org/dashboards/mmv_dewiki#opt_in_opt_out-graphs-tab

As you can see, the recent drama has contributed to a significant
increase in opt-out events. Pre-vote, about 17% of very active (>100
edit/month) users had disabled MMV. This is about the same number of
people who ultimately voted no, BTW, about 200. Post-vote it was 20%.
Since then it has climbed to 23%. In contrast, about 30% of that same
user group still use Monobook.

I think those numbers can and should reasonably inform the default for
logged in users, for sure. I don't think they should be used to
determine the default for readers.

In general, though, let's talk. The overarching principle we're not
going to budge on is that this process is really not acceptable:

1) The UI changes
2) A subset of users is upset and organizes a poll/vote
3) The poll/vote closes with a request to undo said UI Change and a
request is filed
4) WMF offers compromise or says no
5) A local hack is used to undo said UI change

That's no way to develop software, and that's no way to work together.
If you want a WMF that slavishly implements RFCs or votes to disable
features upon request, you'll need to petition to replace more than
just one person. In fact, you should petition to reduce the staff
dramatically, find an administrative ED who has no opinion on what to
do, and exclusively focus on platform-level improvements and requests
that clearly have community backing.

This is not the org we want to be. I am hopeful and optimistic that
there are enough admins and regular editors who believe in a vision of
improving the user experience iteratively, and working together
through conflict, that we can in future entirely rely on local admins
to prevent the kind of JS hacks we've seen here, working towards a
proper code review and deployment mechanism that further alleviates
the risk of escalations. Mind you, we made it very clear in this case
ahead of time that JS hacks were unacceptable, we attempted a revert
and a very explicit warning.

None of us love drama. We've been punting on this issue for a long
time, living with ambiguity that we knew was going to bite us sooner
or later. When DaB. removed the link to Beta Features on de.wp in
November, calling it "clutter", we ignored it and hoped that another
sensible admin would step in and restore it, because we didn't want to
trigger precisely this kind of conflict over minutiae. (It was only
restored a couple of days ago.) In other cases we've made simple
reverts to MediaWiki: edits and hoped they would stick. Can you
imagine how frustrating this is for developers and UX designers who
are paid using donor funds to improve the user experience?

We need rules of engagement for these types of changes, and they need
to acknowlege that WMF is a partner in them. The problem with the
sequence above is that there's no venue for negotiating compromises,
evaluating options, and establishing final agreements about what
should happen. That puts WMF in a position where we get to say "yes",
"WONTFIX" or "here's a random compromise, hope you like it". We need
better ways to discuss and negotiate when we disagree.

Please give us some time to outline some compromise options consistent
with the above. However, please don't expect us to endorse the idea of
"If WMF doesn't do what we want, we'll just enforce it by means of a
local hack". That is simply not workable, and no Wikimedia Foundation
that at all resembles the one we have today will accept it.

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Pine W]

FYI, Lila had chosen to engage in discussion on her meta talk page.
Numerous editors are commenting there. Discussion also continues on the
meta RFC and on the English Wikipedia arbitration workshop page.

Pine
On Aug 14, 2014 12:03 AM, "Russavia"  wrote:

Erik

On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller  wrote:

>
> This is why on all major sites, you see a gradual ramp-up of a new
> feature, and continued improvement once it's widely used. Often
> there's an opt-in and then an opt-out to ease users into the change.
> But once a change is launched, it very rarely gets rolled back unless
> it's just clearly not doing what it's supposed to.


Are you are familiar with the Flickr experience in the last 12 months by
any chance? I think that is a very pertinent and prominent example of what
goes against what you say. The Flickr attitude was much the same as the
WMF's. That ended up in a revolt, much like the WMF is seeing against it.
In the end, they ended up doing what Erik?

Also, the other day I received a Flickr email from someone wishing to use
an image which I had not taken, but which I had uploaded to Commons. They
mentioned that they saw the photo on Commons.

When I told them that I am not the author, and that they would need to
contact Joe Bloggs, their response: "I'm sorry, this is SO confusing to me."

I put that down to MediaViewer and its adding irrelevant information, and
also the fact that file information is more difficult to find.

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

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Russavia]

Erik

On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller  wrote:

>
> This is why on all major sites, you see a gradual ramp-up of a new
> feature, and continued improvement once it's widely used. Often
> there's an opt-in and then an opt-out to ease users into the change.
> But once a change is launched, it very rarely gets rolled back unless
> it's just clearly not doing what it's supposed to.


Are you are familiar with the Flickr experience in the last 12 months by
any chance? I think that is a very pertinent and prominent example of what
goes against what you say. The Flickr attitude was much the same as the
WMF's. That ended up in a revolt, much like the WMF is seeing against it.
In the end, they ended up doing what Erik?

Also, the other day I received a Flickr email from someone wishing to use
an image which I had not taken, but which I had uploaded to Commons. They
mentioned that they saw the photo on Commons.

When I told them that I am not the author, and that they would need to
contact Joe Bloggs, their response: "I'm sorry, this is SO confusing to me."

I put that down to MediaViewer and its adding irrelevant information, and
also the fact that file information is more difficult to find.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[MZMcBride]

Erik Moeller wrote:
>This is why on all major sites, you see a gradual ramp-up of a new
>feature, and continued improvement once it's widely used. Often
>there's an opt-in and then an opt-out to ease users into the change.
>But once a change is launched, it very rarely gets rolled back unless
>it's just clearly not doing what it's supposed to. Yes, we can all
>agree that we need to continually raise the bar for how we build
>software (without getting into analysis paralysis) -- but that doesn't
>mean that reverting (here or in other cases) once there's an ad hoc
>vote (or two, or three) is the right thing to do.
>
>No other significantly sized organization follows the development
>methodology you're proposing WMF should follow. Certainly, WMF is an
>unusual organization, and we have every desire to take concerns
>seriously, engage with people, scrutinize data honestly, and work
>iteratively to make things better for everyone. What we can't and
>won't accept is the idea that admin-reverts of features are an OK way
>to try to enforce the outcome of an ad hoc poll or vote.

Is there anything that the German Wikipedia could do to convince you to
disable MediaViewer there? Some percentage of active users showing up to
say so? Some percentage of users (logged-in or otherwise) disabling the
feature? (Presumably we can get stats of some kind.) I'm curious what it
would take for you to change course here.

We should note that your behavior on the German Wikipedia has resulted in
you being blocked there for a month. I get the sense that many people on
the German Wikipedia feel as though there's no way you'll ever be
convinced to disable MediaViewer. And from the comments I've been reading,
this incident, along with others, has done significant damage to both your
reputation and the reputation of the Wikimedia Foundation.

>We can - and should, and do - talk to figure things out. We can - and
>should, and do - work out compromises. (And we did indeed agree to
>implement a compromise solution for Commons.) But the idea that WMF
>always must slavishly execute the result of a poll or vote is neither
>rational nor sustainable, nor has it ever been practice --- much less
>controversially so in situations where WMF's decisions cannot be
>overriden by admins employing JavaScript hacks.

You've not established an overriding interest here. If this issue related
to online harassment or child protection or biographies of living people
or the ability of users to edit or copyright or something else that
matters, it might make sense for you to step in.

But we're discussing an entirely supplementary feature. A few wikis (three
by my count) have tried MediaViewer and have decided that they'd rather
not have it be opt-out on their wiki. Instead they'd prefer that
MediaViewer be opt-in for now. These communities have politely requested
a configuration change, which should be within the purview of Wikimedia
stewards, but MediaWiki doesn't yet have a graphical configuration user
interface. Why deny these seemingly reasonable requests?

MZMcBride



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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Thu, 14 Aug 2014, at 00:50, Pete Forsyth wrote:
> On Wed, Aug 13, 2014 at 3:27 AM, svetlana  wrote:
> > [...]
> > Surely this issue can be solved by talking without force: if you don't
> > think so, you get force applied to YOU; you started a fight, and lost it.
> 
> 
> I have advocated using force? Where?! Please don't answer -- I am done with
> this thread, it has no basis in reality.

I am being generic. The "you" refers to whoever made the edit which was 
reverted by WMF and super-protected.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Pete Forsyth]

On Wed, Aug 13, 2014 at 2:32 PM, Erik Moeller  wrote:

> But the idea that WMF
> always must slavishly execute the result of a poll or vote is neither
> rational nor sustainable,
>

While there may be some who suggest that WMF should do so, I am not one of
them -- and nor are many of my colleagues.

The RfCs are merely one data point. I would like to remind you (though I am
getting tired of repeating my arguments, while you reflect back to me
arguments that are substantially weaker than my own, and attack straw men)
that mere "reader preference" is a ridiculous measurement to regard as
final and binding, for a project that exists to fulfill a mission, and that
developed a clear strategic plan to fulfill that mission. Where in the
strategic plan does it say that "if we feel that the readers are trending
toward accepting something, then it is good?" What if their ultimate
acceptance of that makes them LESS likely to participate in the community,
and MORE likely to merely consume information -- to have ACCESS to
information, rather than to SHARE in our vision?

I do not ask these questions because I want them answered now; I suggest
that they should have been asked and explored long ago. For instance, when
I brought them up in February.[1]

They're still worthwhile to explore carefully now, but as long as the
software remains enabled by default, in defiance of the thoughtful opinions
of a majority of Wikipedians who have weighed in on 3 projects, I predict
that it will be difficult to do so.

-Pete

[1] https://www.mediawiki.org/w/index.php?diff=907392
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Erik Moeller]

On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth  wrote:
> In favor of the Media Viewer software is a bunch of inquiry and analysis
> Restoring the default state of the software to the state that worked for
> the last decade is a clear precondition for healthier discussion of a
> positive path forward.

Dear Pete,

You speak as if there is no cost to disabling and re-enabling an
interface. That is not the case.

As you say, millions of readers use the site. And just like editors,
introducing a new, very different viewing experience - like MV - takes
some time to adjust to. We saw this in survey responses improving over
time where they were initially negative, and we also saw it in some
comments of the type "I am getting used to it now and I like it". (We
also got plenty of "I love this, this is great" type comments.) To the
extent that there are discoverability issues in the current UI, they
are just that: discoverability issues. That doesn't mean if the same
user keeps using the same inteface, they will never click a button -
it means it's harder to figure out than it needs to be.

Some of this was already fixed in production. For example, adding a
label to the "Use this file" button more than doubled its usage. This
is how this stuff works: You instrument, you change, you learn. Other
changes are underway. Turning off the UI completely means readers who
have gotten used to it or who have always enjoyed it will have to
re-learn the old UI, then re-learn the new UI when some (undetermined)
set of conditions are met. That's jarring, confusing, and avoidable.

This is why on all major sites, you see a gradual ramp-up of a new
feature, and continued improvement once it's widely used. Often
there's an opt-in and then an opt-out to ease users into the change.
But once a change is launched, it very rarely gets rolled back unless
it's just clearly not doing what it's supposed to. Yes, we can all
agree that we need to continually raise the bar for how we build
software (without getting into analysis paralysis) -- but that doesn't
mean that reverting (here or in other cases) once there's an ad hoc
vote (or two, or three) is the right thing to do.

No other significantly sized organization follows the development
methodology you're proposing WMF should follow. Certainly, WMF is an
unusual organization, and we have every desire to take concerns
seriously, engage with people, scrutinize data honestly, and work
iteratively to make things better for everyone. What we can't and
won't accept is the idea that admin-reverts of features are an OK way
to try to enforce the outcome of an ad hoc poll or vote.

We can - and should, and do - talk to figure things out. We can - and
should, and do - work out compromises. (And we did indeed agree to
implement a compromise solution for Commons.) But the idea that WMF
always must slavishly execute the result of a poll or vote is neither
rational nor sustainable, nor has it ever been practice --- much less
controversially so in situations where WMF's decisions cannot be
overriden by admins employing JavaScript hacks.

If we're being honest, at the end of the day, a lot of this is about
establishing clear governing principles for the MediaWiki: namespace.
The fact that WMF doesn't implement every vote and indeed has in the
past even been somewhat capricious at times when it did not
(especially when such decisions were made just by a single dev
applying their own best judgment) is not in question. From a
communications perspective, we handled WP:ACTRIAL much more poorly
than we did this (we responded way too late), for example. But you
can't implement WP:ACTRIAL in JavaScript.

But there is no governing principle - documented clearly - that says
you can't disable a feature using the MW: namespace. WMF is saying it
now, and people perceive that (understandably) as a power grab. Fair
enough - it is the explicit extension of existing authority into a
novel domain. Such a change is always contentious and controversial,
but I don't think it was avoidable. If we are to work together
effectively, we need to define areas of competency and responsibility
clearly.

Erik
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Ziko van Dijk]

A Dutch politician once said in a presentation: 'Sometimes citizens
come to us and say: You don't listen. Then I answer: Well, we do
listen, but we also listen to the millions of inhabitants who have
other opinions.'

Kind regards
Ziko


2014-08-13 22:47 GMT+02:00 Michael Peel :
>
> On 13 Aug 2014, at 21:12, Pete Forsyth  wrote:
>
>> On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier 
>> wrote:
>>
>>> There is no such thing as "the community"; we have a huge collection of
>>> communities joined loosely over a number of ambigously shared principles
>>> that often - but not always - move in more or less the same direction.
>>>
>>> Anyone who claims to speak for "the community" is - put simply - full of
>>> shit.
>>>
>>
>> So very true! All of the arguments that claim knowledge of what "the
>> community" wants, or what "the readers" want, need to be regarded with a
>> strong dose of skepticism, or put aside entirely.
>
> {{citation needed}}
>
> There are some community members who spend a lot of time thinking about what 
> "the community" and "the readers" may want, who actually have a good 
> understanding of what is needed to support those stakeholders. There are 
> others that say that their views represent the community/readers when they 
> don't. A distinction needs to be made there - don't confuse the former with 
> the latter.
>
> Additionally: there is no guarantee that what has worked well in the past 
> will continue to work well in the future. The internet is always changing and 
> improving, and a lot of organisations that dominated a decade ago now only 
> exist in historical record. Wikimedia really needs to match the current state 
> of the art, otherwise it will likely also cease to exist. I'd like to see the 
> Wikimedia community leading the way with the internet's development, but 
> right now it feels like it's lagging by about a decade, and the WMF is having 
> to play a leading role to keep it relevant. If the Wikimedia community can 
> catch up with the current state of the internet, that would be great, but if 
> it can't then supporting the WMF while it does so would make a lot of sense.
>
> Thanks,
> Mike
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> 

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Michael Peel]

On 13 Aug 2014, at 21:12, Pete Forsyth  wrote:

> On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier 
> wrote:
> 
>> There is no such thing as "the community"; we have a huge collection of
>> communities joined loosely over a number of ambigously shared principles
>> that often - but not always - move in more or less the same direction.
>> 
>> Anyone who claims to speak for "the community" is - put simply - full of
>> shit.
>> 
> 
> So very true! All of the arguments that claim knowledge of what "the
> community" wants, or what "the readers" want, need to be regarded with a
> strong dose of skepticism, or put aside entirely.

{{citation needed}}

There are some community members who spend a lot of time thinking about what 
"the community" and "the readers" may want, who actually have a good 
understanding of what is needed to support those stakeholders. There are others 
that say that their views represent the community/readers when they don't. A 
distinction needs to be made there - don't confuse the former with the latter.

Additionally: there is no guarantee that what has worked well in the past will 
continue to work well in the future. The internet is always changing and 
improving, and a lot of organisations that dominated a decade ago now only 
exist in historical record. Wikimedia really needs to match the current state 
of the art, otherwise it will likely also cease to exist. I'd like to see the 
Wikimedia community leading the way with the internet's development, but right 
now it feels like it's lagging by about a decade, and the WMF is having to play 
a leading role to keep it relevant. If the Wikimedia community can catch up 
with the current state of the internet, that would be great, but if it can't 
then supporting the WMF while it does so would make a lot of sense.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Trillium Corsage]

13.08.2014, 01:46, "svetlana" :

>
> if the community was not so willing to use force (ie a js hack) against the 
> other party
>
> instead of talking properly
>
> then the superprotect wouldn't exist at all
>
> you seeing the problem there? whose problem is it?
> desire to act out of the blue instead of collaborating
> they didn't collaborate at all
> they added the js hack as if it was something urgent, that needs saving 
> people from
>
> i would only do this if someone added a virus into mv by mistake
>
> this community thinks that its power structures allow to tromp onto other 
> people

I agree with your thinking here Svetlana, but would disagree with your 
terminology that the vocal complainers about superprotect should be shorthanded 
as "the community." That is what they like to think of themselves, but they are 
really a minority of the community. They are the administrative culture. They 
are not really the editors, not really the readers, both of those groups dwarf 
the administrators and administrative participants. 

The community is all the readers, all the editors, and after them in size the 
vocal and visible administrative set. So Mr. Moeller shouldn't feel 
intimidated, and clearly doesn't, when a bunch of very loud people writes 
volumes of complaining text on discussion pages insisting that he has affronted 
"the community."

Trillium Corsage

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Pete Forsyth]

On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier 
wrote:

> There is no such thing as "the community"; we have a huge collection of
> communities joined loosely over a number of ambigously shared principles
> that often - but not always - move in more or less the same direction.
>
> Anyone who claims to speak for "the community" is - put simply - full of
> shit.
>

So very true! All of the arguments that claim knowledge of what "the
community" wants, or what "the readers" want, need to be regarded with a
strong dose of skepticism, or put aside entirely.

What we are left with is a question: which version is *acceptable*, as an
interim measure, while a more careful decision -- involving things like
research and better executed community consultation -- is made?

In favor of the standard MediaWiki image interface is this: it has been
part of a collection of features that, over a 13 year period, has led to
Wikimedia sites becoming a top 5 web property, and is familiar to all the
millions of people who have interacted with it (in that capacity, and on
other MediaWiki-based sites) in that 13 year period. That is not to say
it's "perfect" or anything close to it, but we do know that it is "good
enough."

In favor of the Media Viewer software is a bunch of inquiry and analysis
done by the WMF's Multimedia Team. The methodology has been widely
criticized, and the results point in various directions. (For example, as I
pointed out here
,
none of the 3 readers consulted by WMF in a User Experience study, although
they were all technically proficient Internet users, were able to find the
"Details" page on Commons using the MV software.)

Restoring the default state of the software to the state that worked for
the last decade is a clear precondition for healthier discussion of a
positive path forward. This is not me drawing a line in the sand, but me
observing what has become readily apparent. I am pretty sure this condition
is outside of anybody's influence at this point -- it is simply the natural
result of a poorly planned and executed product launch.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Marc A. Pelletier]

On 08/13/2014 01:31 PM, Trillium Corsage wrote:
> [...] that he has affronted "the community."

I've spent no small amount of years involved in the various layers of
administrative/governance/meta aspects of the English Wikipedia and from
this I learned one lesson:

"Whenever someone says 'the community' without qualifying this to an
enumerable set of users means the assertion is definitely false."

There is no such thing as "the community"; we have a huge collection of
communities joined loosely over a number of ambigously shared principles
that often - but not always - move in more or less the same direction.

Anyone who claims to speak for "the community" is - put simply - full of
shit.

-- Marc


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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Pete Forsyth]

On Wed, Aug 13, 2014 at 3:27 AM, svetlana  wrote:

> On Wed, 13 Aug 2014, at 10:53, Pete Forsyth wrote:
> > On Tue, Aug 12, 2014 at 5:46 PM, svetlana 
> wrote:
> >
> > > On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
> > > > That the community reacts the way it does now, is because they care
> very
> > > > much about the site and they notice something is terrible going
> wrong on
> > > > WMF side and too less is done to fix those problems/issues!
> > >
> > > if the community was not so willing to use force (ie a js hack) against
> > > the other party
> >
> >
> > [...]
> >
> > You talk about admin accountability, Svetlana -- but what about
> > accountability for the WMF, when it makes sweeping changes that (among
> > other things) remove any suggestion of an "edit" functionality from "the
> > encyclopedia anyone can edit" from millions and millions of pages?
> >
> > Pete
> > [[User:Peteforsyth]]
>
> Surely this issue can be solved by talking without force: if you don't
> think so, you get force applied to YOU; you started a fight, and lost it.


I have advocated using force? Where?! Please don't answer -- I am done with
this thread, it has no basis in reality.


> Because you went and did something contradicting user preferences; WMF did
> not. You'd think it's "better" because it's "unchanged compared to what it
> was X months ago", and that justifies your thing? No, it does not.
>

I don't even know what you're talking about here. But again -- let's let it
go.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Wed, 13 Aug 2014, at 12:01, Romaine Wiki wrote:
> 2014-08-13 2:46 GMT+02:00 svetlana :
> > [..]
> [...]
> > instead of talking properly
> >
> > then the superprotect wouldn't exist at all
> >
> > you seeing the problem there? whose problem is it?
> > desire to act out of the blue instead of collaborating
> > they didn't collaborate at all
> > they added the js hack as if it was something urgent, that needs saving
> > people from
> >
> > i would only do this if someone added a virus into mv by mistake
> >
> > this community thinks that its power structures allow to tromp onto other
> > people
> >
> 
> I do not think the community thinks that way.

It doesn't think so inherently, but it lacks some useful habits.

> Members of the community can
> make mistake and staff members of WMF can make mistakes, I think that both
> that community and WMF are grown up enough to correct mistakes if they
> arise. Certainly inside the community are many critical people who watch
> these kind of things carefully and do correct those things when a mistake
> is made.
> 
> The German community did collaborate, did communicate. Having a voting is a
> desperate way of getting the attention of the big problems WMF has too
> little insight in apparently. The community does not think in power
> structures, WMF does.

Writing an RFC is a complicated process. You don't ask people whether they want 
to go backwards, for one; they almost always do, but it is not always a good 
thing.

svetlana

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Wed, 13 Aug 2014, at 10:53, Pete Forsyth wrote:
> On Tue, Aug 12, 2014 at 5:46 PM, svetlana  wrote:
> 
> > On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
> > > That the community reacts the way it does now, is because they care very
> > > much about the site and they notice something is terrible going wrong on
> > > WMF side and too less is done to fix those problems/issues!
> >
> > if the community was not so willing to use force (ie a js hack) against
> > the other party
> 
> 
> [...]
> 
> You talk about admin accountability, Svetlana -- but what about
> accountability for the WMF, when it makes sweeping changes that (among
> other things) remove any suggestion of an "edit" functionality from "the
> encyclopedia anyone can edit" from millions and millions of pages?
> 
> Pete
> [[User:Peteforsyth]]

Surely this issue can be solved by talking without force: if you don't think 
so, you get force applied to YOU; you started a fight, and lost it. Because you 
went and did something contradicting user preferences; WMF did not. You'd think 
it's "better" because it's "unchanged compared to what it was X months ago", 
and that justifies your thing? No, it does not.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Yaroslav M. Blanter]

On 13.08.2014 05:57, Pine W wrote:
Two points I have heard off list are that 1. While it may be that 
disabling
MV by default for logged-in users can be done, disabling it for those 
not
logged-in is effectively another major UI change which a study shows 
likely

will make some of them leave and not return; 2. German Wikimedians are
going inactive in protest.

Can someone confirm that both of those points are true?


Point 2 is essentially impossible to confirm. People are coming, 
leaving and sometimes coming back (when I left the Russian Wikipedia in 
2011, most of my opponents just said they are sure I was playing games 
and would be back soon). You never know why they leave, and even if they 
have left a clear message you never know how serious it is. It is quite 
unlikely that on a short term a significant share of active users will 
leave or has left - the German Wikipedia is not the Acehnese Wikipedia, 
and even if a dozen of users would leave at the same time, it can not be 
detected by the editing statistics. The long-time consequences and 
trends can of course be detected but then you would need to reach the 
active users who really have left and asked them why they left - it is 
unlikely anybody would successfully perform such study.


Cheers
Yaroslav

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Yaroslav M. Blanter]

On 13.08.2014 02:48, svetlana wrote:

On Wed, 13 Aug 2014, at 10:46, svetlana wrote:


this community thinks that its power structures allow to tromp onto 
other people


sysops aren't even held accountable
they are elected once for an infinite term
nobody reviews their contribution in position in power ever

this would surely be solved by making them elected on a 2-year term
then re-elect

svetlana



Sounds exactly like an indeffed former contributor to the Russian 
Wikipedia.


I do not think we should discuss the administrator elections on this 
list. Anyway, there are projects where administrators only get elected 
for a finite period.


Cheers
Yaroslav

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Pine W]

Two points I have heard off list are that 1. While it may be that disabling
MV by default for logged-in users can be done, disabling it for those not
logged-in is effectively another major UI change which a study shows likely
will make some of them leave and not return; 2. German Wikimedians are
going inactive in protest.

Can someone confirm that both of those points are true? If so, this puts
WMF in an even more difficult position. Perhaps the communities could be I
persuaded to leave MV enabled by default for logged-out users and WMF would
agree to release superprotection and disable MV by default for logged in
users.

I fear that already volunteers may be  leaving who will not return.

Pine

On Aug 12, 2014 6:42 AM, "Romaine Wiki"  wrote:

> 2014-08-13 2:46 GMT+02:00 svetlana :
>
> > On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
> > > That the community reacts the way it does now, is because they care
> very
> > > much about the site and they notice something is terrible going wrong
> on
> > > WMF side and too less is done to fix those problems/issues!
> >
> > if the community was not so willing to use force (ie a js hack) against
> > the other party
> >
>
> You miss a very important thing here: the community does not want to use
> such measure at all, but is forced to this by the inappropriate behaviour
> of some WMF staff. The community gets the feeling that it isn't listened
> to, while it has serious points and considerations which are stepped over
> too lightly. And as I said before, we are all on the same ship. Sure a
> captain must make decisions, but if parts have serious comments, issues,
> and critics, such should not be ignored.
>
>
> > instead of talking properly
> >
> > then the superprotect wouldn't exist at all
> >
> > you seeing the problem there? whose problem is it?
> > desire to act out of the blue instead of collaborating
> > they didn't collaborate at all
> > they added the js hack as if it was something urgent, that needs saving
> > people from
> >
> > i would only do this if someone added a virus into mv by mistake
> >
> > this community thinks that its power structures allow to tromp onto other
> > people
> >
>
> I do not think the community thinks that way. Members of the community can
> make mistake and staff members of WMF can make mistakes, I think that both
> that community and WMF are grown up enough to correct mistakes if they
> arise. Certainly inside the community are many critical people who watch
> these kind of things carefully and do correct those things when a mistake
> is made.
>
> The German community did collaborate, did communicate. Having a voting is a
> desperate way of getting the attention of the big problems WMF has too
> little insight in apparently. The community does not think in power
> structures, WMF does.
>
> Just as in 2013, again the problems start inside WMF and not in the
> community, and the community reacts on it.
>
> Romaine
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Romaine Wiki]

2014-08-13 2:46 GMT+02:00 svetlana :

> On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
> > That the community reacts the way it does now, is because they care very
> > much about the site and they notice something is terrible going wrong on
> > WMF side and too less is done to fix those problems/issues!
>
> if the community was not so willing to use force (ie a js hack) against
> the other party
>

You miss a very important thing here: the community does not want to use
such measure at all, but is forced to this by the inappropriate behaviour
of some WMF staff. The community gets the feeling that it isn't listened
to, while it has serious points and considerations which are stepped over
too lightly. And as I said before, we are all on the same ship. Sure a
captain must make decisions, but if parts have serious comments, issues,
and critics, such should not be ignored.


> instead of talking properly
>
> then the superprotect wouldn't exist at all
>
> you seeing the problem there? whose problem is it?
> desire to act out of the blue instead of collaborating
> they didn't collaborate at all
> they added the js hack as if it was something urgent, that needs saving
> people from
>
> i would only do this if someone added a virus into mv by mistake
>
> this community thinks that its power structures allow to tromp onto other
> people
>

I do not think the community thinks that way. Members of the community can
make mistake and staff members of WMF can make mistakes, I think that both
that community and WMF are grown up enough to correct mistakes if they
arise. Certainly inside the community are many critical people who watch
these kind of things carefully and do correct those things when a mistake
is made.

The German community did collaborate, did communicate. Having a voting is a
desperate way of getting the attention of the big problems WMF has too
little insight in apparently. The community does not think in power
structures, WMF does.

Just as in 2013, again the problems start inside WMF and not in the
community, and the community reacts on it.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Todd Allen]

If the WF wasn't so willing to use force (i.e. pushing unwanted changes)
against the other party

instead of talking properly

then the superprotect wouldn't exist at all

you seeing the problem there? whose problem is it?
desire to act out of the blue instead of collaborating
they didn't collaborate at all
they added Media Viewer as if it was something urgent, that will save people

this WMF thinks that its power structures allow it to tromp onto other
people

Works perfectly the other way too, doesn't it?


On Tue, Aug 12, 2014 at 6:46 PM, svetlana  wrote:

> On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
> > That the community reacts the way it does now, is because they care very
> > much about the site and they notice something is terrible going wrong on
> > WMF side and too less is done to fix those problems/issues!
>
> if the community was not so willing to use force (ie a js hack) against
> the other party
>
> instead of talking properly
>
> then the superprotect wouldn't exist at all
>
> you seeing the problem there? whose problem is it?
> desire to act out of the blue instead of collaborating
> they didn't collaborate at all
> they added the js hack as if it was something urgent, that needs saving
> people from
>
> i would only do this if someone added a virus into mv by mistake
>
> this community thinks that its power structures allow to tromp onto other
> people
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Pete Forsyth]

On Tue, Aug 12, 2014 at 5:46 PM, svetlana  wrote:

> On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
> > That the community reacts the way it does now, is because they care very
> > much about the site and they notice something is terrible going wrong on
> > WMF side and too less is done to fix those problems/issues!
>
> if the community was not so willing to use force (ie a js hack) against
> the other party


"Using force" could equally well apply to implementing a feature without
sufficient buy-in, and then refusing to roll it back when so requested.

The WMF's basis for concluding that readers are better served with the MV
than without it is riddled with holes, as exhaustively explained elsewhere.

You talk about admin accountability, Svetlana -- but what about
accountability for the WMF, when it makes sweeping changes that (among
other things) remove any suggestion of an "edit" functionality from "the
encyclopedia anyone can edit" from millions and millions of pages?

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[John Mark Vandenberg]

On Wed, Aug 13, 2014 at 10:48 AM, svetlana  wrote:
> On Wed, 13 Aug 2014, at 10:46, svetlana wrote:
>> On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
>> > That the community reacts the way it does now, is because they care very
>> > much about the site and they notice something is terrible going wrong on
>> > WMF side and too less is done to fix those problems/issues!
>>
>> if the community was not so willing to use force (ie a js hack) against the 
>> other party
>>
>> instead of talking properly
>>
>> then the superprotect wouldn't exist at all
>>
>> you seeing the problem there? whose problem is it?
>> desire to act out of the blue instead of collaborating
>> they didn't collaborate at all
>> they added the js hack as if it was something urgent, that needs saving 
>> people from
>>
>> i would only do this if someone added a virus into mv by mistake
>>
>> this community thinks that its power structures allow to tromp onto other 
>> people
>
> sysops aren't even held accountable
> they are elected once for an infinite term
> nobody reviews their contribution in position in power ever
>
> this would surely be solved by making them elected on a 2-year term
> then re-elect

Hi svetlana, there are several large wikis which have sysop
re-election policies; notably, German Wikipedia.

-- 
John Vandenberg

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Wed, 13 Aug 2014, at 10:46, svetlana wrote:
> On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
> > That the community reacts the way it does now, is because they care very
> > much about the site and they notice something is terrible going wrong on
> > WMF side and too less is done to fix those problems/issues!
> 
> if the community was not so willing to use force (ie a js hack) against the 
> other party
> 
> instead of talking properly
> 
> then the superprotect wouldn't exist at all
> 
> you seeing the problem there? whose problem is it?
> desire to act out of the blue instead of collaborating
> they didn't collaborate at all
> they added the js hack as if it was something urgent, that needs saving 
> people from
> 
> i would only do this if someone added a virus into mv by mistake
> 
> this community thinks that its power structures allow to tromp onto other 
> people

sysops aren't even held accountable
they are elected once for an infinite term
nobody reviews their contribution in position in power ever

this would surely be solved by making them elected on a 2-year term
then re-elect

svetlana

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
> That the community reacts the way it does now, is because they care very
> much about the site and they notice something is terrible going wrong on
> WMF side and too less is done to fix those problems/issues!

if the community was not so willing to use force (ie a js hack) against the 
other party

instead of talking properly

then the superprotect wouldn't exist at all

you seeing the problem there? whose problem is it?
desire to act out of the blue instead of collaborating
they didn't collaborate at all
they added the js hack as if it was something urgent, that needs saving people 
from

i would only do this if someone added a virus into mv by mistake

this community thinks that its power structures allow to tromp onto other people

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Brad Jorsch (Anomie)]

On Mon, Aug 11, 2014 at 6:54 PM, John Mark Vandenberg 
wrote:

> On Tue, Aug 12, 2014 at 3:49 AM, Brad Jorsch (Anomie)
>  wrote:
> > On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg 
> > wrote:
> >
> >> Before this, there was no expectation that a page could be protected
> >> such that sysops could not alter the content of the superprotected
> >> page.
> >>
> >
> > This is false.
>
> Care to explain?
>

https://www.mediawiki.org/w/index.php?title=Manual:$wgRestrictionLevels&diff=519048&oldid=451673
shows that protection levels that prevent sysops from editing were
considered as far back as 3 April 2012, for example.


> > Most of what MZMcBride posted there has nothing to do with actually
> > breaking superprotection. Editing a page that isn't superprotected isn't
> a
> > break in the protection feature itself, for example.
>
> Of course it is.  It isnt a 'feature' until it actually works at the
> released product level.
>

You appear to be confusing superprotection with something else, likely the
much larger concept of preventing JS hacks to disable MediaViewer.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Romaine Wiki]

Has it ever come to the mind that something is going wrong on how the
community is approached?

Has it ever come to the mind that some software implementations have gone
to hastily with negative effects?

That the community reacts the way it does now, is because they care very
much about the site and they notice something is terrible going wrong on
WMF side and too less is done to fix those problems/issues!

Apparently nothing (or not enough) has been learned from the VE 2013 fiasco.

Romaine


2014-08-10 15:27 GMT+02:00 Erik Moeller :

> Hi folks,
>
> Admins are currently given broad leeway to customize the user
> experience for all users, including addition of site-wide JS, CSS,
> etc. These are important capabilities of the wiki that have been used
> for many clearly beneficial purposes. In the long run, we will want to
> apply a code review process to these changes as with any other
> deployed code, but for now the system works as it is and we have no
> intent to remove this capability.
>
> However, we've clarified in a number of venues that use of the
> MediaWiki: namespace to disable site features is unacceptable. If such
> a conflict arises, we're prepared to revoke permissions if required.
> This protection level provides an additional path to manage these
> situations by preventing edits to the relevant pages (we're happy to
> help apply any urgent edits) until a particular situation has calmed
> down.
>
> Thanks,
> Erik
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Erik Moeller]

On Tue, Aug 12, 2014 at 10:19 AM, Craig Franklin
 wrote:

> I'll be writing a longer post on the Meta RFC later, but can you confirm
> whether the idea is to "superprotect" key interface pages like
> [[Mediawiki:common.js]] on a permanent basis, or will this feature only be
> used to lock pages temporarily in the case of wheel warring or other
> circumstances like what happened on de.wp?

Dear Craig,

Thank you for the question. Definitely the latter. In general, as I
mentioned in my original note, we intend to bring on-wiki
functionality that directly relates to the UI and code (i.e. chiefly
the MediaWiki: namespace, which is a highly unusual software feature
to begin with) in closer alignment with off-wiki software development,
review and deployment practices, including permission levels (e.g.
actually make it easier for anyone to submit changes, but gate changes
that impact all users).

Lila and I will post more thoughts on the larger issues within the
coming days. We deeply regret the disruptive impact this discussion is
having on Wikimedia's mission and our work together. At the same time,
working through these questions has long been overdue, and my hope is
that we can come out of this with greater clarity regarding how we
partner on issues that are often likely to be contentious, which
includes user experience changes.

Sincerely,

Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Pine W]

Straniu, Jimbo's comments in his keynote about forking concerned
encouraging competent editors who can't work cooperatively with other
people to fork in a way that would be better for everyone in the long run.
I don't believe this disappointing  confrontation between the WMF and
volunteers were what Jimbo had in mind.

Pine
On Aug 12, 2014 1:44 AM, "Strainu"  wrote:

> Hi Gerard,
>
> Some answers (in a random order).
>
> 2014-08-11 12:20 GMT+03:00 Gerard Meijssen :
> > You know our projects, you know our licenses. If you, the "community"do
> not
> > like what you have, you can fork. At Wikimania forking and leaving the
> > community was very much discussed. Watch Jimbo's presentation for
> instance,
> > he may be aghast that I quote him here but in his state of the Wiki he
> made
> > it abundantly clear that it is your option to stay or go.
>
> I gave up watching Jimbo's keynotes a few years ago, as I would
> invariably get pissed off. So, should we understand that the vast
> ammounts of money and resources spent on editor retention are a waste
> of our money? I sincerely hope this is a heat-of-the-moment argument,
> just like the one about closing de.wp.
>
> > Hoi,
> > Code review should be a strictly technical process surely. However the
> > community CANNOT decide on everything.
>
> Agreed. How about letting the WMF decide for anonymous users and the
> community decide for logged-in users? Presumably, the logged-in users
> have access to a large panel of options and can make up their own mind
> if they disagree with the consensus. Of course, discussions should not
> disappear because of such a separation, but even become more active
> and hopefully less aggressive.
>
>
> > When you are in those conversations you realise that many
> > complications are considered; it is not easy nor obvious.
> > NB there is not one community, there are many with often completely
> > diverging opinions. Technically it is not possible to always keep
> backward
> > compatibility / functionality. We are not backward we need to stay
> > contemporary.
>
> As a software engineer in a publicly traded company, I understand the
> reasoning behind more than 90% of the decisions made by the
> Engineering staff - and this worries me terribly, because they *don't*
> work for a company. Their objectives and approaches should be
> different.
>
> There are three main wiki-use-cases that should receive similar levels
> of attention:
> * reading
> * basic editing
> * advanced editing
>
> The first two receive a lot of love, but the third one not so much,
> it's even hindered by initiatives designed for the first two. I'm not
> saying that we should keep backwards compatibility forever, but since
> the WMF wants to deploy stuff early in order to get feedback, it
> should begin by offering it as a beta (they do that now), then, when
> reaching a decent level of stability, deploy it for anonymous users
> and opt-in users and only when it reaches feature-parity with the
> feature being replaced should it be pushed for everybody (keeping an
> opt-out feature for some time - months or a couple of years).
>
> Take for instance the media viewer: the current version is useless for
> editors, as it has basically no controls visible by default (without
> scrolling). The future version, presented at Wikimania, has a lot more
> stuff visible on the first screen, making it much easier to use for
> editing. I believe that the media viewer should have been kept as
> opt-in for logged in users until this future version arrives.
>
> Strainu
>
> ___
> Wikitech-l mailing list
> wikitec...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Craig Franklin]

Erik,

I'll be writing a longer post on the Meta RFC later, but can you confirm
whether the idea is to "superprotect" key interface pages like
[[Mediawiki:common.js]] on a permanent basis, or will this feature only be
used to lock pages temporarily in the case of wheel warring or other
circumstances like what happened on de.wp?

Thanks,
Craig Franklin


On 10 August 2014 23:27, Erik Moeller  wrote:

> Hi folks,
>
> Admins are currently given broad leeway to customize the user
> experience for all users, including addition of site-wide JS, CSS,
> etc. These are important capabilities of the wiki that have been used
> for many clearly beneficial purposes. In the long run, we will want to
> apply a code review process to these changes as with any other
> deployed code, but for now the system works as it is and we have no
> intent to remove this capability.
>
> However, we've clarified in a number of venues that use of the
> MediaWiki: namespace to disable site features is unacceptable. If such
> a conflict arises, we're prepared to revoke permissions if required.
> This protection level provides an additional path to manage these
> situations by preventing edits to the relevant pages (we're happy to
> help apply any urgent edits) until a particular situation has calmed
> down.
>
> Thanks,
> Erik
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[John Mark Vandenberg]

On Tue, Aug 12, 2014 at 3:49 AM, Brad Jorsch (Anomie)
 wrote:
> On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg 
> wrote:
>
>> Before this, there was no expectation that a page could be protected
>> such that sysops could not alter the content of the superprotected
>> page.
>>
>
> This is false.

Care to explain?

Was this functionality was ever supported by MediaWiki core?
Could you point me towards some documentation?

>> Now, the devs/ops have attempted to introduce that capability, and the
>> new functionality is very likely riddled with holes, some of which
>> MZMcBride has suggested in the thread 'Options for the German
>> Wikipedia'.
>>
>
> Most of what MZMcBride posted there has nothing to do with actually
> breaking superprotection. Editing a page that isn't superprotected isn't a
> break in the protection feature itself, for example.

Of course it is.  It isnt a 'feature' until it actually works at the
released product level.
Rushing component level hardening changes into production, when
everyone knows how to work around the new 'hardened' code, it very bad
change management.
It likely introduces unforeseen bugs, for no actual gain.

--
John Vandenberg

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Brad Jorsch (Anomie)]

On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg 
wrote:

> Before this, there was no expectation that a page could be protected
> such that sysops could not alter the content of the superprotected
> page.
>

This is false.


> Now, the devs/ops have attempted to introduce that capability, and the
> new functionality is very likely riddled with holes, some of which
> MZMcBride has suggested in the thread 'Options for the German
> Wikipedia'.
>

Most of what MZMcBride posted there has nothing to do with actually
breaking superprotection. Editing a page that isn't superprotected isn't a
break in the protection feature itself, for example. Nor is hacking
people's accounts.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Todd Allen]

And what happens when said admin is overwhelmingly reelected by the
community?

This is not the way forward. WMF can't continue to treat its volunteers in
this manner.
On Aug 11, 2014 12:01 PM, "John Mark Vandenberg"  wrote:

> On Tue, Aug 12, 2014 at 12:18 AM, Brian Wolff  wrote:
> >>
> >> Now, having observed that not only user Eloquence (aka Erik Moeller)
> >> himself engaged in the enforcement of   right on de.wp
> >> [1] but soon after a workaround was published a change was deployed
> >> [2, 3] as counter measurement to block any possible interference can
> >> no longer be interpret as acting in good faith but rather strikes me
> >> as a form of oppression (or worst as censorship).
> >>
> >
> > [Putting the purely mw dev hat on]
> >
> > It was a bug in mediawiki, and thus it should be fixed. MediaWiki is used
> > by many different groups and in general we [mw devs] do not judge people
> > for how they use the software. If some non wmf entity reported the bug,
> it
> > would still be fixed.
> >
> > So dont complain that mw fixes a bug in how page protection. If you are
> > unhappy with current events you should direct your anger at how the wmf
> > decided to use hard security to enforce its dictates, not at the software
> > for "working".
>
> Sorry Brian, which bug are you referring to?  Could you point me to a
> bug report?
>
> Before this, there was no expectation that a page could be protected
> such that sysops could not alter the content of the superprotected
> page.
>
> Now, the devs/ops have attempted to introduce that capability, and the
> new functionality is very likely riddled with holes, some of which
> MZMcBride has suggested in the thread 'Options for the German
> Wikipedia'.
>
> Moreover the deployed technical change is useless due to design flaws.
> What was the goal of this change?  Was it to prevent sysops injecting
> JavaScript that logged out user-agents execute?  If that is the
> use-case, this patch is a very weak solution from an engineering
> perspective.  It was rushed it into a production environment, and
> needed a follow up patch almost immediately.  And the bug reports for
> this new functionality will surely roll in.
>
> These patches only make it 'forbidden' to deactivate the MediaViewer.
> They don't prevent it.  These patches only introduce a new policy,
> signalling a new era, and make it technically more challenging to
> bypass that new policy.  The policy written says "Sysops are not
> allowed to inject JavaScript into the reader's user-agent which
> interferes with WMF's favoured features."  It is still possible, but
> the only thing that is stopping de.wp sysops from deactivating the
> MediaViewer some other way is that the WMF has demonstrated it will
> make drastic changes to the MediaWiki configuration to take away
> capabilities from their community.  Should the community work-around
> this change, they are fairly confident that the WMF will desysop
> whoeverdoes it, or more configuration changes and superprotection will
> occur.
>
> --
> 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,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[John Mark Vandenberg]

On Tue, Aug 12, 2014 at 12:18 AM, Brian Wolff  wrote:
>>
>> Now, having observed that not only user Eloquence (aka Erik Moeller)
>> himself engaged in the enforcement of   right on de.wp
>> [1] but soon after a workaround was published a change was deployed
>> [2, 3] as counter measurement to block any possible interference can
>> no longer be interpret as acting in good faith but rather strikes me
>> as a form of oppression (or worst as censorship).
>>
>
> [Putting the purely mw dev hat on]
>
> It was a bug in mediawiki, and thus it should be fixed. MediaWiki is used
> by many different groups and in general we [mw devs] do not judge people
> for how they use the software. If some non wmf entity reported the bug, it
> would still be fixed.
>
> So dont complain that mw fixes a bug in how page protection. If you are
> unhappy with current events you should direct your anger at how the wmf
> decided to use hard security to enforce its dictates, not at the software
> for "working".

Sorry Brian, which bug are you referring to?  Could you point me to a
bug report?

Before this, there was no expectation that a page could be protected
such that sysops could not alter the content of the superprotected
page.

Now, the devs/ops have attempted to introduce that capability, and the
new functionality is very likely riddled with holes, some of which
MZMcBride has suggested in the thread 'Options for the German
Wikipedia'.

Moreover the deployed technical change is useless due to design flaws.
What was the goal of this change?  Was it to prevent sysops injecting
JavaScript that logged out user-agents execute?  If that is the
use-case, this patch is a very weak solution from an engineering
perspective.  It was rushed it into a production environment, and
needed a follow up patch almost immediately.  And the bug reports for
this new functionality will surely roll in.

These patches only make it 'forbidden' to deactivate the MediaViewer.
They don't prevent it.  These patches only introduce a new policy,
signalling a new era, and make it technically more challenging to
bypass that new policy.  The policy written says "Sysops are not
allowed to inject JavaScript into the reader's user-agent which
interferes with WMF's favoured features."  It is still possible, but
the only thing that is stopping de.wp sysops from deactivating the
MediaViewer some other way is that the WMF has demonstrated it will
make drastic changes to the MediaWiki configuration to take away
capabilities from their community.  Should the community work-around
this change, they are fairly confident that the WMF will desysop
whoeverdoes it, or more configuration changes and superprotection will
occur.

--
John Vandenberg

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Comet styles]

Erik, I wonder, did you have discussion with other staff and moreso,
the technical staff before you went ahead and implemented this and
also something most of us are wondering, just because dewiki did not
accept your "enforcement" of MediaViewer, did you abuse your authority
and force the technical staff to create this new permission
(superprotect) so that you can override a community's decision..a
permission which currently only the staff have access to?

Seems a bit dictator-like...


your comments above is just not reasonable enough..

On 8/11/14, svetlana  wrote:
> On Mon, 11 Aug 2014, at 08:42, Tomasz W. Kozłowski wrote:
>> Someone is definitely forgetting that Wikimedia wikis are not the
>> Foundation's personal playground.
>
> It is becoming one for a long time now.
>
> svetlana
>
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 


-- 
Cometstyles

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Mon, 11 Aug 2014, at 08:42, Tomasz W. Kozłowski wrote:
> Someone is definitely forgetting that Wikimedia wikis are not the
> Foundation's personal playground.

It is becoming one for a long time now.

svetlana

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Austin Hair]

On Sun, Aug 10, 2014 at 11:42 PM, Tomasz W. Kozłowski
 wrote:
> Someone is definitely forgetting that Wikimedia wikis are not the
> Foundation's personal playground.
>
> You should be ashamed of yourself, Erik, and you should resign or be fired.
>
> And all volunteers should make sure to remember who was involved in
> deploying those shameful patches to Wikimedia wikis without consulting
> anything with the people who actually matter -- the community.

Tomasz,

While I appreciate your indignation, this is absolutely not the tone
appropriate for the list, nor is it one likely to effect your desired
outcome. Please be civil, and consider commenting on the RfC rather
than making personal attacks and veiled threats on this mailing list.

Austin

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Tomasz W . Kozłowski]

The show must go on.

To ensure that no German Wikipedia administrator deletes
MediaWiki:Common.js to cancel the super-protection, the WMF has just
merged  and deployed it to
Wikimedia wikis as a matter of emergency after a personal request from
Erik Moller.

Someone is definitely forgetting that Wikimedia wikis are not the
Foundation's personal playground.

You should be ashamed of yourself, Erik, and you should resign or be fired.

And all volunteers should make sure to remember who was involved in
deploying those shameful patches to Wikimedia wikis without consulting
anything with the people who actually matter -- the community.

Tomasz

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Austin Hair]

On Sun, Aug 10, 2014 at 6:29 PM, John Mark Vandenberg  wrote:
> As this has wide-ranging implications, I have started an RFC on meta
>
> https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotect_rights

With that done, I'd like to ask that discussion on this topic be
continued there. Not that this isn't an appropriate forum for the
issue to be raised, because it obviously is, but a public,
transparent, and permanently documented RfC seems like a better place
for it than the inboxes of this select few.

Austin

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Chris Keating]

>
> It is clear to me that the Foundation has agreed on this sneaky change
> behind closed doors while some of the most outspoken Wikimedia
> volunteers were (and still are) gathered in London.


It's interesting you mention Wikimania, because one of the things I took
away from the conference was the idea that if Wikimedia sites keep on
looking and acting like they did in 2004, we'll get left behind by the rest
of the internet

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Tomasz W . Kozłowski]

This is, by far, the most disgusting and disrespectful action
undertaken by the Foundation that I have ever witnessed. The 2012 mass
desysopping of volunteer administrators on the WMF wiki and the past
threats of desysopping users re: VisualEditor and MediaViewer do not
even come close to this.

It is clear to me that the Foundation has agreed on this sneaky change
behind closed doors while some of the most outspoken Wikimedia
volunteers were (and still are) gathered in London. This is not the
first time that we're seeing this happpen, and it is clear to me that
the Foundation has lost all remaining moral authority to talk about
transparency and involving volunteers in the decision-making process.

Erik has forced his employees, including a so-called community
advocacy liaison, to use this opportunity to actively fight the
volunteer community of the German Wikipedia. He himself has engaged in
a wheel war over this, and continues to shove MediaViewer down the
German Wikipedia's community throat.

I'm not sure what was the purpose of this change, but if its aim was
to escalate the already tense situation between the WMF and its
volunteer communities regarding MediaViewer, protecting the
MediaWiki:Common.js page so that no one can edit it was the perfect
choice.

This action will cause a huge shitstorm, and Erik deserves every bit
of shit and mud that will be thrown his way.

You can force anything you like on your employees, but you cannot
force the volunteer community to do what you want, not in a manner
like this.

Remember that in the end, the community can exist without the WMF, but
there is no WMF without the community.

-- 
Tomasz

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[rupert THURNER]

On Sun, Aug 10, 2014 at 3:27 PM, Erik Moeller  wrote:
> Hi folks,
>
> Admins are currently given broad leeway to customize the user
> experience for all users, including addition of site-wide JS, CSS,
> etc. These are important capabilities of the wiki that have been used
> for many clearly beneficial purposes. In the long run, we will want to
> apply a code review process to these changes as with any other
> deployed code, but for now the system works as it is and we have no
> intent to remove this capability.
>
> However, we've clarified in a number of venues that use of the
> MediaWiki: namespace to disable site features is unacceptable. If such
> a conflict arises, we're prepared to revoke permissions if required.
> This protection level provides an additional path to manage these
> situations by preventing edits to the relevant pages (we're happy to
> help apply any urgent edits) until a particular situation has calmed
> down.

erik, this was designed so, and worked well exactly like this.
administrators are voted, and there are hundreds which work together.
if it is wise process to review a change by another administrator
implement it like this. that has to be enough. it worked well 5 years
ago when we had most new editors joining. if you cannot convince the
admins about a change, there is strong evidence that something else is
wrong - not the user rights.

rupert

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[John Mark Vandenberg]

On Sun, Aug 10, 2014 at 10:08 PM, MZMcBride  wrote:
> David Gerard wrote:
>>On 10 August 2014 15:51, MZMcBride  wrote:
>>> You'd been threatening to implement super-protection for a long time. I
>>> see you finally made good on this very bad idea. This is certainly bold,
>>> but also incredibly reckless. Your response to being told "we don't like
>>> your software" is to try shove it down a wiki community's throat?
>>
>>I thought this was a response to someone hamfistedly editing en:wp's
>>JS and *actually breaking it*. When Erik reverted this change and said
>>"don't break the damn wiki", the response was "but we can so we should
>>be able to!" and an attempt to take the Foundation to en:wp
>>arbitration. The obvious response is to make it so that such
>>blithering stupidity can't be enacted again.
>
> Super-protection was implemented in response to the German, not English,
> Wikipedia. It turns out that multiple communities don't like MediaViewer.
>
> Erik is squarely responsible for the mess being made here and deserves the
> full blame and consequences. He instigated the arbitration case on the
> English Wikipedia and he's now instigating a war with the German Wikipedia.
>
> The German Wikipedia community has looked at and evaluated MediaViewer and
> has decided that it doesn't want MediaViewer enabled on its wiki. Erik has
> made it his mission to force MediaViewer on the German Wikipedians (and
> the Commoners), using system administrators and community advocates and
> anyone else he can coerce. This is unacceptable behavior on Erik's part.
> MediaViewer is an entirely supplementary feature, not some fundamental or
> critical piece of infrastructure in desperate need of protection.

As this has wide-ranging implications, I have started an RFC on meta

https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotect_rights

--
John Vandenberg

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Gerard]

On 10 August 2014 16:08, MZMcBride  wrote:

> He instigated the arbitration case on the
> English Wikipedia


That's *definitely* a claim needing actual evidence, considering he
didn't bring it. I assume you can produce something.


- d.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[MZMcBride]

David Gerard wrote:
>On 10 August 2014 15:51, MZMcBride  wrote:
>> You'd been threatening to implement super-protection for a long time. I
>> see you finally made good on this very bad idea. This is certainly bold,
>> but also incredibly reckless. Your response to being told "we don't like
>> your software" is to try shove it down a wiki community's throat?
>
>I thought this was a response to someone hamfistedly editing en:wp's
>JS and *actually breaking it*. When Erik reverted this change and said
>"don't break the damn wiki", the response was "but we can so we should
>be able to!" and an attempt to take the Foundation to en:wp
>arbitration. The obvious response is to make it so that such
>blithering stupidity can't be enacted again.

Super-protection was implemented in response to the German, not English,
Wikipedia. It turns out that multiple communities don't like MediaViewer.

Erik is squarely responsible for the mess being made here and deserves the
full blame and consequences. He instigated the arbitration case on the
English Wikipedia and he's now instigating a war with the German Wikipedia.

The German Wikipedia community has looked at and evaluated MediaViewer and
has decided that it doesn't want MediaViewer enabled on its wiki. Erik has
made it his mission to force MediaViewer on the German Wikipedians (and
the Commoners), using system administrators and community advocates and
anyone else he can coerce. This is unacceptable behavior on Erik's part.
MediaViewer is an entirely supplementary feature, not some fundamental or
critical piece of infrastructure in desperate need of protection.

MZMcBride



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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[David Gerard]

On 10 August 2014 15:51, MZMcBride  wrote:

> You'd been threatening to implement super-protection for a long time. I
> see you finally made good on this very bad idea. This is certainly bold,
> but also incredibly reckless. Your response to being told "we don't like
> your software" is to try shove it down a wiki community's throat?


I thought this was a response to someone hamfistedly editing en:wp's
JS and *actually breaking it*. When Erik reverted this change and said
"don't break the damn wiki", the response was "but we can so we should
be able to!" and an attempt to take the Foundation to en:wp
arbitration. The obvious response is to make it so that such
blithering stupidity can't be enacted again.


- d.

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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[MZMcBride]

Erik Moeller wrote:
>Admins are currently given broad leeway to customize the user
>experience for all users, including addition of site-wide JS, CSS,
>etc. These are important capabilities of the wiki that have been used
>for many clearly beneficial purposes. In the long run, we will want to
>apply a code review process to these changes as with any other
>deployed code, but for now the system works as it is and we have no
>intent to remove this capability.
>
>However, we've clarified in a number of venues that use of the
>MediaWiki: namespace to disable site features is unacceptable. If such
>a conflict arises, we're prepared to revoke permissions if required.
>This protection level provides an additional path to manage these
>situations by preventing edits to the relevant pages (we're happy to
>help apply any urgent edits) until a particular situation has calmed
>down.

Let's be clear here. You unilaterally implemented super-protection and
then had a "Community Advocate" apply this new protection level to the
German Wikipedia's "MediaWiki:Common.js"?

You'd been threatening to implement super-protection for a long time. I
see you finally made good on this very bad idea. This is certainly bold,
but also incredibly reckless. Your response to being told "we don't like
your software" is to try shove it down a wiki community's throat?

The German Wikipedia can easily use "MediaWiki:Vector.js" or an
on-by-default JavaScript gadget to implement this change. The German
Wikipedia can also block Jan Eissfeldt's account for conduct unbecoming of
an administrator. In my opinion, it also wouldn't be unreasonable for the
stewards to remove Jan Eissfeldt's capability to protect this page.

MZMcBride



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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Maarten Dammers]

Hi Erik,

I understand you reasoning, but you couldn't have communicated and timed 
this in a worse way. You might be doing the right thing, but because of 
this ill communication and timing, this will be completely overshadowed. 
That saddens me. Good luck with the shit storm :-(


Maarten

Erik Moeller schreef op 10-8-2014 14:27:

Hi folks,

Admins are currently given broad leeway to customize the user
experience for all users, including addition of site-wide JS, CSS,
etc. These are important capabilities of the wiki that have been used
for many clearly beneficial purposes. In the long run, we will want to
apply a code review process to these changes as with any other
deployed code, but for now the system works as it is and we have no
intent to remove this capability.

However, we've clarified in a number of venues that use of the
MediaWiki: namespace to disable site features is unacceptable. If such
a conflict arises, we're prepared to revoke permissions if required.
This protection level provides an additional path to manage these
situations by preventing edits to the relevant pages (we're happy to
help apply any urgent edits) until a particular situation has calmed
down.

Thanks,
Erik



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

Re: [Wikimedia-l] [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Erik Moeller]

Hi folks,

Admins are currently given broad leeway to customize the user
experience for all users, including addition of site-wide JS, CSS,
etc. These are important capabilities of the wiki that have been used
for many clearly beneficial purposes. In the long run, we will want to
apply a code review process to these changes as with any other
deployed code, but for now the system works as it is and we have no
intent to remove this capability.

However, we've clarified in a number of venues that use of the
MediaWiki: namespace to disable site features is unacceptable. If such
a conflict arises, we're prepared to revoke permissions if required.
This protection level provides an additional path to manage these
situations by preventing edits to the relevant pages (we're happy to
help apply any urgent edits) until a particular situation has calmed
down.

Thanks,
Erik
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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