Lets all welcome the new overlord Erik.
Add a new protection level called "superprotect" Assigned to nobody by default. Requested by Erik Möller for the purposes of protecting pages such that sysop permissions are not sufficient to
edit them. Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e https://gerrit.wikimedia.org/r/#q,Idfa211257dbacc7623d42393257de1525ff01e9e,n,z
https://gerrit.wikimedia.org/r/#/c/153302/
Someone clearly can't take criticism of their projects well.
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
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
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
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.
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
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.
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
On Sun, Aug 10, 2014 at 6:29 PM, John Mark Vandenberg jayvdb@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
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
The people who were actually responsible were the community. Erik was acting in a preventative role to prevent further disruption not punish administrators. The community. couldn't take no for an answer and what has happened?
* Wheel/edit wars * A new user right to prevent disruption * A priviledge has been revoked on dewiki * A user has been desysoped by the community for no reason on dewiki
And who are we blaming? Erik. Why? Because we are a bunch of stubborn children. We don't get what we want so we are kicking and screaming to get it but in the end; we don't and we then accuse our parent (WMF) of being too harsh, mean and taking away something we like but do not deserve.
To be honest - until we as a community learn we are not the overlords, the masters, god of Wikimedia, we can work to building a real encyclopedia with awesome feature where are all work in a good environment and get on as a community and Foundation.
I am not saying the WMF is perfect and is not in the wrong; they certainly have some blame to take and I will come onto that shortly, but we can not blame the Foundation for revoking something we clearly do not deserve.
Erik, While I will say you have not been communicating stuff the best you can and this new user right was proxy deployed by Tim and an advocate and not your self - you mean well and I see this. I agree with everything you have done so far as a matter of fact.
Fabrice, Have you attempted to start any discussions with communities in exactly why they don't want Media Viewer and how exactly it causes so much dispute that it requires Erik to proxy intervene? It not, please do so.
In a short conclusion - I feel both parties have acted inappropriately and our bitching at each other does far than solve it. The WMF had to implement a new right and revoke dewiki's access to their site wide js page because of their refusal to accept what the WMF said and want to create a performance killer hack to 'fix it' at the cost of performance. Why did dewiki have to do this? The WMF refusing to disable Media Viewer. From what I see, the WMF have backed up by they refused to do this for Wikipedias and their compromise for Commons is acceptable. I have yet to see a valid reason why Media Viewer exactly makes Wikipedia go into a 'OMG UNUSABLE DISABLE IT FUCKING NOW OR I WILL' state. Media Viewer allows you to view and images without leaving the page - reducing load time for both users and the WMF. It is hardly the beginning if the end for images.
If we take a quick look at the statistics - 64 voted against Media Viewer on the English Wikipedia while 6kish users enabled it, this shows 1.1% consensus for disabling the extension in a whole.
I will not ramble on any more. I just ask the community to stop bitching at the WMF and accept their decision. Until then - I fully support Erik super protecting every single js and CSS page on every wiki as most Sysop I feel are technically incompetent.
John Lewis
Your mail is embarrassing. If you think the foundation is like the parent of the community, you don't understand anything about the foundation nor the community. Am 11.08.2014 00:05 schrieb "John Lewis" johnflewis93@gmail.com:
The people who were actually responsible were the community. Erik was acting in a preventative role to prevent further disruption not punish administrators. The community. couldn't take no for an answer and what has happened?
- Wheel/edit wars
- A new user right to prevent disruption
- A priviledge has been revoked on dewiki
- A user has been desysoped by the community for no reason on dewiki
And who are we blaming? Erik. Why? Because we are a bunch of stubborn children. We don't get what we want so we are kicking and screaming to get it but in the end; we don't and we then accuse our parent (WMF) of being too harsh, mean and taking away something we like but do not deserve.
To be honest - until we as a community learn we are not the overlords, the masters, god of Wikimedia, we can work to building a real encyclopedia with awesome feature where are all work in a good environment and get on as a community and Foundation.
I am not saying the WMF is perfect and is not in the wrong; they certainly have some blame to take and I will come onto that shortly, but we can not blame the Foundation for revoking something we clearly do not deserve.
Erik, While I will say you have not been communicating stuff the best you can and this new user right was proxy deployed by Tim and an advocate and not your self - you mean well and I see this. I agree with everything you have done so far as a matter of fact.
Fabrice, Have you attempted to start any discussions with communities in exactly why they don't want Media Viewer and how exactly it causes so much dispute that it requires Erik to proxy intervene? It not, please do so.
In a short conclusion - I feel both parties have acted inappropriately and our bitching at each other does far than solve it. The WMF had to implement a new right and revoke dewiki's access to their site wide js page because of their refusal to accept what the WMF said and want to create a performance killer hack to 'fix it' at the cost of performance. Why did dewiki have to do this? The WMF refusing to disable Media Viewer. From what I see, the WMF have backed up by they refused to do this for Wikipedias and their compromise for Commons is acceptable. I have yet to see a valid reason why Media Viewer exactly makes Wikipedia go into a 'OMG UNUSABLE DISABLE IT FUCKING NOW OR I WILL' state. Media Viewer allows you to view and images without leaving the page - reducing load time for both users and the WMF. It is hardly the beginning if the end for images.
If we take a quick look at the statistics - 64 voted against Media Viewer on the English Wikipedia while 6kish users enabled it, this shows 1.1% consensus for disabling the extension in a whole.
I will not ramble on any more. I just ask the community to stop bitching at the WMF and accept their decision. Until then - I fully support Erik super protecting every single js and CSS page on every wiki as most Sysop I feel are technically incompetent.
John Lewis
-- John Lewis _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
MF-Warburg, that came across as a bit rude... On 11 Aug 2014 00:29, "MF-Warburg" mfwarburg@googlemail.com wrote:
Your mail is embarrassing. If you think the foundation is like the parent of the community, you don't understand anything about the foundation nor the community. Am 11.08.2014 00:05 schrieb "John Lewis" johnflewis93@gmail.com:
The people who were actually responsible were the community. Erik was acting in a preventative role to prevent further disruption not punish administrators. The community. couldn't take no for an answer and what
has
happened?
- Wheel/edit wars
- A new user right to prevent disruption
- A priviledge has been revoked on dewiki
- A user has been desysoped by the community for no reason on dewiki
And who are we blaming? Erik. Why? Because we are a bunch of stubborn children. We don't get what we want so we are kicking and screaming to
get
it but in the end; we don't and we then accuse our parent (WMF) of being too harsh, mean and taking away something we like but do not deserve.
To be honest - until we as a community learn we are not the overlords,
the
masters, god of Wikimedia, we can work to building a real encyclopedia with awesome
feature
where are all work in a good environment and get on as a community and Foundation.
I am not saying the WMF is perfect and is not in the wrong; they
certainly
have some blame to take and I will come onto that shortly, but we can not blame the Foundation for revoking something we clearly do not deserve.
Erik, While I will say you have not been communicating stuff the best you can and this new user right was proxy deployed by Tim and an advocate and not your self - you mean well and I see this. I agree with everything you have done so far as a matter of fact.
Fabrice, Have you attempted to start any discussions with communities in exactly why they don't want Media Viewer and how exactly it causes so
much
dispute that it requires Erik to proxy intervene? It not, please do so.
In a short conclusion - I feel both parties have acted inappropriately
and
our bitching at each other does far than solve it. The WMF had to
implement
a new right and revoke dewiki's access to their site wide js page because of their refusal to accept what the WMF said and want to create a performance killer hack to 'fix it' at the cost of performance. Why did dewiki have to do this? The WMF refusing to disable Media Viewer. From
what
I see, the WMF have backed up by they refused to do this for Wikipedias
and
their compromise for Commons is acceptable. I have yet to see a valid reason why Media Viewer exactly makes Wikipedia go into a 'OMG UNUSABLE DISABLE IT FUCKING NOW OR I WILL' state. Media Viewer allows you to view and images without leaving the page - reducing load time for both users
and
the WMF. It is hardly the beginning if the end for images.
If we take a quick look at the statistics - 64 voted against Media Viewer on the English Wikipedia while 6kish users enabled it, this shows 1.1% consensus for disabling the extension in a whole.
I will not ramble on any more. I just ask the community to stop bitching
at
the WMF and accept their decision. Until then - I fully support Erik
super
protecting every single js and CSS page on every wiki as most Sysop I
feel
are technically incompetent.
John Lewis
-- John Lewis _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Oh sorry, that was totally not the intention. It must be the strange beer here at the Thistle Barbecue hotel. Am 11.08.2014 00:54 schrieb "Richard Symonds" < richard.symonds@wikimedia.org.uk>:
MF-Warburg, that came across as a bit rude... On 11 Aug 2014 00:29, "MF-Warburg" mfwarburg@googlemail.com wrote:
Your mail is embarrassing. If you think the foundation is like the parent of the community, you
don't
understand anything about the foundation nor the community. Am 11.08.2014 00:05 schrieb "John Lewis" johnflewis93@gmail.com:
The people who were actually responsible were the community. Erik was acting in a preventative role to prevent further disruption not punish administrators. The community. couldn't take no for an answer and what
has
happened?
- Wheel/edit wars
- A new user right to prevent disruption
- A priviledge has been revoked on dewiki
- A user has been desysoped by the community for no reason on dewiki
And who are we blaming? Erik. Why? Because we are a bunch of stubborn children. We don't get what we want so we are kicking and screaming to
get
it but in the end; we don't and we then accuse our parent (WMF) of
being
too harsh, mean and taking away something we like but do not deserve.
To be honest - until we as a community learn we are not the overlords,
the
masters, god of Wikimedia, we can work to building a real encyclopedia with awesome
feature
where are all work in a good environment and get on as a community and Foundation.
I am not saying the WMF is perfect and is not in the wrong; they
certainly
have some blame to take and I will come onto that shortly, but we can
not
blame the Foundation for revoking something we clearly do not deserve.
Erik, While I will say you have not been communicating stuff the best
you
can and this new user right was proxy deployed by Tim and an advocate
and
not your self - you mean well and I see this. I agree with everything
you
have done so far as a matter of fact.
Fabrice, Have you attempted to start any discussions with communities
in
exactly why they don't want Media Viewer and how exactly it causes so
much
dispute that it requires Erik to proxy intervene? It not, please do so.
In a short conclusion - I feel both parties have acted inappropriately
and
our bitching at each other does far than solve it. The WMF had to
implement
a new right and revoke dewiki's access to their site wide js page
because
of their refusal to accept what the WMF said and want to create a performance killer hack to 'fix it' at the cost of performance. Why did dewiki have to do this? The WMF refusing to disable Media Viewer. From
what
I see, the WMF have backed up by they refused to do this for Wikipedias
and
their compromise for Commons is acceptable. I have yet to see a valid reason why Media Viewer exactly makes Wikipedia go into a 'OMG UNUSABLE DISABLE IT FUCKING NOW OR I WILL' state. Media Viewer allows you to
view
and images without leaving the page - reducing load time for both users
and
the WMF. It is hardly the beginning if the end for images.
If we take a quick look at the statistics - 64 voted against Media
Viewer
on the English Wikipedia while 6kish users enabled it, this shows 1.1% consensus for disabling the extension in a whole.
I will not ramble on any more. I just ask the community to stop
bitching
at
the WMF and accept their decision. Until then - I fully support Erik
super
protecting every single js and CSS page on every wiki as most Sysop I
feel
are technically incompetent.
John Lewis
-- John Lewis _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
As long as we all stay friends! On 11 Aug 2014 00:57, "MF-Warburg" mfwarburg@googlemail.com wrote:
Oh sorry, that was totally not the intention. It must be the strange beer here at the Thistle Barbecue hotel. Am 11.08.2014 00:54 schrieb "Richard Symonds" < richard.symonds@wikimedia.org.uk>:
MF-Warburg, that came across as a bit rude... On 11 Aug 2014 00:29, "MF-Warburg" mfwarburg@googlemail.com wrote:
Your mail is embarrassing. If you think the foundation is like the parent of the community, you
don't
understand anything about the foundation nor the community. Am 11.08.2014 00:05 schrieb "John Lewis" johnflewis93@gmail.com:
The people who were actually responsible were the community. Erik was acting in a preventative role to prevent further disruption not
punish
administrators. The community. couldn't take no for an answer and
what
has
happened?
- Wheel/edit wars
- A new user right to prevent disruption
- A priviledge has been revoked on dewiki
- A user has been desysoped by the community for no reason on dewiki
And who are we blaming? Erik. Why? Because we are a bunch of stubborn children. We don't get what we want so we are kicking and screaming
to
get
it but in the end; we don't and we then accuse our parent (WMF) of
being
too harsh, mean and taking away something we like but do not deserve.
To be honest - until we as a community learn we are not the
overlords,
the
masters, god of Wikimedia, we can work to building a real encyclopedia with awesome
feature
where are all work in a good environment and get on as a community
and
Foundation.
I am not saying the WMF is perfect and is not in the wrong; they
certainly
have some blame to take and I will come onto that shortly, but we can
not
blame the Foundation for revoking something we clearly do not
deserve.
Erik, While I will say you have not been communicating stuff the best
you
can and this new user right was proxy deployed by Tim and an advocate
and
not your self - you mean well and I see this. I agree with everything
you
have done so far as a matter of fact.
Fabrice, Have you attempted to start any discussions with communities
in
exactly why they don't want Media Viewer and how exactly it causes so
much
dispute that it requires Erik to proxy intervene? It not, please do
so.
In a short conclusion - I feel both parties have acted
inappropriately
and
our bitching at each other does far than solve it. The WMF had to
implement
a new right and revoke dewiki's access to their site wide js page
because
of their refusal to accept what the WMF said and want to create a performance killer hack to 'fix it' at the cost of performance. Why
did
dewiki have to do this? The WMF refusing to disable Media Viewer.
From
what
I see, the WMF have backed up by they refused to do this for
Wikipedias
and
their compromise for Commons is acceptable. I have yet to see a valid reason why Media Viewer exactly makes Wikipedia go into a 'OMG
UNUSABLE
DISABLE IT FUCKING NOW OR I WILL' state. Media Viewer allows you to
view
and images without leaving the page - reducing load time for both
users
and
the WMF. It is hardly the beginning if the end for images.
If we take a quick look at the statistics - 64 voted against Media
Viewer
on the English Wikipedia while 6kish users enabled it, this shows
1.1%
consensus for disabling the extension in a whole.
I will not ramble on any more. I just ask the community to stop
bitching
at
the WMF and accept their decision. Until then - I fully support Erik
super
protecting every single js and CSS page on every wiki as most Sysop I
feel
are technically incompetent.
John Lewis
-- John Lewis _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On 11 August 2014 01:05, John Lewis wrote:
The people who were actually responsible were the community. Erik was acting in a preventative role to prevent further disruption not punish administrators.
Erik was acting in a manner that is totally disgraceful. He should have never used his force to revert DaB. The way that DaB. "implemented" the results of that RfC were incorrect, and the community of the German Wikipedia were perfectly able to revert his edits themselves once they realized what the effects were — without the need to involve the WMF at any point.
- A new user right to prevent disruption
Implemented without any community consultation whatsoever, on a global scale even though the problem was occurring only on the German Wikipedia.
- A user has been desysoped by the community for no reason on dewiki
Nothing of the sort has happened yet.
And who are we blaming? Erik. Why? Because we are a bunch of stubborn children. We don't get what we want so we are kicking and screaming to get it but in the end; we don't and we then accuse our parent (WMF) of being too harsh, mean and taking away something we like but do not deserve.
The only person that should be blamed by what happened is Erik. He is a WMF employee, he is an experienced Wikimedian, and he should have realized what would be the result of his actions.
Instead, he went ahead with his show of force, and escalated a situation that would have fixed itself in a matter of hours.
Even if MMV was disabled for a day, nothing would have happened. Now shit's happened, and it will be damn hard to regain the trust that was lost over this absurd stretching of muscles.
PS For what it's worth: I like MultimediaViewer. I use it, and I opposed the idea that a small community of volunteers can decide to disable it for anonymous editors. But what Erik has done is totally unacceptable, and contrary to the supposed cooperation between the WMF and the volunteer communities.
Lila,
I hope you are aware of the issues being described in this thread. Would you please state your views on this situation?
Pine On Aug 10, 2014 6:09 PM, "Tomasz W. Kozłowski" twkozlowski@gmail.com wrote:
On 11 August 2014 01:05, John Lewis wrote:
The people who were actually responsible were the community. Erik was acting in a preventative role to prevent further disruption not punish administrators.
Erik was acting in a manner that is totally disgraceful. He should have never used his force to revert DaB. The way that DaB. "implemented" the results of that RfC were incorrect, and the community of the German Wikipedia were perfectly able to revert his edits themselves once they realized what the effects were — without the need to involve the WMF at any point.
- A new user right to prevent disruption
Implemented without any community consultation whatsoever, on a global scale even though the problem was occurring only on the German Wikipedia.
- A user has been desysoped by the community for no reason on dewiki
Nothing of the sort has happened yet.
And who are we blaming? Erik. Why? Because we are a bunch of stubborn children. We don't get what we want so we are kicking and screaming to
get
it but in the end; we don't and we then accuse our parent (WMF) of being too harsh, mean and taking away something we like but do not deserve.
The only person that should be blamed by what happened is Erik. He is a WMF employee, he is an experienced Wikimedian, and he should have realized what would be the result of his actions.
Instead, he went ahead with his show of force, and escalated a situation that would have fixed itself in a matter of hours.
Even if MMV was disabled for a day, nothing would have happened. Now shit's happened, and it will be damn hard to regain the trust that was lost over this absurd stretching of muscles.
PS For what it's worth: I like MultimediaViewer. I use it, and I opposed the idea that a small community of volunteers can decide to disable it for anonymous editors. But what Erik has done is totally unacceptable, and contrary to the supposed cooperation between the WMF and the volunteer communities.
-- 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-request@lists.wikimedia.org?subject=unsubscribe
EXACTLY Who is this "community" of which we speak so glibly? Herein lies a large part of the problem. A few people claim to represent the many, based on "consensus" derived from a tiny sample. There is no one community, there are several, depending on who wants to make a point. Clique may be a better description in many cases. Peter Southwood.
-----Original Message----- From: wikimedia-l-bounces@lists.wikimedia.org [mailto:wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of John Lewis Sent: 11 August 2014 01:05 AM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you
The people who were actually responsible were the community. Erik was acting in a preventative role to prevent further disruption not punish administrators. The community. couldn't take no for an answer and what has happened?
* Wheel/edit wars * A new user right to prevent disruption * A priviledge has been revoked on dewiki * A user has been desysoped by the community for no reason on dewiki
And who are we blaming? Erik. Why? Because we are a bunch of stubborn children. We don't get what we want so we are kicking and screaming to get it but in the end; we don't and we then accuse our parent (WMF) of being too harsh, mean and taking away something we like but do not deserve.
To be honest - until we as a community learn we are not the overlords, the masters, god of Wikimedia, we can work to building a real encyclopedia with awesome feature where are all work in a good environment and get on as a community and Foundation.
I am not saying the WMF is perfect and is not in the wrong; they certainly have some blame to take and I will come onto that shortly, but we can not blame the Foundation for revoking something we clearly do not deserve.
Erik, While I will say you have not been communicating stuff the best you can and this new user right was proxy deployed by Tim and an advocate and not your self - you mean well and I see this. I agree with everything you have done so far as a matter of fact.
Fabrice, Have you attempted to start any discussions with communities in exactly why they don't want Media Viewer and how exactly it causes so much dispute that it requires Erik to proxy intervene? It not, please do so.
In a short conclusion - I feel both parties have acted inappropriately and our bitching at each other does far than solve it. The WMF had to implement a new right and revoke dewiki's access to their site wide js page because of their refusal to accept what the WMF said and want to create a performance killer hack to 'fix it' at the cost of performance. Why did dewiki have to do this? The WMF refusing to disable Media Viewer. From what I see, the WMF have backed up by they refused to do this for Wikipedias and their compromise for Commons is acceptable. I have yet to see a valid reason why Media Viewer exactly makes Wikipedia go into a 'OMG UNUSABLE DISABLE IT FUCKING NOW OR I WILL' state. Media Viewer allows you to view and images without leaving the page - reducing load time for both users and the WMF. It is hardly the beginning if the end for images.
If we take a quick look at the statistics - 64 voted against Media Viewer on the English Wikipedia while 6kish users enabled it, this shows 1.1% consensus for disabling the extension in a whole.
I will not ramble on any more. I just ask the community to stop bitching at the WMF and accept their decision. Until then - I fully support Erik super protecting every single js and CSS page on every wiki as most Sysop I feel are technically incompetent.
John Lewis
-- John Lewis _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4744 / Virus Database: 4007/8014 - Release Date: 08/11/14
On Sun, Aug 10, 2014 at 11:42 PM, Tomasz W. Kozłowski twkozlowski@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
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
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 svetlana@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-request@lists.wikimedia.org?subject=unsubscribe
On Sun, Aug 10, 2014 at 3:27 PM, Erik Moeller erik@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
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.
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
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 erik@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-request@lists.wikimedia.org?subject=unsubscribe
On Tue, Aug 12, 2014 at 10:19 AM, Craig Franklin cfranklin@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
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 erik@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-request@lists.wikimedia.org?subject=unsubscribe
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
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
On Wed, Aug 13, 2014 at 10:48 AM, svetlana svetlana@fastmail.com.au wrote:
On Wed, 13 Aug 2014, at 10:46, svetlana wrote:
On Tue, 12 Aug 2014, at 23:42, Romaine Wiki wrote:
That the community reacts the way it does now, is because they care very much about the site and they notice something is terrible going wrong on WMF side and too less is done to fix those problems/issues!
if the community was not so willing to use force (ie a js hack) against the other party
instead of talking properly
then the superprotect wouldn't exist at all
you seeing the problem there? whose problem is it? desire to act out of the blue instead of collaborating they didn't collaborate at all they added the js hack as if it was something urgent, that needs saving people from
i would only do this if someone added a virus into mv by mistake
this community thinks that its power structures allow to tromp onto other people
sysops aren't even held accountable they are elected once for an infinite term nobody reviews their contribution in position in power ever
this would surely be solved by making them elected on a 2-year term then re-elect
Hi svetlana, there are several large wikis which have sysop re-election policies; notably, German Wikipedia.
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
On Tue, Aug 12, 2014 at 5:46 PM, svetlana svetlana@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]]
On Wed, 13 Aug 2014, at 10:53, Pete Forsyth wrote:
On Tue, Aug 12, 2014 at 5:46 PM, svetlana svetlana@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.
On Wed, Aug 13, 2014 at 3:27 AM, svetlana svetlana@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 svetlana@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
On Thu, 14 Aug 2014, at 00:50, Pete Forsyth wrote:
On Wed, Aug 13, 2014 at 3:27 AM, svetlana svetlana@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.
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 svetlana@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-request@lists.wikimedia.org?subject=unsubscribe
2014-08-13 2:46 GMT+02:00 svetlana svetlana@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
Two points I have heard off list are that 1. While it may be that disabling MV by default for logged-in users can be done, disabling it for those not logged-in is effectively another major UI change which a study shows likely will make some of them leave and not return; 2. German Wikimedians are going inactive in protest.
Can someone confirm that both of those points are true? If so, this puts WMF in an even more difficult position. Perhaps the communities could be I persuaded to leave MV enabled by default for logged-out users and WMF would agree to release superprotection and disable MV by default for logged in users.
I fear that already volunteers may be leaving who will not return.
Pine
On Aug 12, 2014 6:42 AM, "Romaine Wiki" romaine.wiki@gmail.com wrote:
2014-08-13 2:46 GMT+02:00 svetlana svetlana@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-request@lists.wikimedia.org?subject=unsubscribe
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
On Wed, 13 Aug 2014, at 12:01, Romaine Wiki wrote:
2014-08-13 2:46 GMT+02:00 svetlana svetlana@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
On Wed, 13 Aug 2014, at 20:36, svetlana wrote:
On Wed, 13 Aug 2014, at 12:01, Romaine Wiki wrote:
2014-08-13 2:46 GMT+02:00 svetlana svetlana@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
I started drafting some thoughts on what /not to do/ in an RFC. These thoughts can be found here: https://meta.wikimedia.org/wiki/Requests_for_comment#Guidelines
13.08.2014, 01:46, "svetlana" svetlana@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
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
On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier marc@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]]
On 13 Aug 2014, at 21:12, Pete Forsyth peteforsyth@gmail.com wrote:
On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier marc@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
A Dutch politician once said in a presentation: 'Sometimes citizens come to us and say: You don't listen. Then I answer: Well, we do listen, but we also listen to the millions of inhabitants who have other opinions.'
Kind regards Ziko
2014-08-13 22:47 GMT+02:00 Michael Peel email@mikepeel.net:
On 13 Aug 2014, at 21:12, Pete Forsyth peteforsyth@gmail.com wrote:
On Wed, Aug 13, 2014 at 12:57 PM, Marc A. Pelletier marc@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-request@lists.wikimedia.org?subject=unsubscribe
On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth peteforsyth@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
On Wed, Aug 13, 2014 at 2:32 PM, Erik Moeller erik@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
On Thu, 14 Aug 2014, at 07:32, Erik Moeller wrote:
On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth peteforsyth@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,
[...]
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.
This is indeed true. Why does a global.js or whatever edit override user preference in the first place? I would expect user preferences to run after global.js, and set the onClick event back to what it should be (such as, something meaningful where a user has MV enabled).
svetlana
Hoi, The big question is not so much where and when things happen, the big question is who supports all the muck. There have been enough instances where changes to for instance common.js brought down servers.
This is not a zero sum game. It is not as if there are no consequences. I am certain that the "community" will not be happy when Wikipedia goes black for them or because of them. So when the totality goes down, who to blame and who is to fix it .. the "community"?? Will it blame itself or will it shrug it off like always? Or will it blame the WMF because "it" feels entitled?? Thanks, GerardM
On 14 August 2014 00:54, svetlana svetlana@fastmail.com.au wrote:
On Thu, 14 Aug 2014, at 07:32, Erik Moeller wrote:
On Wed, Aug 13, 2014 at 10:12 PM, Pete Forsyth peteforsyth@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,
[...]
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.
This is indeed true. Why does a global.js or whatever edit override user preference in the first place? I would expect user preferences to run after global.js, and set the onClick event back to what it should be (such as, something meaningful where a user has MV enabled).
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-request@lists.wikimedia.org?subject=unsubscribe
On Thu, Aug 14, 2014 at 1:41 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, The big question is not so much where and when things happen, the big question is who supports all the muck. There have been enough instances where changes to for instance common.js brought down servers.
Out of interest, when was the last time that a common.js change brought down the servers?
Ah, I believe when the Italian (?) Wikipedia started using my JS-based also-search-on-wikidata tool. A dependency JS file was hosted on Tools Labs, effectively DDOSing it to a halt. Moved file to en.wp, cache can handle it easily now.
So, not technically a Wikipedia server, but a Wikimedia server with lots'o'tools got unresponsive for a while. Last one I can think of.
Cheers, Magnus
On Thu, Aug 14, 2014 at 7:55 AM, John Mark Vandenberg jayvdb@gmail.com wrote:
On Thu, Aug 14, 2014 at 1:41 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, The big question is not so much where and when things happen, the big question is who supports all the muck. There have been enough instances where changes to for instance common.js brought down servers.
Out of interest, when was the last time that a common.js change brought down the servers?
-- John Vandenberg
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
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
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-g...
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,
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 erik@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-g...
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:
- The UI changes
- A subset of users is upset and organizes a poll/vote
- 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-request@lists.wikimedia.org?subject=unsubscribe
On 14 August 2014 13:56, David Cuenca dacuetu@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.
On Thu, Aug 14, 2014 at 3:35 PM, David Gerard dgerard@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
On 14 Aug 2014 14:50, "David Cuenca" dacuetu@gmail.com wrote:
On Thu, Aug 14, 2014 at 3:35 PM, David Gerard dgerard@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-request@lists.wikimedia.org?subject=unsubscribe
On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating chriskeatingwiki@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
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 dacuetu@gmail.com wrote:
On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating < chriskeatingwiki@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-request@lists.wikimedia.org?subject=unsubscribe
Gerard,
Citizenship in the digital world is more flexible than in the real world, but that doesn't mean that it doesn't exist or that it cannot be characterized. It is just a matter of providing a conceptual framework for defining rights, obligations, etc. and it avoids precisely that a person, or a group of people, or part or the community, or a sub-community, or any of the several communities, overtakes a decision-making process that belongs to the whole.
The terms of use can be considered a first approach to this tough problem, and it has many interesting keywords: "Part of our mission is to", "You are free to", "Under the following conditions", "With the understanding that". Unfortunately it just a "terms of use", not a "terms of community".
If such a thing came into being, there you could state: "Part of our mission is to promote a healthy collaboration between ourselves, you are free to represent yourself and others in our community, under the condition that they have provided you explicit consent and that you respect the interests of non-represented users, with the understanding that we work for the benefit of all humanity and not only for our own."
Cheers, Micru
On Fri, Aug 15, 2014 at 12:27 PM, Gerard Meijssen <gerard.meijssen@gmail.com
wrote:
Hoi, David, who is the community and how do you get members of the community recognise and respect the decisions it does not like that are taken on their behalf by "its" representatives. We do not have one community, we have many. The interests people aim for are diverse and all too often contradictory..
Really, in the past one part of the community insisted that it ALWAYS requires to be able to have the deciding influence for "its" project.. That clearly pains the picture for me. Thanks, GerardM
On 15 August 2014 10:17, David Cuenca dacuetu@gmail.com wrote:
On Thu, Aug 14, 2014 at 11:30 PM, Chris Keating < chriskeatingwiki@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-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Erik said:
We are very open to continuing the discussion about how the feature should be configured, how it should be improved, and how it should be integrated in the site experience
The message that is being given, though is, to quote Mathilda "I'm smart; you're dumb; I'm big, you're little; *I'm right, you're wrong*, and there's nothing you can do about it."
And this continues in this post. Assuming for example that those who do not opt-out "support" the media viewer.
Let me just make my position on the media viewer clear, since I am being uncharacteristically vocal on this subject. I am undecided, but I think it is probably a good thing. However when I hear respected communities saying there are functional and legal problems, I am inclined to believe them. I support therefore the "not-yet" faction. Personally I find it irritating (and at the same time potentially very cool), but I keep it on because I want to see what the bulk of our readers see.
So there are interconnecting layers of issues here - and I think they are clear, but I will lay them out in case we are talking at cross purposes.
1. Erik's actions. This sort of thing happens a lot on on-line communities (and elsewhere - see the Crimea!) and I did not get too excited about the socially inept blundering on en:WP. But to repeat the same script on German Wikipedia within a few days shows a lack of wisdom unbecoming to "Deputy Director".
2. The specific question of Media Viewer. That I believe can be resolved, and is all about "not yet", it should never have been allowed to cause drama. I would like to see some metrics for the value delivered by the Media Viewer, though, rather than "Flikr does it, it must be good". I am disappointed after a mostly unusable Visual Editor was released with content breaking bugs that another project is being forced down the same path - Erik's comment "That's no way to develop software" rings rather hollow in this context.
3. The ongoing question of software development. The WMF is supposed to "to empower and engage" the communities to disseminate content "effectively and globally." It is not supposed to run with its own agenda. Bugs and feature requests by the community are allowed to stand unattended for years - one was closed (WONTFIX) because of an off-hand comment made by a dev on a mailing list! Meanwhile "nice to have" features absorb apparently huge amounts of financial and staff resoruces. In the style re-work, extensive feedback was solicited and provided - and ignored when it didin't suit. (Notably a/b testing, mixing serif and sans, and using typefaces where the glyphs are more distinct)
4. The culture at the Foundation needs to be more focussed on collaborative and collegial work with the communities. The Foundation is an essential part of the Movement, if it did not exist it would be necessary to invent it. However it is not the senior partner, certainly not in terms of age or resource, and, due to the open licensing, not in content. To work effectively with the community the Foundation needs to consider the community as its customer, be responsive to its needs and wants, in this way it can deliver on its charitable objectives.
Note: This does not mean a namby-pamby relationship, but rather a robust one, where evidence based decisions can be made jointly and collegialy. Indeed one value add from having an organisation like the WMF is the resource to gather significant evidence on usability, readability, accessibility, clarity, interrogability and so forth.
On 14 August 2014 14:35, David Gerard dgerard@gmail.com wrote:
On 14 August 2014 13:56, David Cuenca dacuetu@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-request@lists.wikimedia.org?subject=unsubscribe
On 14 August 2014 16:27, Richard Farmbrough richard@farmbrough.co.uk wrote:
- The ongoing question of software development. The WMF is supposed to "to
empower and engage" the communities to disseminate content "effectively and globally." It is not supposed to run with its own agenda. Bugs and feature requests by the community are allowed to stand unattended for years
- one was closed (WONTFIX) because of an off-hand comment made by a dev on
a mailing list! Meanwhile "nice to have" features absorb apparently huge amounts of financial and staff resoruces. In the style re-work, extensive feedback was solicited and provided - and ignored when it didin't suit. (Notably a/b testing, mixing serif and sans, and using typefaces where the glyphs are more distinct)
Although I concur with Erik's and WMF's actions in this particular case (and I really don't see how it could have worked out any other way), it's worth noting for the general case that local communities *do* need to be able to add local enhancements to MediaWiki - because the developers, WMF and volunteer, simply don't scale. This has been observable even for simple administrative actions that happen to require shell use, let alone adding new functionality.
So locally-editable site JavaScript, for locally-important gadgets and so forth, is in fact something that's needed. This particularly applies to non-Wikipedia wikis that get no paid developer attention from WMF.
Of course, in an ideal world this would be later reviewed and possibly centralised. But blocking it in general will immediately make Wikimedia sites worse, not better, in important ways.
- d.
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
On 14 August 2014 20:27, Marc A. Pelletier marc@uberbox.org wrote:
On 08/14/2014 02:36 PM, David Gerard wrote:
So locally-editable site JavaScript, for locally-important gadgets and so forth, is in fact something that's needed.
That seems reasonable, but it's less clear to me that this should be bundled with / part of the 'editinterface' right, at least as it is currently managed (the ability to be able to change wording of system message is only related to being able to change javascript/CSS by way of hysterical raisins). Regardless of which process, in the end, is adopted to make management of sitewide customization to javascript etc, separating that from "normal" editinterface seems to me to be prerequisite.
This is true, but prerequisite to what? What I'm saying is that switching off local scripting in general until [unspecified condition] is met is going to be an immediately bad thing for every WMF wiki that doesn't get lots of WMF attention, which is most of them. So that's a thing that shouldn't be done just because admins on two wikis are acting like my daughter just before I withdraw her computer access.
- d.
On 14.08.2014 15:35, David Gerard wrote:
On 14 August 2014 13:56, David Cuenca dacuetu@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.
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
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
On Thu, 14 Aug 2014, at 23:35, David Gerard wrote:
On 14 August 2014 13:56, David Cuenca dacuetu@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
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 dacuetu@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
On 8/14/14, 3:35 PM, David Gerard wrote:
On 14 August 2014 13:56, David Cuenca dacuetu@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
On Aug 14, 2014 3:58 AM, "Erik Moeller" erik@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-g...
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:
- The UI changes
- A subset of users is upset and organizes a poll/vote
- 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 them and have that be okay; there isn't a magic word to speak. You must stop doing it.
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?
Then imagine how frustrating this situation is to people who aren't getting paid and donate their time. I get frustrated at my job, too, but that's why they pay people to do it. While I care deeply about Wikipedia and its mission, I will still eat and pay the rent tomorrow if I leave it today.
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.
A partner, yes, exactly. Not an authority, not a boss. If you want to be treated like a partner, ask, do not demand, and accept "no" as "no".
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.
Do a lot better than you have been. Thus far, the options on offer are only a "compromise" in that they will badly compromise local autonomy. Those will not be accepted, no matter how often they are floated.
Todd Allen
Erik
On Thu, Aug 14, 2014 at 5:32 AM, Erik Moeller erik@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
Ha, you'd think so! ;-)
In reality so far, the only known application was to lock the common.js at de.wikipedia, to prevent some crazy admin(s) from breaking the wiki.
Which incidentally shows that "will not break the wiki" really IS the minimal admin criterion, and is not trivial at all }:-)
sincerely, Kim
On Sun, Aug 10, 2014 at 11:19:27PM +1000, K. Peachey wrote:
Lets all welcome the new overlord Erik.
Add a new protection level called "superprotect" Assigned to nobody by default. Requested by Erik M??ller for the purposes of protecting pages such that sysop permissions are not sufficient to
edit them. Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e https://gerrit.wikimedia.org/r/#q,Idfa211257dbacc7623d42393257de1525ff01e9e,n,z
https://gerrit.wikimedia.org/r/#/c/153302/
Someone clearly can't take criticism of their projects well.
On Aug 11, 2014 7:11 AM, "Kim Bruning" kim@bruning.xs4all.nl wrote:
Ha, you'd think so! ;-)
In reality so far, the only known application was to lock the common.js at de.wikipedia, to prevent some crazy admin(s) from breaking the wiki.
Which incidentally shows that "will not break the wiki" really IS the minimal admin criterion, and is not trivial at all }:-)
sincerely, Kim
On Sun, Aug 10, 2014 at 11:19:27PM +1000, K. Peachey wrote:
Lets all welcome the new overlord Erik.
Add a new protection level called "superprotect" Assigned to nobody by default. Requested by Erik M??ller for the
purposes
of protecting pages such that sysop permissions are not sufficient to
edit them. Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e <
https://gerrit.wikimedia.org/r/#q,Idfa211257dbacc7623d42393257de1525ff01e9e,...
https://gerrit.wikimedia.org/r/#/c/153302/
Someone clearly can't take criticism of their projects well.
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
No one "broke the wiki" by disabling unwanted functions following a clear consensus. True breaking changes to those pages would be reverted by other admins before you could blink.
wikimedia-l@lists.wikimedia.org