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

2014-08-15 Thread David Cuenca
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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-15 Thread 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 dacu...@gmail.com 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,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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

2014-08-14 Thread Russavia
Erik

On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller e...@wikimedia.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread 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 russavia.wikipe...@gmail.com wrote:

Erik

On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller e...@wikimedia.org 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,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread Erik Moeller
On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride z...@mzmcbride.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread 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 e...@wikimedia.org wrote:

 On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride z...@mzmcbride.com 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 

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

2014-08-14 Thread David Gerard
On 14 August 2014 13:56, David Cuenca dacu...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread Todd Allen
On Aug 14, 2014 3:58 AM, Erik Moeller e...@wikimedia.org wrote:

 On Thu, Aug 14, 2014 at 5:41 AM, MZMcBride z...@mzmcbride.com 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. There isn't a way you can overrule 

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

2014-08-14 Thread David Cuenca
On Thu, Aug 14, 2014 at 3:35 PM, David Gerard dger...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread Chris Keating
On 14 Aug 2014 14:50, David Cuenca dacu...@gmail.com wrote:

 On Thu, Aug 14, 2014 at 3:35 PM, David Gerard dger...@gmail.com 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,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread svetlana
On Thu, 14 Aug 2014, at 23:35, David Gerard wrote:
 On 14 August 2014 13:56, David Cuenca dacu...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread 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 dacu...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-14 Thread Mark

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

On 14 August 2014 13:56, David Cuenca dacu...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread svetlana
On Wed, 13 Aug 2014, at 10:53, Pete Forsyth wrote:
 On Tue, Aug 12, 2014 at 5:46 PM, svetlana svetl...@fastmail.com.au 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread svetlana
On Wed, 13 Aug 2014, at 12:01, Romaine Wiki wrote:
 2014-08-13 2:46 GMT+02:00 svetlana svetl...@fastmail.com.au:
  [..]
 [...]
  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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread Pete Forsyth
On Wed, Aug 13, 2014 at 3:27 AM, svetlana svetl...@fastmail.com.au wrote:

 On Wed, 13 Aug 2014, at 10:53, Pete Forsyth wrote:
  On Tue, Aug 12, 2014 at 5:46 PM, svetlana svetl...@fastmail.com.au
 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread Pete Forsyth
On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier m...@uberbox.org
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
https://en.wikipedia.org/wiki/Wikipedia:Arbitration/Requests/Case/Media_Viewer_RfC/Evidence#Evidence_presented_by_Pete_Forsyth,
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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread Trillium Corsage


13.08.2014, 01:46, svetlana svetl...@fastmail.com.au:


 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread Michael Peel

On 13 Aug 2014, at 21:12, Pete Forsyth petefors...@gmail.com wrote:

 On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier m...@uberbox.org
 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread Erik Moeller
On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth petefors...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread Pete Forsyth
On Wed, Aug 13, 2014 at 2:32 PM, Erik Moeller e...@wikimedia.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread svetlana
On Thu, 14 Aug 2014, at 00:50, Pete Forsyth wrote:
 On Wed, Aug 13, 2014 at 3:27 AM, svetlana svetl...@fastmail.com.au 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-13 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-12 Thread 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 e...@wikimedia.org 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,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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

2014-08-12 Thread 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 strain...@gmail.com wrote:

 Hi Gerard,

 Some answers (in a random order).

 2014-08-11 12:20 GMT+03:00 Gerard Meijssen gerard.meijs...@gmail.com:
  You know our projects, you know our licenses. If you, the communitydo
 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-12 Thread Erik Moeller
On Tue, Aug 12, 2014 at 10:19 AM, Craig Franklin
cfrank...@halonetwork.net 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-12 Thread 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 e...@wikimedia.org:

 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,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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

2014-08-12 Thread Brad Jorsch (Anomie)
On Mon, Aug 11, 2014 at 6:54 PM, John Mark Vandenberg jay...@gmail.com
wrote:

 On Tue, Aug 12, 2014 at 3:49 AM, Brad Jorsch (Anomie)
 bjor...@wikimedia.org wrote:
  On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jay...@gmail.com
  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:$wgRestrictionLevelsdiff=519048oldid=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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-12 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-12 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-12 Thread Pete Forsyth
On Tue, Aug 12, 2014 at 5:46 PM, svetlana svetl...@fastmail.com.au 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-12 Thread 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 svetl...@fastmail.com.au 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,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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

2014-08-12 Thread Romaine Wiki
2014-08-13 2:46 GMT+02:00 svetlana svetl...@fastmail.com.au:

 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-11 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-11 Thread 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 svetl...@fastmail.com.au 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,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe


-- 
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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-11 Thread John Mark Vandenberg
On Tue, Aug 12, 2014 at 12:18 AM, Brian Wolff bawo...@gmail.com wrote:

 Now, having observed that not only user Eloquence (aka Erik Moeller)
 himself engaged in the enforcement of  superprotect 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-11 Thread 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 jay...@gmail.com wrote:

 On Tue, Aug 12, 2014 at 12:18 AM, Brian Wolff bawo...@gmail.com wrote:
 
  Now, having observed that not only user Eloquence (aka Erik Moeller)
  himself engaged in the enforcement of  superprotect 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,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-11 Thread Brad Jorsch (Anomie)
On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jay...@gmail.com
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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-11 Thread John Mark Vandenberg
On Tue, Aug 12, 2014 at 3:49 AM, Brad Jorsch (Anomie)
bjor...@wikimedia.org wrote:
 On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jay...@gmail.com
 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread David Gerard
On 10 August 2014 15:51, MZMcBride z...@mzmcbride.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread MZMcBride
David Gerard wrote:
On 10 August 2014 15:51, MZMcBride z...@mzmcbride.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread David Gerard
On 10 August 2014 16:08, MZMcBride z...@mzmcbride.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread John Mark Vandenberg
On Sun, Aug 10, 2014 at 10:08 PM, MZMcBride z...@mzmcbride.com wrote:
 David Gerard wrote:
On 10 August 2014 15:51, MZMcBride z...@mzmcbride.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread rupert THURNER
On Sun, Aug 10, 2014 at 3:27 PM, Erik Moeller e...@wikimedia.org 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread Austin Hair
On Sun, Aug 10, 2014 at 6:29 PM, John Mark Vandenberg jay...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread 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 https://gerrit.wikimedia.org/r/#/c/153345/ 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

2014-08-10 Thread Austin Hair
On Sun, Aug 10, 2014 at 11:42 PM, Tomasz W. Kozłowski
twkozlow...@gmail.com 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, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe