On Tue, Aug 12, 2014 at 12:18 AM, Brian Wolff bawolff@gmail.com wrote:
Now, having observed that not only user Eloquence (aka Erik Moeller) himself engaged in the enforcement of <superprotect> right on de.wp [1] but soon after a workaround was published a change was deployed [2, 3] as counter measurement to block any possible interference can no longer be interpret as acting in good faith but rather strikes me as a form of oppression (or worst as censorship).
[Putting the purely mw dev hat on]
It was a bug in mediawiki, and thus it should be fixed. MediaWiki is used by many different groups and in general we [mw devs] do not judge people for how they use the software. If some non wmf entity reported the bug, it would still be fixed.
So dont complain that mw fixes a bug in how page protection. If you are unhappy with current events you should direct your anger at how the wmf decided to use hard security to enforce its dictates, not at the software for "working".
Sorry Brian, which bug are you referring to? Could you point me to a bug report?
Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page.
Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'.
Moreover the deployed technical change is useless due to design flaws. What was the goal of this change? Was it to prevent sysops injecting JavaScript that logged out user-agents execute? If that is the use-case, this patch is a very weak solution from an engineering perspective. It was rushed it into a production environment, and needed a follow up patch almost immediately. And the bug reports for this new functionality will surely roll in.
These patches only make it 'forbidden' to deactivate the MediaViewer. They don't prevent it. These patches only introduce a new policy, signalling a new era, and make it technically more challenging to bypass that new policy. The policy written says "Sysops are not allowed to inject JavaScript into the reader's user-agent which interferes with WMF's favoured features." It is still possible, but the only thing that is stopping de.wp sysops from deactivating the MediaViewer some other way is that the WMF has demonstrated it will make drastic changes to the MediaWiki configuration to take away capabilities from their community. Should the community work-around this change, they are fairly confident that the WMF will desysop whoeverdoes it, or more configuration changes and superprotection will occur.
-- John Vandenberg
And what happens when said admin is overwhelmingly reelected by the community?
This is not the way forward. WMF can't continue to treat its volunteers in this manner. On Aug 11, 2014 12:01 PM, "John Mark Vandenberg" jayvdb@gmail.com wrote:
On Tue, Aug 12, 2014 at 12:18 AM, Brian Wolff bawolff@gmail.com wrote:
Now, having observed that not only user Eloquence (aka Erik Moeller) himself engaged in the enforcement of <superprotect> right on de.wp [1] but soon after a workaround was published a change was deployed [2, 3] as counter measurement to block any possible interference can no longer be interpret as acting in good faith but rather strikes me as a form of oppression (or worst as censorship).
[Putting the purely mw dev hat on]
It was a bug in mediawiki, and thus it should be fixed. MediaWiki is used by many different groups and in general we [mw devs] do not judge people for how they use the software. If some non wmf entity reported the bug,
it
would still be fixed.
So dont complain that mw fixes a bug in how page protection. If you are unhappy with current events you should direct your anger at how the wmf decided to use hard security to enforce its dictates, not at the software for "working".
Sorry Brian, which bug are you referring to? Could you point me to a bug report?
Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page.
Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'.
Moreover the deployed technical change is useless due to design flaws. What was the goal of this change? Was it to prevent sysops injecting JavaScript that logged out user-agents execute? If that is the use-case, this patch is a very weak solution from an engineering perspective. It was rushed it into a production environment, and needed a follow up patch almost immediately. And the bug reports for this new functionality will surely roll in.
These patches only make it 'forbidden' to deactivate the MediaViewer. They don't prevent it. These patches only introduce a new policy, signalling a new era, and make it technically more challenging to bypass that new policy. The policy written says "Sysops are not allowed to inject JavaScript into the reader's user-agent which interferes with WMF's favoured features." It is still possible, but the only thing that is stopping de.wp sysops from deactivating the MediaViewer some other way is that the WMF has demonstrated it will make drastic changes to the MediaWiki configuration to take away capabilities from their community. Should the community work-around this change, they are fairly confident that the WMF will desysop whoeverdoes it, or more configuration changes and superprotection will occur.
-- John Vandenberg
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page.
This is false.
Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'.
Most of what MZMcBride posted there has nothing to do with actually breaking superprotection. Editing a page that isn't superprotected isn't a break in the protection feature itself, for example. Nor is hacking people's accounts.
On Tue, Aug 12, 2014 at 3:49 AM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page.
This is false.
Care to explain?
Was this functionality was ever supported by MediaWiki core? Could you point me towards some documentation?
Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'.
Most of what MZMcBride posted there has nothing to do with actually breaking superprotection. Editing a page that isn't superprotected isn't a break in the protection feature itself, for example.
Of course it is. It isnt a 'feature' until it actually works at the released product level. Rushing component level hardening changes into production, when everyone knows how to work around the new 'hardened' code, it very bad change management. It likely introduces unforeseen bugs, for no actual gain.
-- John Vandenberg
On Mon, Aug 11, 2014 at 6:54 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
On Tue, Aug 12, 2014 at 3:49 AM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
Before this, there was no expectation that a page could be protected such that sysops could not alter the content of the superprotected page.
This is false.
Care to explain?
https://www.mediawiki.org/w/index.php?title=Manual:$wgRestrictionLevels&... shows that protection levels that prevent sysops from editing were considered as far back as 3 April 2012, for example.
Most of what MZMcBride posted there has nothing to do with actually breaking superprotection. Editing a page that isn't superprotected isn't
a
break in the protection feature itself, for example.
Of course it is. It isnt a 'feature' until it actually works at the released product level.
You appear to be confusing superprotection with something else, likely the much larger concept of preventing JS hacks to disable MediaViewer.
On 11/08/14 21:49, Brad Jorsch (Anomie) wrote:
On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'.
Most of what MZMcBride posted there has nothing to do with actually breaking superprotection. Editing a page that isn't superprotected isn't a break in the protection feature itself, for example. Nor is hacking people's accounts.
Right, we (devs) weren't asked to prevent admins from disabling MediaViewer, we were only asked to make it possible to protect pages in the MediaWiki namespace such that ordinary admins couldn't edit them. I understood the feature request as introducing a more gradual escalation path, it wasn't an attempt to directly achieve a particular goal.
John Mark Vandenberg wrote:
These patches only introduce a new policy, signalling a new era, and make it technically more challenging to bypass that new policy. The policy written says "Sysops are not allowed to inject JavaScript into the reader's user-agent which interferes with WMF's favoured features."
Erik was very clear about this policy change in his first email to this thread.
-- Tim Starling
Tim, I don't believe the issue was a failure to be clear. The problem is the content of the change and its heavy handed enforcement.
Super protection either should not exist, or like suppression, it should be used only by stewards and community approved functionaries. On Aug 11, 2014 5:49 PM, "Tim Starling" tstarling@wikimedia.org wrote:
On 11/08/14 21:49, Brad Jorsch (Anomie) wrote:
On Mon, Aug 11, 2014 at 2:01 PM, John Mark Vandenberg jayvdb@gmail.com wrote:
Now, the devs/ops have attempted to introduce that capability, and the new functionality is very likely riddled with holes, some of which MZMcBride has suggested in the thread 'Options for the German Wikipedia'.
Most of what MZMcBride posted there has nothing to do with actually breaking superprotection. Editing a page that isn't superprotected isn't
a
break in the protection feature itself, for example. Nor is hacking people's accounts.
Right, we (devs) weren't asked to prevent admins from disabling MediaViewer, we were only asked to make it possible to protect pages in the MediaWiki namespace such that ordinary admins couldn't edit them. I understood the feature request as introducing a more gradual escalation path, it wasn't an attempt to directly achieve a particular goal.
John Mark Vandenberg wrote:
These patches only introduce a new policy, signalling a new era, and make it technically more challenging to bypass that new policy. The policy written says "Sysops are not allowed to inject JavaScript into the reader's user-agent which interferes with WMF's favoured features."
Erik was very clear about this policy change in his first email to this thread.
-- Tim Starling
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 Aug 11, 2014 5:49 PM, "Tim Starling" tstarling@wikimedia.org wrote:
On 11/08/14 21:49, Brad Jorsch (Anomie) wrote: John Mark Vandenberg wrote:
These patches only introduce a new policy, signalling a new era, and make it technically more challenging to bypass that new policy. The policy written says "Sysops are not allowed to inject JavaScript into the reader's user-agent which interferes with WMF's favoured features."
Erik was very clear about this policy change in his first email to this thread.
-- Tim Starling
On Tue, 12 Aug 2014, at 10:13, Todd Allen wrote:
Tim, I don't believe the issue was a failure to be clear. The problem is the content of the change and its heavy handed enforcement.
Super protection either should not exist, or like suppression, it should be used only by stewards and community approved functionaries.
If we accept the policy in principle, I don't care who enforces such policy, that be community or WMF. Such policy does not go against community entirely, unless WMF shows a will to reject community patches related to issues which community finds important. Whether or not this is the case, I don't care; it's a website in their hands and they're welcome to shut it off without notice, or to experiment at leisure.
The time for community to get involved in development, and create all the necessary structures required to support such development, is long overdue.
svetlana
On 12.08.2014 02:26, svetlana wrote:
If we accept the policy in principle, I don't care who enforces such policy, that be community or WMF. Such policy does not go against community entirely, unless WMF shows a will to reject community patches related to issues which community finds important. Whether or not this is the case, I don't care; it's a website in their hands and they're welcome to shut it off without notice, or to experiment at leisure.
svetlana
Whoever believes that an administration of a crowdsourcing website can do whatever they want just because they are running the website should recollect what recently happened to Internet Brands and Wikitravel.
Cheers Yaroslav
As one has been there, done that, I would like to point out that there is an order of magnitude difference between Internet Brands and WMF. Cheers, Peter
-----Original Message----- From: wikimedia-l-bounces@lists.wikimedia.org [mailto:wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of Yaroslav M. Blanter Sent: 12 August 2014 02:00 PM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you
On 12.08.2014 02:26, svetlana wrote:
If we accept the policy in principle, I don't care who enforces such policy, that be community or WMF. Such policy does not go against community entirely, unless WMF shows a will to reject community patches related to issues which community finds important. Whether or not this is the case, I don't care; it's a website in their hands and they're welcome to shut it off without notice, or to experiment at leisure.
svetlana
Whoever believes that an administration of a crowdsourcing website can do whatever they want just because they are running the website should recollect what recently happened to Internet Brands and Wikitravel.
Cheers Yaroslav
_______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4744 / Virus Database: 4007/8020 - Release Date: 08/11/14
Also, 118 people (190 vs. 72 votes in the "poll" [1] on German Wikipedia) are not "the community". They are a small part of the community.
The people who would profit [2] from the Media Viewer as a default feature were not consulted.
Cheers, Magnus
[1] https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Medienbetrachter [2] Value of ""profit" TBD
On Tue, Aug 12, 2014 at 1:13 PM, Peter Southwood < peter.southwood@telkomsa.net> wrote:
As one has been there, done that, I would like to point out that there is an order of magnitude difference between Internet Brands and WMF. Cheers, Peter
-----Original Message----- From: wikimedia-l-bounces@lists.wikimedia.org [mailto: wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of Yaroslav M. Blanter Sent: 12 August 2014 02:00 PM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you
On 12.08.2014 02:26, svetlana wrote:
If we accept the policy in principle, I don't care who enforces such policy, that be community or WMF. Such policy does not go against community entirely, unless WMF shows a will to reject community patches related to issues which community finds important. Whether or not this is the case, I don't care; it's a website in their hands and they're welcome to shut it off without notice, or to experiment at leisure.
svetlana
Whoever believes that an administration of a crowdsourcing website can do whatever they want just because they are running the website should recollect what recently happened to Internet Brands and Wikitravel.
Cheers Yaroslav
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4744 / Virus Database: 4007/8020 - Release Date: 08/11/14
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
magnus, a vote always has 3 options. * i am for it * i am against it * i can live with the outcome of the vote
so i did not vote. because i can live with both. but i do respect the vote. i do respect admin decisions, i even voted for some admins.
at the end it is very simple. the one who produces software has a conflict of interest. so this person or organisation is not in a good position to decide when it is used.
wmf, its employees and voluntary officers need to be exemplary with respect to conflicts of interest, imo. always. errors are allowed as well as excuses of course.
magnus you said you are not happy with media viewer. and you always produce software people like. what should they improve?
rupert Am 12.08.2014 14:45 schrieb "Magnus Manske" magnusmanske@googlemail.com:
Also, 118 people (190 vs. 72 votes in the "poll" [1] on German Wikipedia) are not "the community". They are a small part of the community.
The people who would profit [2] from the Media Viewer as a default feature were not consulted.
Cheers, Magnus
[1] https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Medienbetrachter [2] Value of ""profit" TBD
On Tue, Aug 12, 2014 at 1:13 PM, Peter Southwood < peter.southwood@telkomsa.net> wrote:
As one has been there, done that, I would like to point out that there is an order of magnitude difference between Internet Brands and WMF. Cheers, Peter
-----Original Message----- From: wikimedia-l-bounces@lists.wikimedia.org [mailto: wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of Yaroslav M.
Blanter
Sent: 12 August 2014 02:00 PM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] Superprotect user right, Comming to a wiki
near
you
On 12.08.2014 02:26, svetlana wrote:
If we accept the policy in principle, I don't care who enforces such policy, that be community or WMF. Such policy does not go against community entirely, unless WMF shows a will to reject community patches related to issues which community finds important. Whether or not this is the case, I don't care; it's a website in their hands and they're welcome to shut it off without notice, or to experiment at leisure.
svetlana
Whoever believes that an administration of a crowdsourcing website can do whatever they want just because they are running the website should recollect what recently happened to Internet Brands and Wikitravel.
Cheers Yaroslav
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4744 / Virus Database: 4007/8020 - Release Date: 08/11/14
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 12/08/2014 15:19, rupert THURNER wrote:
magnus, a vote always has 3 options.
- i am for it
- i am against it
- i can live with the outcome of the vote
No, there are other options. * I didn't know the poll was happening * I just want to get on with editing / reading Wikipedia (or sister project) and are sick of the constant bickering. * I am happy for the Foundation (after consultation) to decide on what features to have on the project it is entrusted in running.
at the end it is very simple. the one who produces software has a conflict of interest. so this person or organisation is not in a good position to decide when it is used.
And the editor community are not in the best position to decide what are the best features for the (overlapping but much much larger) reader community either.
Katie
On Tue, Aug 12, 2014 at 3:19 PM, rupert THURNER rupert.thurner@gmail.com wrote:
magnus, a vote always has 3 options.
- i am for it
- i am against it
- i can live with the outcome of the vote
<nitpick> You mean "do not particularly care about it", surely? That you can live with the outcome of a vote, whatever outcome that is, is a fundamental principle of democracy, not a voting option. </nitpick>
so i did not vote. because i can live with both. but i do respect the vote. i do respect admin decisions, i even voted for some admins.
at the end it is very simple. the one who produces software has a conflict of interest. so this person or organisation is not in a good position to decide when it is used.
wmf, its employees and voluntary officers need to be exemplary with respect to conflicts of interest, imo. always. errors are allowed as well as excuses of course.
There needs to be a balance between the wishes of (some members of) the logged-in community, the (otherwise silent) majority of readers, and the WMF.
German Wikipedia had 1.1 billion page views in June [1]. ~300 votes (~2/3 against MediaViewer) do not represent the readers, IMHO.
The Foundation is tasked with managing the hardware and software that runs Wikipedia. On Wikimania, several remarks were made about how outdated Wikipedia appears. WMF tries to improve that situation. No, MediaViewer is not perfect. What software is? When is it "perfect" enough to go live by default? WMF should have a say there.
magnus you said you are not happy with media viewer. and you always produce software people like. what should they improve?
Like many other "old hands", it seems to get in the way of my workflow. Not an issue for me, as long as I can turn it off.
It's probably fine for "modern" viewing, although it's hard to guess that you get to the file page via the little Commons icon for people who (in all likelihood) have never seen that icon, or visited Commons.
Cheers, Magnus
[1] https://stats.wikimedia.org/EN/SummaryDE.htm
rupert Am 12.08.2014 14:45 schrieb "Magnus Manske" magnusmanske@googlemail.com:
Also, 118 people (190 vs. 72 votes in the "poll" [1] on German Wikipedia) are not "the community". They are a small part of the community.
The people who would profit [2] from the Media Viewer as a default
feature
were not consulted.
Cheers, Magnus
[1] https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Medienbetrachter [2] Value of ""profit" TBD
On Tue, Aug 12, 2014 at 1:13 PM, Peter Southwood < peter.southwood@telkomsa.net> wrote:
As one has been there, done that, I would like to point out that there
is
an order of magnitude difference between Internet Brands and WMF. Cheers, Peter
-----Original Message----- From: wikimedia-l-bounces@lists.wikimedia.org [mailto: wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of Yaroslav M.
Blanter
Sent: 12 August 2014 02:00 PM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] Superprotect user right, Comming to a wiki
near
you
On 12.08.2014 02:26, svetlana wrote:
If we accept the policy in principle, I don't care who enforces such policy, that be community or WMF. Such policy does not go against community entirely, unless WMF shows a will to reject community patches related to issues which community finds important. Whether or not this is the case, I don't care; it's a website in their hands and they're welcome to shut it off without notice, or to experiment at leisure.
svetlana
Whoever believes that an administration of a crowdsourcing website can
do
whatever they want just because they are running the website should recollect what recently happened to Internet Brands and Wikitravel.
Cheers Yaroslav
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4744 / Virus Database: 4007/8020 - Release Date:
08/11/14
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
2014-08-12 16:57 GMT+02:00 Magnus Manske magnusmanske@googlemail.com:
On Tue, Aug 12, 2014 at 3:19 PM, rupert THURNER rupert.thurner@gmail.com wrote:
so i did not vote. because i can live with both. but i do respect the
vote.
i do respect admin decisions, i even voted for some admins.
at the end it is very simple. the one who produces software has a
conflict
of interest. so this person or organisation is not in a good position to decide when it is used.
wmf, its employees and voluntary officers need to be exemplary with
respect
to conflicts of interest, imo. always. errors are allowed as well as excuses of course.
There needs to be a balance between the wishes of (some members of) the logged-in community, the (otherwise silent) majority of readers, and the WMF.
True
German Wikipedia had 1.1 billion page views in June [1]. ~300 votes (~2/3
against MediaViewer) do not represent the readers, IMHO.
I think it is more relevant to look at the number of unique visitors, in stead of the 1.1 billion page views.
The Foundation is tasked with managing the hardware and software that runs
Wikipedia. On Wikimania, several remarks were made about how outdated Wikipedia appears. WMF tries to improve that situation. No, MediaViewer is not perfect. What software is? When is it "perfect" enough to go live by default? WMF should have a say there.
I agree that WMF should have a say, but how it is done now is certainly not the way WMF should handle it. Also I think it would be good to define for future cases how such situations should be handled. If a community has a strong oppose in something, such situation should be considered more carefully and be handled with more care. A community can't represent all readers, but they are themselves readers too who feel to have a large responsibility to the readers. They usually have valid arguments and considerations which should be taken more seriously. We all are on the same ship with the same vision on the horizon, with the same goals.
Romaine
On Tue, Aug 12, 2014 at 4:21 PM, Romaine Wiki romaine.wiki@gmail.com wrote:
2014-08-12 16:57 GMT+02:00 Magnus Manske magnusmanske@googlemail.com:
On Tue, Aug 12, 2014 at 3:19 PM, rupert THURNER <
rupert.thurner@gmail.com>
wrote:
so i did not vote. because i can live with both. but i do respect the
vote.
i do respect admin decisions, i even voted for some admins.
at the end it is very simple. the one who produces software has a
conflict
of interest. so this person or organisation is not in a good position
to
decide when it is used.
wmf, its employees and voluntary officers need to be exemplary with
respect
to conflicts of interest, imo. always. errors are allowed as well as excuses of course.
There needs to be a balance between the wishes of (some members of) the logged-in community, the (otherwise silent) majority of readers, and the WMF.
True
German Wikipedia had 1.1 billion page views in June [1]. ~300 votes (~2/3
against MediaViewer) do not represent the readers, IMHO.
I think it is more relevant to look at the number of unique visitors, in stead of the 1.1 billion page views.
I agree, but I couldn't find that number on the report card, so I used the next best thing. Assuming 100 page views per visitor would give 10M visitors. 80M people in Germany alone, so probably not too far off. That would mean that 0.003% of visitors voted, and 0.002% voted against MediaViewer, with a ~0.001% "edge".
The Foundation is tasked with managing the hardware and software that runs
Wikipedia. On Wikimania, several remarks were made about how outdated Wikipedia appears. WMF tries to improve that situation. No, MediaViewer
is
not perfect. What software is? When is it "perfect" enough to go live by default? WMF should have a say there.
I agree that WMF should have a say, but how it is done now is certainly not the way WMF should handle it. Also I think it would be good to define for future cases how such situations should be handled. If a community has a strong oppose in something, such situation should be considered more carefully and be handled with more care. A community can't represent all readers, but they are themselves readers too who feel to have a large responsibility to the readers. They usually have valid arguments and considerations which should be taken more seriously. We all are on the same ship with the same vision on the horizon, with the same goals.
Yes, it could have been handled better. Actually, just saying "this is coming by default, you can turn it off individually" /before/ the "vote" was initiated would have been much clearer, and I don't think it would have caused as much uproar as we have now. It also could have helped to focus the community on finding and reporting bugs, which might have lead to earlier improvements to the software.
And yes, the community should have a say, but this is a rather technical issue, even if it is an interface change. The community is, and always has been, very much in charge of content and editorial policies, beyond the pillars.
Finally, I think that an open and detailed description by the WMF about what, exactly, happened, and why MediaViewer is pushed against the wishes of a small but vocal group, would help a lot to smooth the waves.
Cheers, Magnus
On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske magnusmanske@googlemail.com wrote:
It's probably fine for "modern" viewing, although it's hard to guess that you get to the file page via the little Commons icon for people who (in all likelihood) have never seen that icon, or visited Commons.
Dear Magnus,
Thanks as always for your thoughtful comments. It was great to see you at Wikimania again, too. :)
Indeed, the icon to the File: page is currently very opaque. We're preparing for a round of possible changes to the viewing experience, potentially including - moving caption above the fold so readers don't have to hunt for it - moving disable action above-the-fold - potentially eliminating the below-the-fold panel entirely - emphasizing the File: page more prominently as the canonical source of metadata - separating out download/use actions more clearly
These changes will need to be carefully tested/validated. If you want to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please note that anything but the basic view experience is placeholder right now (as is the "Details" icon etc.), and the caption-above-the-fold is not implemented yet. We've looked at some of this with folks at Wikimania, and the community feedback there was very positive. But like I said, give us a bit more time on this.
In general, Giles made a good point at the multimedia roundtable at Wikimania: Historically, product development at WMF was so slow that calling for an immediate rollback of a new thing that doesn't work quite perfectly yet for everyone was a bit more appropriate. Nowadays we really can push out a new release in a few weeks, and the constant turning on/off is not helpful for anyone, especially for a feature like this that can easily be disabled by anyone who doesn't like it.
In answer to your query regarding how we communicated about this, please note that we posted the following at the beginning of the poll: https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbild...
Translation: The Wikimedia Foundation reserves the right to make a final decision about the standard configuration of software features in Wikimedia projects (see [[m:Limits to configuration changes]]). For the avoidance of doubt: This includes hacks implemented via the MediaWiki: namespace. Of course want to find a solution that is acceptable for readers and editors. We are open to the idea that the default setting for logged in users and logged out users should be different.
- - -
I don't think we could have been any clearer that a MediaWiki: disable hack would not be acceptable -- we said so from the start. We did indeed agree to implement a different default configuration for logged in users for Wikimedia Commons, given the unique nature of the project. We would strongly advise against doing the same for logged in users on Wikipedia projects, and decided not to do so in response to the vote on de.wp. While settling on a compromise like this may be tempting in the short term to de-escalate matters, let's only do it if it's truly the right thing to do, not for political reasons alone.
Erik
On Tue, Aug 12, 2014 at 5:26 PM, Erik Moeller erik@wikimedia.org wrote:
These changes will need to be carefully tested/validated. If you want to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please note that anything but the basic view experience is placeholder right now (as is the "Details" icon etc.), and the caption-above-the-fold is not implemented yet. We've looked at some of this with folks at Wikimania, and the community feedback there was very positive. But like I said, give us a bit more time on this.
This looks much better! (though it appears to have problems with PNGs...)
In answer to your query regarding how we communicated about this, please note that we posted the following at the beginning of the poll:
https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbild...
Thanks Erik, I somehow missed this. It is indeed ample notification.
Cheers, Magnus
On Tue, Aug 12, 2014 at 11:12 AM, Magnus Manske <magnusmanske@googlemail.com
wrote:
On Tue, Aug 12, 2014 at 5:26 PM, Erik Moeller erik@wikimedia.org wrote:
These changes will need to be carefully tested/validated. If you want to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please note that anything but the basic view experience is placeholder right now (as is the "Details" icon etc.), and the caption-above-the-fold is not implemented yet. We've looked at some of this with folks at Wikimania, and the community feedback there was very positive. But like I said, give us a bit more time on this.
This looks much better! (though it appears to have problems with PNGs...)
It does look better, and addresses *some* of the many major problems with the Media Viewer. But there are still show-stopper problems. Iterating while badly broken software is still deployed to many millions of readers is a bad practice, though, so for the moment I'll leave it at that.
Erik, as I have said before -- your request for a bit more time would be much better received if you would simply revert the change, as per consensus on 3 major projects, while you work to fix this broken software. It's a very simple and non-dramatic option you have had available the entire time.
Pete [[User:Peteforsyth]]
It is very disheartening to see that active members of the community have been Borged by the Foundation, and all tell the same story, albeit with different levels of enthusiasm.
Quite possibly there are issues over configuration pages, but to implement a super-protection feature *in the middle of a dispute* is ham-fisted at best, and a blatant power grab at worst.
Many less extreme alternatives exist, and good reasons for maintaining the *status quo* are also not hard to find.
Since this is undoubtedly a fire, the fire-fighting steps that should be taken immediately are:
1 Un-super-protect the page.
2 Apologise to the community
3 Give an undertaking not to use superprotect except in a clear emergency (though I can't think of one that would justify its use) - or disable the feature
4 Engage with the community to discuss superprotect.
Once this discussion is concluded, then and only then should a discussion about media-viewer be entered into, meanwhile the community consensus should be respected.
And Magnus - saying X number of people does not represent the community is all very well, provided that there is a mechanism for gaining a more representative sample - and it has been used.
All the best, Rich Farmbrough
On 12 August 2014 19:12, Magnus Manske magnusmanske@googlemail.com wrote:
On Tue, Aug 12, 2014 at 5:26 PM, Erik Moeller erik@wikimedia.org wrote:
These changes will need to be carefully tested/validated. If you want to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please note that anything but the basic view experience is placeholder right now (as is the "Details" icon etc.), and the caption-above-the-fold is not implemented yet. We've looked at some of this with folks at Wikimania, and the community feedback there was very positive. But like I said, give us a bit more time on this.
This looks much better! (though it appears to have problems with PNGs...)
In answer to your query regarding how we communicated about this, please note that we posted the following at the beginning of the poll:
https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbild...
Thanks Erik, I somehow missed this. It is indeed ample notification.
Cheers, Magnus _______________________________________________ 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 6:26 PM, Erik Moeller erik@wikimedia.org wrote:
On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske magnusmanske@googlemail.com wrote:
Like many other "old hands", it seems to get in the way of my workflow. Not an issue for me, as long as I can turn it off.
hehe, i suppose investing a million $$ to get you turning it off because it is in your way is probably not the goal :)
It's probably fine for "modern" viewing, although it's hard to guess that you get to the file page via the little Commons icon for people who (in all likelihood) have never seen that icon, or visited Commons.
Indeed, the icon to the File: page is currently very opaque. We're preparing for a round of possible changes to the viewing experience, potentially including
- moving caption above the fold so readers don't have to hunt for it
- moving disable action above-the-fold
- potentially eliminating the below-the-fold panel entirely
- emphasizing the File: page more prominently as the canonical source
of metadata
- separating out download/use actions more clearly
These changes will need to be carefully tested/validated. If you want to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please
magnus, do these changes make you turn it on again? if not, what would need to be better?
i think there is two kinds of feedback. (1) technical / feature / workflow issues. like "i cannot tag easy", "esc leaves mediaviewer instead of fullscreen", "browser zoom (ctrl-/+) does not work". "X takes one click more now". i d love this to be taken into account.
while i find design issues more difficult. the whole user experience needs, at least imo, consistency. tinkering here and there may quite heavily break that. better would be to encourage getting alternative full designs. if this would include how to clean the commons page ... but that might be too much :)
rupert
On Wed, Aug 13, 2014 at 6:51 AM, rupert THURNER rupert.thurner@gmail.com wrote:
On Tue, Aug 12, 2014 at 6:26 PM, Erik Moeller erik@wikimedia.org wrote:
On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske magnusmanske@googlemail.com wrote:
Like many other "old hands", it seems to get in the way of my workflow.
Not
an issue for me, as long as I can turn it off.
hehe, i suppose investing a million $$ to get you turning it off because it is in your way is probably not the goal :)
Well, for a million $$ MediaViewer would be slightly overpriced ;-)
It's probably fine for "modern" viewing, although it's hard to guess
that
you get to the file page via the little Commons icon for people who (in
all
likelihood) have never seen that icon, or visited Commons.
Indeed, the icon to the File: page is currently very opaque. We're preparing for a round of possible changes to the viewing experience, potentially including
- moving caption above the fold so readers don't have to hunt for it
- moving disable action above-the-fold
- potentially eliminating the below-the-fold panel entirely
- emphasizing the File: page more prominently as the canonical source
of metadata
- separating out download/use actions more clearly
These changes will need to be carefully tested/validated. If you want to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please
magnus, do these changes make you turn it on again? if not, what would need to be better?
I think this is a non-issue. It took one click to get to the image page; now it takes two. That's my main "problem" with it. As I said, I'm not the target audience for this. I hope.
i think there is two kinds of feedback. (1) technical / feature / workflow issues. like "i cannot tag easy", "esc leaves mediaviewer instead of fullscreen", "browser zoom (ctrl-/+) does not work". "X takes one click more now". i d love this to be taken into account.
while i find design issues more difficult. the whole user experience needs, at least imo, consistency. tinkering here and there may quite heavily break that. better would be to encourage getting alternative full designs. if this would include how to clean the commons page ... but that might be too much :)
rupert
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Am 13.08.2014 15:56 schrieb "Magnus Manske" magnusmanske@googlemail.com:
On Wed, Aug 13, 2014 at 6:51 AM, rupert THURNER rupert.thurner@gmail.com wrote:
On Tue, Aug 12, 2014 at 6:26 PM, Erik Moeller erik@wikimedia.org
wrote:
On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske magnusmanske@googlemail.com wrote:
It's probably fine for "modern" viewing, although it's hard to guess
that
you get to the file page via the little Commons icon for people who
(in
all
likelihood) have never seen that icon, or visited Commons.
Indeed, the icon to the File: page is currently very opaque. We're preparing for a round of possible changes to the viewing experience, potentially including
- moving caption above the fold so readers don't have to hunt for it
- moving disable action above-the-fold
- potentially eliminating the below-the-fold panel entirely
- emphasizing the File: page more prominently as the canonical source
of metadata
- separating out download/use actions more clearly
These changes will need to be carefully tested/validated. If you want to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please
magnus, do these changes make you turn it on again? if not, what would
need
to be better?
I think this is a non-issue. It took one click to get to the image page; now it takes two. That's my main "problem" with it. As I said, I'm not the target audience for this. I hope.
to give back the one click experience one would need two entry points. a tab or a toolbox link to start mediaviewer, and standard behavior on the images. for one link more in the gui everybody would be happy?
rupert
On Wed, Aug 13, 2014 at 6:20 PM, rupert THURNER rupert.thurner@gmail.com wrote:
Am 13.08.2014 15:56 schrieb "Magnus Manske" magnusmanske@googlemail.com:
On Wed, Aug 13, 2014 at 6:51 AM, rupert THURNER <
rupert.thurner@gmail.com>
wrote:
On Tue, Aug 12, 2014 at 6:26 PM, Erik Moeller erik@wikimedia.org
wrote:
On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske magnusmanske@googlemail.com wrote:
It's probably fine for "modern" viewing, although it's hard to guess
that
you get to the file page via the little Commons icon for people who
(in
all
likelihood) have never seen that icon, or visited Commons.
Indeed, the icon to the File: page is currently very opaque. We're preparing for a round of possible changes to the viewing experience, potentially including
- moving caption above the fold so readers don't have to hunt for it
- moving disable action above-the-fold
- potentially eliminating the below-the-fold panel entirely
- emphasizing the File: page more prominently as the canonical source
of metadata
- separating out download/use actions more clearly
These changes will need to be carefully tested/validated. If you want to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please
magnus, do these changes make you turn it on again? if not, what would
need
to be better?
I think this is a non-issue. It took one click to get to the image page; now it takes two. That's my main "problem" with it. As I said, I'm not the target audience for this. I hope.
to give back the one click experience one would need two entry points. a tab or a toolbox link to start mediaviewer, and standard behavior on the images. for one link more in the gui everybody would be happy?
Thanks for trying, but I wouldn't like to have some "click confusion" to be added on my part. This is not really the issue that's being discussed here. Some people felt that MediaViewer is too buggy to be default right now. WMF disagreed. Disagreement escalated. This needs to calm down again. A quick single-point tech fix won't make it go away, I'm afraid.
To be clear, I did not vote in the Meinungsbild, because I have no strong feeling about the MediaViewer one way or the other.
Cheers, Magnus
Am 13.08.2014 21:53 schrieb "Magnus Manske" magnusmanske@googlemail.com:
On Wed, Aug 13, 2014 at 6:20 PM, rupert THURNER rupert.thurner@gmail.com wrote:
Am 13.08.2014 15:56 schrieb "Magnus Manske" <magnusmanske@googlemail.com
:
On Wed, Aug 13, 2014 at 6:51 AM, rupert THURNER <
rupert.thurner@gmail.com>
wrote:
On Tue, Aug 12, 2014 at 6:26 PM, Erik Moeller erik@wikimedia.org
wrote:
On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske magnusmanske@googlemail.com wrote:
It's probably fine for "modern" viewing, although it's hard to
guess
that
you get to the file page via the little Commons icon for people
who
(in
all
likelihood) have never seen that icon, or visited Commons.
Indeed, the icon to the File: page is currently very opaque. We're preparing for a round of possible changes to the viewing
experience,
potentially including
- moving caption above the fold so readers don't have to hunt for
it
- moving disable action above-the-fold
- potentially eliminating the below-the-fold panel entirely
- emphasizing the File: page more prominently as the canonical
source
of metadata
- separating out download/use actions more clearly
These changes will need to be carefully tested/validated. If you
want
to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but
please
magnus, do these changes make you turn it on again? if not, what
would
need
to be better?
I think this is a non-issue. It took one click to get to the image
page;
now it takes two. That's my main "problem" with it. As I said, I'm not the target audience for this. I hope.
to give back the one click experience one would need two entry points. a tab or a toolbox link to start mediaviewer, and standard behavior on the images. for one link more in the gui everybody would be happy?
Thanks for trying, but I wouldn't like to have some "click confusion" to
be
added on my part. This is not really the issue that's being discussed
here.
Some people felt that MediaViewer is too buggy to be default right now.
WMF
disagreed. Disagreement escalated. This needs to calm down again. A quick single-point tech fix won't make it go away, I'm afraid.
haha, yes, if you express it like that i agree. i was suggesting this more as a permanent solution, in the lines of googles "images" tab when presenting search results. it is well established and simple to grasp. one click less to get what one wants, one option less. the user always has both choices. bugs of course stay bugs. such a media tab would additionally allow to not only present images out of the article, but some search result out of commons if desired. later on it might allow a new workflow for editing by selecting one of the images and have a "include in the article" choice. the search box could be adjusted to find text or media depending which tab is selected.
rupert
It would work for me. Peter Southwood
-----Original Message----- From: wikimedia-l-bounces@lists.wikimedia.org [mailto:wikimedia-l-bounces@lists.wikimedia.org] On Behalf Of rupert THURNER Sent: 13 August 2014 07:21 PM To: Wikimedia Mailing List Subject: Re: [Wikimedia-l] Superprotect user right, Comming to a wiki near you
Am 13.08.2014 15:56 schrieb "Magnus Manske" magnusmanske@googlemail.com:
On Wed, Aug 13, 2014 at 6:51 AM, rupert THURNER rupert.thurner@gmail.com wrote:
On Tue, Aug 12, 2014 at 6:26 PM, Erik Moeller erik@wikimedia.org
wrote:
On Tue, Aug 12, 2014 at 4:57 PM, Magnus Manske magnusmanske@googlemail.com wrote:
It's probably fine for "modern" viewing, although it's hard to guess
that
you get to the file page via the little Commons icon for people who
(in
all
likelihood) have never seen that icon, or visited Commons.
Indeed, the icon to the File: page is currently very opaque. We're preparing for a round of possible changes to the viewing experience, potentially including
- moving caption above the fold so readers don't have to hunt for
it
- moving disable action above-the-fold
- potentially eliminating the below-the-fold panel entirely
- emphasizing the File: page more prominently as the canonical
source of metadata
- separating out download/use actions more clearly
These changes will need to be carefully tested/validated. If you want to take a look at an early early (!) prototype (!!), see http://multimedia-alpha.wmflabs.org/wiki/Lightbox_demo , but please
magnus, do these changes make you turn it on again? if not, what would
need
to be better?
I think this is a non-issue. It took one click to get to the image page; now it takes two. That's my main "problem" with it. As I said, I'm not the target audience for this. I hope.
to give back the one click experience one would need two entry points. a tab or a toolbox link to start mediaviewer, and standard behavior on the images. for one link more in the gui everybody would be happy?
rupert _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-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/8026 - Release Date: 08/13/14
On 12.08.2014 16:57, Magnus Manske wrote:
German Wikipedia had 1.1 billion page views in June [1]. ~300 votes (~2/3 against MediaViewer) do not represent the readers, IMHO.
Claiming to speak for a perceived silent majority will not help you much in this discussion.
There is a common pattern in the conflicts between WMF and several communities over software developments during the last few years. As I wrote two weeks ago to Rachel:
| Decision making seems to be focused on reader experience, including | winning readers to become authors, but existing authors and their | experience (in both meanings of the word) is ignored. Even by people | like Eric, who once was a prolific author himself
| Authors see themselves as the single most important group in the |Wikimedia universe. Without their content, there would be nothing: No | readers, no fundraising banners, no donations, no employees, no | foundation. On the other hand, WMF seems to see the readers (and | donors) as their main target audience. Of course WMF knows, that all | the projects need content and authors, but in my opinion most of them | fail in appreciating the existing authors and focus too much on | winning readers to become authors, by simplifying the entry.
This is serious. WMF really needs to appreciate the expertise of the author community and accept their experience a important and valid. If authors tell the WMF and particularly the devs, that a particular function is necessary, then the devs really, really need to think.
If the community tells the devs, that a particular idea is a bad one, a feature is too buggy to be rolled out (as default) or is unsuitable for a project at all, this warrants more than just a cursory thought.
A formal RfD must not be taken lightly, overruling it by creating a whole new user class, and crippling the elected admins is inpermissible. WMF has broken trust again and this time in a unprecedented way.
Until this event, I thought the dev process to be broken, not just the communication around devs. But now I believe the conflict runs deeper.
Henning User: H-stt (admin on deWP and Commons)
On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann h.schlottmann@gmx.net wrote:
On 12.08.2014 16:57, Magnus Manske wrote:
German Wikipedia had 1.1 billion page views in June [1]. ~300 votes (~2/3 against MediaViewer) do not represent the readers, IMHO.
Claiming to speak for a perceived silent majority will not help you much in this discussion.
I do not make any such claim. All I say is that the 300 (is there a movie plot here?) do not necessarily speak for it, either.
There is a common pattern in the conflicts between WMF and several communities over software developments during the last few years. As I wrote two weeks ago to Rachel:
| Decision making seems to be focused on reader experience, including | winning readers to become authors, but existing authors and their | experience (in both meanings of the word) is ignored. Even by people | like Eric, who once was a prolific author himself
| Authors see themselves as the single most important group in the |Wikimedia universe. Without their content, there would be nothing: No | readers, no fundraising banners, no donations, no employees, no | foundation. On the other hand, WMF seems to see the readers (and | donors) as their main target audience. Of course WMF knows, that all | the projects need content and authors, but in my opinion most of them | fail in appreciating the existing authors and focus too much on | winning readers to become authors, by simplifying the entry.
This is serious. WMF really needs to appreciate the expertise of the author community and accept their experience a important and valid. If authors tell the WMF and particularly the devs, that a particular function is necessary, then the devs really, really need to think.
I do agree with this. Visual Editor (which works much better these days) and MediaViewer are not aimed at the experienced editor. They aim to make the reader more comfortable, and try to ease the first steps into editing. Winning new editors has been deemed a priority, somewhat at the expense of WMF-made support for the power user. This is a judgement call the Foundation has to make.
If the community tells the devs, that a particular idea is a bad one, a feature is too buggy to be rolled out (as default) or is unsuitable for a project at all, this warrants more than just a cursory thought.
A formal RfD must not be taken lightly, overruling it by creating a whole new user class, and crippling the elected admins is inpermissible. WMF has broken trust again and this time in a unprecedented way.
As Erik pointed out, WMF had made it quite clear that they reserve the right to overrule the community in that specific matter, before the Meinungsbild was done. WMF then acted as announced, and refused to be "hacked" out of their own servers. An unfortunate escalation on both sides, but since they never promised to accept the Meinungsbild (quite the opposite!), it was not a breach of trust.
Until this event, I thought the dev process to be broken, not just the communication around devs. But now I believe the conflict runs deeper.
It points out an issue we (community and WMF) should discuss, in a more general sense. What should the decision process be for technical changes? When does the Foundation get precendence, and when should the community have the last word? What weight should small-scale "votes" of editors have? Should random polls be done, and included in such votes? Etc.
The MediaViewer "affair" itself gets blown out of proportion IMO.
Cheers, Magnus
All,
I just want to call your attention to Lila's statement at https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#On_a_Scale_of_Billion... .
pb
*Philippe Beaudette * \ Director, Community Advocacy \ Wikimedia Foundation, Inc. T: 1-415-839-6885 x6643 | philippe@wikimedia.org | : @Philippewiki https://twitter.com/Philippewiki
On Tue, Aug 12, 2014 at 2:41 PM, Magnus Manske magnusmanske@googlemail.com wrote:
On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann < h.schlottmann@gmx.net> wrote:
On 12.08.2014 16:57, Magnus Manske wrote:
German Wikipedia had 1.1 billion page views in June [1]. ~300 votes
(~2/3
against MediaViewer) do not represent the readers, IMHO.
Claiming to speak for a perceived silent majority will not help you much in this discussion.
I do not make any such claim. All I say is that the 300 (is there a movie plot here?) do not necessarily speak for it, either.
There is a common pattern in the conflicts between WMF and several communities over software developments during the last few years. As I wrote two weeks ago to Rachel:
| Decision making seems to be focused on reader experience, including | winning readers to become authors, but existing authors and their | experience (in both meanings of the word) is ignored. Even by people | like Eric, who once was a prolific author himself
| Authors see themselves as the single most important group in the |Wikimedia universe. Without their content, there would be nothing: No | readers, no fundraising banners, no donations, no employees, no | foundation. On the other hand, WMF seems to see the readers (and | donors) as their main target audience. Of course WMF knows, that all | the projects need content and authors, but in my opinion most of them | fail in appreciating the existing authors and focus too much on | winning readers to become authors, by simplifying the entry.
This is serious. WMF really needs to appreciate the expertise of the author community and accept their experience a important and valid. If authors tell the WMF and particularly the devs, that a particular function is necessary, then the devs really, really need to think.
I do agree with this. Visual Editor (which works much better these days) and MediaViewer are not aimed at the experienced editor. They aim to make the reader more comfortable, and try to ease the first steps into editing. Winning new editors has been deemed a priority, somewhat at the expense of WMF-made support for the power user. This is a judgement call the Foundation has to make.
If the community tells the devs, that a particular idea is a bad one, a feature is too buggy to be rolled out (as default) or is unsuitable for a project at all, this warrants more than just a cursory thought.
A formal RfD must not be taken lightly, overruling it by creating a whole new user class, and crippling the elected admins is inpermissible. WMF has broken trust again and this time in a unprecedented way.
As Erik pointed out, WMF had made it quite clear that they reserve the right to overrule the community in that specific matter, before the Meinungsbild was done. WMF then acted as announced, and refused to be "hacked" out of their own servers. An unfortunate escalation on both sides, but since they never promised to accept the Meinungsbild (quite the opposite!), it was not a breach of trust.
Until this event, I thought the dev process to be broken, not just the communication around devs. But now I believe the conflict runs deeper.
It points out an issue we (community and WMF) should discuss, in a more general sense. What should the decision process be for technical changes? When does the Foundation get precendence, and when should the community have the last word? What weight should small-scale "votes" of editors have? Should random polls be done, and included in such votes? Etc.
The MediaViewer "affair" itself gets blown out of proportion IMO.
Cheers, Magnus _______________________________________________ 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 12:41 PM, Magnus Manske <magnusmanske@googlemail.com
wrote:
On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann < h.schlottmann@gmx.net> wrote:
This is serious. WMF really needs to appreciate the expertise of the author community and accept their experience a important and valid. If authors tell the WMF and particularly the devs, that a particular function is necessary, then the devs really, really need to think.
I do agree with this. Visual Editor (which works much better these days) and MediaViewer are not aimed at the experienced editor. They aim to make the reader more comfortable, and try to ease the first steps into editing. Winning new editors has been deemed a priority, somewhat at the expense of WMF-made support for the power user. This is a judgement call the Foundation has to make.
This is the biggest aspect of the problem, from my perspective: many of us who have opposed the default enabling of the Media Viewer have done so *not* on the basis that we personally dislike it, but on the basis that we believe it causes problems for the process of helping readers become effective editors. I myself have a great deal of experience with this process; I was hired in 2009 by WMF for my expertise in this area; I helped design the Ambassador Training program for the WMF that helps university students convert from readers to editors; and since I left WMF, I have trained hundreds of others to edit Wikipedia, most notably in the 6 week online course I developed and taught 4 times. Whether or not I, as an experienced editor, like the Media Viewer is indeed unimportant; I have no problem disabling the software for myself.
Many WMF staff, however, *continue* to summarize the opposition as, "experienced editors do not like it." This is a straw man argument, and an absolute failure to absorb the considered criticisms layed out on the various RfC pages. At the same time, a frequent piece of the WMF argument is, "many readers *do* like it." But whether or not they *like* it is completely different from whether or not we are guiding them toward becoming editors -- the two have almost nothing to do with one another. Whether the readers "like" it has absolutely nothing to do with the five goals layed out in the 2010 Five Year Strategic Plan. But whether or not they are guided effectively toward becoming editors, that does. And removing the "edit" button, or any suggestion that such a thing might exist, from millions and millions of pages...that does not serve that goal.
The WMF chose to "Narrow Focus" a couple years ago. I believe that what got "narrowed out" was, by and large, processes that serve the secondary purpose of helping the WMF educate itself, in an ongoing way, about how its projects and communities operate. I believe we are seeing the effects of that decision now.
Until this event, I thought the dev process to be broken, not just the communication around devs. But now I believe the conflict runs deeper.
It points out an issue we (community and WMF) should discuss, in a more general sense. What should the decision process be for technical changes? When does the Foundation get precendence, and when should the community have the last word? What weight should small-scale "votes" of editors have?
While I agree that it's important to have some clarity on this stuff, it's also very important -- more important, perhaps -- to keep in mind that when things are working smoothly, we very rarely have to consider the question of "who can overrule whom." That is the kind of ideal the WMF should be striving for -- in actions, not merely in words.
Pete [[User:Peteforsyth]]
2014-08-12 21:41 GMT+02:00 Magnus Manske magnusmanske@googlemail.com:
On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann < h.schlottmann@gmx.net> wrote:
There is a common pattern in the conflicts between WMF and several communities over software developments during the last few years. As I wrote two weeks ago to Rachel:
| Decision making seems to be focused on reader experience, including | winning readers to become authors, but existing authors and their | experience (in both meanings of the word) is ignored. Even by people | like Eric, who once was a prolific author himself
| Authors see themselves as the single most important group in the |Wikimedia universe. Without their content, there would be nothing: No | readers, no fundraising banners, no donations, no employees, no | foundation. On the other hand, WMF seems to see the readers (and | donors) as their main target audience. Of course WMF knows, that all | the projects need content and authors, but in my opinion most of them | fail in appreciating the existing authors and focus too much on | winning readers to become authors, by simplifying the entry.
This is serious. WMF really needs to appreciate the expertise of the author community and accept their experience a important and valid. If authors tell the WMF and particularly the devs, that a particular function is necessary, then the devs really, really need to think.
I do agree with this. Visual Editor (which works much better these days) and MediaViewer are not aimed at the experienced editor. They aim to make the reader more comfortable, and try to ease the first steps into editing. Winning new editors has been deemed a priority, somewhat at the expense of WMF-made support for the power user. This is a judgement call the Foundation has to make.
I am not sure how it is for other wikis but we have seen bugs in the Visual Editor which cause newbies to do wrong edits (like removing stuff which a. should not be removed, b. was not intented to be removed by the newby) that other users can repair later. If new software causes us extra work, purely because of problems in the software itself, the software is absolutely not ready to set on by default. And we are not talking about an extra tool but about a basic functionality that is going to be used massively with many many changes in many pages.
The first priority is having the software work well on a basic level (and the servers in general). The second priority is to attract more new editors.
Until this event, I thought the dev process to be broken, not just the
communication around devs. But now I believe the conflict runs deeper.
It points out an issue we (community and WMF) should discuss, in a more general sense. What should the decision process be for technical changes? When does the Foundation get precendence, and when should the community have the last word? What weight should small-scale "votes" of editors have? Should random polls be done, and included in such votes? Etc.
The MediaViewer "affair" itself gets blown out of proportion IMO.
I fully agree. If a community really has serious problems, these should be carefully considered and the community should be attacked on various ways by WMF. At the current situation, WMF thinks in my opinion to lightly about the role of the community, and to lightly about how she can behave towards a community. We all want the best of each other, than this is not the way to do that.
Romaine
On 12.08.2014 21:41, Magnus Manske wrote:
On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann h.schlottmann@gmx.net wrote:
This is serious. WMF really needs to appreciate the expertise of the author community and accept their experience a important and valid. If authors tell the WMF and particularly the devs, that a particular function is necessary, then the devs really, really need to think.
I do agree with this. Visual Editor (which works much better these days) and MediaViewer are not aimed at the experienced editor. They aim to make the reader more comfortable, and try to ease the first steps into editing. Winning new editors has been deemed a priority, somewhat at the expense of WMF-made support for the power user. This is a judgement call the Foundation has to make.
I do not undersign that dichotomy between readers and authors. And I certainly do not accept any claim, that the MWF know all about what readers need to become authors, while the authors are ignorant about that. The results of the millions of dollars, the WMF put into their understanding of readers interest are less than sterling in this regard.
A formal RfD must not be taken lightly, overruling it by creating a whole new user class, and crippling the elected admins is inpermissible. WMF has broken trust again and this time in a unprecedented way.
As Erik pointed out, WMF had made it quite clear that they reserve the right to overrule the community in that specific matter, before the Meinungsbild was done. WMF then acted as announced, and refused to be "hacked" out of their own servers. An unfortunate escalation on both sides, but since they never promised to accept the Meinungsbild (quite the opposite!), it was not a breach of trust.
Frankly: I don't care the least, what Eric says. Of course the Meinungsbild (RfD) at deWP was a vote of noconfidence after the previous events at enWP. But the reaction by WMF was unprecedented and it was a mistake. A serious one. It damaged the relation between the Community and the WMF, it killed Jan's job and it made Rachel's job very difficult if not untenable. To describe Eric's action I am tempted to use a metaphor that includes black uniforms and heavy boots. But that would not be appropriately written by a German to a German.
Until this event, I thought the dev process to be broken, not just the communication around devs. But now I believe the conflict runs deeper.
It points out an issue we (community and WMF) should discuss, in a more general sense. What should the decision process be for technical changes? When does the Foundation get precendence, and when should the community have the last word? What weight should small-scale "votes" of editors have? Should random polls be done, and included in such votes? Etc.
The MediaViewer "affair" itself gets blown out of proportion IMO.
I agree that this is not just about the MediaViewer but about a general pattern of behavior perceived by the community. The WMF's decision making regarding software and skin development is broken. Its targets are flawed, it is not properly communicated with the community, the actual development processes result in incredibly crappy software that gets rolled out non the less in pre-alpha states.
Do I have to list all the broken projects? Liquid feedback, article feedback tool, image filter, visual editor, flow, the new "thumb" layout.
How do you explain that to donors by the way?
All of them show that the devs and the management level do not understand the features of the existing solutions, particularly the well established tools and sometimes work arounds, authors created over the years to deal with the very basic MediaWiki. But understanding the actual use of MediaWiki is paramount to improving it.
Ciao Henning
Henning,
"To describe Eric's action I am tempted to use a metaphor that includes black uniforms and heavy boots. But that would not be appropriately written by a German to a German."
You may find yourself very smart with this kind of wording. Let me tell you from a North German to a North German: "Dat bisse nich."
Ziko
2014-08-14 12:13 GMT+02:00 Henning Schlottmann h.schlottmann@gmx.net:
On 12.08.2014 21:41, Magnus Manske wrote:
On Tue, Aug 12, 2014 at 5:33 PM, Henning Schlottmann h.schlottmann@gmx.net wrote:
This is serious. WMF really needs to appreciate the expertise of the author community and accept their experience a important and valid. If authors tell the WMF and particularly the devs, that a particular function is necessary, then the devs really, really need to think.
I do agree with this. Visual Editor (which works much better these days) and MediaViewer are not aimed at the experienced editor. They aim to make the reader more comfortable, and try to ease the first steps into editing. Winning new editors has been deemed a priority, somewhat at the expense of WMF-made support for the power user. This is a judgement call the Foundation has to make.
I do not undersign that dichotomy between readers and authors. And I certainly do not accept any claim, that the MWF know all about what readers need to become authors, while the authors are ignorant about that. The results of the millions of dollars, the WMF put into their understanding of readers interest are less than sterling in this regard.
A formal RfD must not be taken lightly, overruling it by creating a whole new user class, and crippling the elected admins is inpermissible. WMF has broken trust again and this time in a unprecedented way.
As Erik pointed out, WMF had made it quite clear that they reserve the right to overrule the community in that specific matter, before the Meinungsbild was done. WMF then acted as announced, and refused to be "hacked" out of their own servers. An unfortunate escalation on both sides, but since they never promised to accept the Meinungsbild (quite the opposite!), it was not a breach of trust.
Frankly: I don't care the least, what Eric says. Of course the Meinungsbild (RfD) at deWP was a vote of noconfidence after the previous events at enWP. But the reaction by WMF was unprecedented and it was a mistake. A serious one. It damaged the relation between the Community and the WMF, it killed Jan's job and it made Rachel's job very difficult if not untenable. To describe Eric's action I am tempted to use a metaphor that includes black uniforms and heavy boots. But that would not be appropriately written by a German to a German.
Until this event, I thought the dev process to be broken, not just the communication around devs. But now I believe the conflict runs deeper.
It points out an issue we (community and WMF) should discuss, in a more general sense. What should the decision process be for technical changes? When does the Foundation get precendence, and when should the community have the last word? What weight should small-scale "votes" of editors have? Should random polls be done, and included in such votes? Etc.
The MediaViewer "affair" itself gets blown out of proportion IMO.
I agree that this is not just about the MediaViewer but about a general pattern of behavior perceived by the community. The WMF's decision making regarding software and skin development is broken. Its targets are flawed, it is not properly communicated with the community, the actual development processes result in incredibly crappy software that gets rolled out non the less in pre-alpha states.
Do I have to list all the broken projects? Liquid feedback, article feedback tool, image filter, visual editor, flow, the new "thumb" layout.
How do you explain that to donors by the way?
All of them show that the devs and the management level do not understand the features of the existing solutions, particularly the well established tools and sometimes work arounds, authors created over the years to deal with the very basic MediaWiki. But understanding the actual use of MediaWiki is paramount to improving it.
Ciao Henning
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
14.08.2014, 13:33, "Ziko van Dijk" <email clipped>:
Henning,
"To describe Eric's action I am tempted to use a metaphor that includes black uniforms and heavy boots. But that would not be appropriately written by a German to a German."
You may find yourself very smart with this kind of wording. Let me tell you from a North German to a North German: "Dat bisse nich."
Man musst nicht Norddeutscher sein verstehen zu koennen dass das Quatschvergleichung ist.
Trillium Corsage
Whoever believes that an administration of a crowdsourcing website can do whatever they want just because they are running the website should recollect what recently happened to Internet Brands and Wikitravel.
Popcorn, anyone?
Wikipedia is not an organization, and the WMF does not administer the Wikipedias. It owns them, which gives the WMF the *legal right* to administer. It's quite obvious that, as the wikis have been operating, for the WMF to take over administration would require major changes. But it would not be impossible, and only a narrow imagination would conclude so.
This issue of superprotect and how it was used raises issues of power and control. It seems to be assumed in these discussions that this is a deliberate assertion of power, "we are in charge and you are not," and in a sense, it obviously is. However, is that the intention? Why are WMF employees confronting the community at this time and in this way and over a relatively small issue, and without a clear policy statement from the Board? The WMF has been, apparently, silent so far, which could mean that the Board and Executive Director have no plan, that they are trying to figure out what to do. This would be completely unsurprising.
There are now editors suggesting a strike. That would be the community -- or a segment of the community -- attempting to force the WMF to submit to their way. And the superprotect flap was the WMF attempting to force the community to submit to their way. That tends to be where we go first when we are sure we are right, and others are wrong. And if it goes this way, everyone loses, very likely. https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotect_rights
is the usual wiki train wreck, which is what happens when raw, unripe proposals are made. But the WMF is not like the community, it is possible for it to come up with reflected, deliberated response. That, indeed, is why they have the money and the control. I recommend no rush. Do this right.
That RfC is generating a lot of comment. Someone can and should refactor it to summarize the arguments, to create a true "consensus document," I've been calling it. But whether or not anyone will find the time to do it, I don't know. It's a lot of work. Still, I'd think that the WMF would be noticing that it touched a live wire. So now what?
Abd ul-Rahman Lomax I'm so excited I can't wait for Now.
On Aug 11, 2014, at 7:13 PM, Todd Allen toddmallen@gmail.com wrote:
like suppression, it should be used only by stewards and community approved functionaries.
I'm confused. Are you suggesting that suppression is not used by staff?
Super protection can be used by staff, and was. Suppression can be used by staff as well, and regularly is. (For instance, if legal were to ask me to suppress an edit, under court order). It (suppression) is not a tool we use without careful consideration, but it is one we use. I should think the same would be true of superprotection- it's not to be used lightly but it is a tool in our belt.
Philippe
On Mon, Aug 11, 2014 at 10:13 PM, Philippe Beaudette < pbeaudette@wikimedia.org> wrote:
On Aug 11, 2014, at 7:13 PM, Todd Allen toddmallen@gmail.com wrote:
like suppression, it should be used only by stewards and community approved functionaries.
I'm confused. Are you suggesting that suppression is not used by staff?
Super protection can be used by staff, and was. Suppression can be used by staff as well, and regularly is. (For instance, if legal were to ask me to suppress an edit, under court order). It (suppression) is not a tool we use without careful consideration, but it is one we use. I should think the same would be true of superprotection- it's not to be used lightly but it is a tool in our belt.
Philippe _______________________________________________ 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
I think we're comparing apples to anvils here. Handling a legal issue using suppression (or protection, or now superprotection) is a far cry from using it to resolve a dispute to one's preferred outcome. That is, if nothing else, a massive expansion of what's normally been acceptable as an Office action, which have historically (and to my mind, properly) been reserved for cases that could put us in severe legal jeopardy if not immediately addressed. Those cases, while rare, are an appropriate use.
Standard full protection along with necessary suppressions, however, along with clear warnings indicating what's going on, has always been sufficient to handle those few cases. Superprotection wasn't designed with vanishingly rare Office legal actions that are already quite adequately handled in mind, and I think all of us here know that. It's another attempt to force unwanted changes, because apparently "We'll desysop you for implementing your community's decisions when we won't!" wasn't quite ham-fisted enough.
Forwarding comments from Lila from https://meta.wikimedia.org/w/index.php?title=User_talk%3ALilaTretikov&di...
All --
Thank you for your comments, criticism, support and advice on software that you've collected in the RfCs. I agree that we need to improve both our process and our software. MV is a great feature to use as a testbed for those improvements. I also believe it represents a good foundation that we should improve together. We are not going to make any hasty changes, but we will will get back to you on:
* Next steps (in the next 2-3 weeks) * Process improvements * Software changes * Policy clarification (deployment, RFCs, reverts, etc.)
We love your feedback and your support.
Thank you.
FWIW, Lila's comments were made before the start of this email thread about superprotect.
Pine
On Mon, Aug 11, 2014 at 11:53 PM, Pine W wiki.pine@gmail.com wrote:
Forwarding comments from Lila from https://meta.wikimedia.org/w/index.php?title=User_talk%3ALilaTretikov&di...
All --
Thank you for your comments, criticism, support and advice on software that you've collected in the RfCs. I agree that we need to improve both our process and our software. MV is a great feature to use as a testbed for those improvements. I also believe it represents a good foundation that we should improve together. We are not going to make any hasty changes, but we will will get back to you on:
- Next steps (in the next 2-3 weeks)
- Process improvements
- Software changes
- Policy clarification (deployment, RFCs, reverts, etc.)
We love your feedback and your support.
Thank you.
wikimedia-l@lists.wikimedia.org