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
On 10 aug. 2014, at 14:27, Erik Moeller erik@wikimedia.org wrote:
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.
I agree that the current situation is basically something that grew historically that is no longer sustainable. For a long time this was not really a problem and good faith made it work regardless of how broken it was, but when it is used for manipulation, then action is required.
This is not a new thing, but perhaps a clarification that was long over due (and one we perhaps we shied away from too long). We need to collaborate to iterate and improve the software for our movement. I'm the first to support the fact that we have not been able to do that in the past for many reasons. We are now becoming more capable, but we will also still be making a lot of mistakes from various roles, while building the actual feedback loop required to perfect this process. BUT that is a separate issue and there are different venues for that, which are not Common.js -like methodologies.
DJ , Volunteer developer
Totally agree with that, dirty common.js hacks aren't really beneficial for anyone.
Cheers,
Marius
On Sun, 2014-08-10 at 14:56 +0100, Derk-Jan Hartman wrote:
On 10 aug. 2014, at 14:27, Erik Moeller erik@wikimedia.org wrote:
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.
I agree that the current situation is basically something that grew historically that is no longer sustainable. For a long time this was not really a problem and good faith made it work regardless of how broken it was, but when it is used for manipulation, then action is required.
This is not a new thing, but perhaps a clarification that was long over due (and one we perhaps we shied away from too long). We need to collaborate to iterate and improve the software for our movement. I'm the first to support the fact that we have not been able to do that in the past for many reasons. We are now becoming more capable, but we will also still be making a lot of mistakes from various roles, while building the actual feedback loop required to perfect this process. BUT that is a separate issue and there are different venues for that, which are not Common.js -like methodologies.
DJ , Volunteer developer
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
Il 10/08/2014 15:27, Erik Moeller ha scritto:
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
https://meta.wikimedia.org/w/index.php?title=Special:Log&dir=prev&of...
WMF vs. community? https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotection
Il 10/08/2014 19:33, Ricordisamoa ha scritto:
Il 10/08/2014 15:27, Erik Moeller ha scritto:
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
https://meta.wikimedia.org/w/index.php?title=Special:Log&dir=prev&of...
WMF vs. community? https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotection
Updated link: https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotect_rights
Hi,
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.
I first thought when witnessing the explicit removal of some lines of code from the German MediaWiki:Common.js [0] followed by the alteration of permission (meaning the assignment of the newly created <superprotect> right) to the same page was a coincidence.
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).
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.
What situation did emerge that such drastic measures were/are necessary?
[0] https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=prev...
[1] https://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js&action=...
[2] https://gerrit.wikimedia.org/r/#/c/153345/ + https://gerrit.wikimedia.org/r/#/c/153351/
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=69380
Cheers
On 8/10/14, 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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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".
--bawolff
Hi,
[Putting purely the mw dev hat on]
I'm putting a hat on from pure observer point of view as neither a member of de.wp nor wmf.
So dont complain that mw fixes a bug in how page protection. If you are
I'm not complaining, I'm observing the events that happened around the introduction of <superprotected> and the swift action which did not involve any consultation or discussion (or rather a single statement from Erik Moeller where he cites security and code review as the inherent cause for the introduction).
It was a bug in mediawiki, and thus it should be fixed. MediaWiki is used
{{cc}} (which bug, when was created and by whom)
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.
Interesting view, that means bugs that are to solve a political dispute are preferred over bugs that existed for years?
Cheers
On 8/12/14, 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".
--bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Aug 11, 2014 2:34 PM, "James HK" jamesin.hongkong.1@gmail.com wrote:
Hi,
[Putting purely the mw dev hat on]
I'm putting a hat on from pure observer point of view as neither a member of de.wp nor wmf.
Note: that i consider my mw dev hat to not involve wmf.
So dont complain that mw fixes a bug in how page protection. If you are
I'm not complaining, I'm observing the events that happened around the introduction of <superprotected> and the swift action which did not involve any consultation or discussion (or rather a single statement from Erik Moeller where he cites security and code review as the inherent cause for the introduction).
It was a bug in mediawiki, and thus it should be fixed. MediaWiki is
used
{{cc}} (which bug, when was created and by whom)
I'm referring to https://gerrit.wikimedia.org/r/#/c/153349/ . I thought that was what the parent message was referring to.
A bug is defined as a the software not working the way it is "expected" to. Not all bugs are tracked in bugzilla, even if most are.
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.
Interesting view, that means bugs that are to solve a political dispute are preferred over bugs that existed for years?
Cheers
Politics isnt really a criteria generally. Bugs are fixed based on many metrics including severity, demands of users, ease of fixing, if there is someone interested in fixing it, etc. In this case it is very easy to fix, and there is an entity contributing to mw who is extremely interested in it being fixed. So it got fixed. But it would still probably have been fixed if somebody else complained.
--bawolff
On 8/12/14, 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".
--bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Sorry wrong url, i meant https://gerrit.wikimedia.org/r/#/c/153345/ not the url i wrote.
Anyways, if the original email was complaining about the config change and not the delete/edit rights change then its much more reasonable. i thus take back my previous email.
--bawolff On Aug 11, 2014 3:45 PM, "Brian Wolff" bawolff@gmail.com wrote:
On Aug 11, 2014 2:34 PM, "James HK" jamesin.hongkong.1@gmail.com wrote:
Hi,
[Putting purely the mw dev hat on]
I'm putting a hat on from pure observer point of view as neither a member of de.wp nor wmf.
Note: that i consider my mw dev hat to not involve wmf.
So dont complain that mw fixes a bug in how page protection. If you
are
I'm not complaining, I'm observing the events that happened around the introduction of <superprotected> and the swift action which did not involve any consultation or discussion (or rather a single statement from Erik Moeller where he cites security and code review as the inherent cause for the introduction).
It was a bug in mediawiki, and thus it should be fixed. MediaWiki is
used
{{cc}} (which bug, when was created and by whom)
I'm referring to https://gerrit.wikimedia.org/r/#/c/153349/ . I thought
that was what the parent message was referring to.
A bug is defined as a the software not working the way it is "expected"
to. Not all bugs are tracked in bugzilla, even if most are.
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.
Interesting view, that means bugs that are to solve a political dispute are preferred over bugs that existed for years?
Cheers
Politics isnt really a criteria generally. Bugs are fixed based on many
metrics including severity, demands of users, ease of fixing, if there is someone interested in fixing it, etc. In this case it is very easy to fix, and there is an entity contributing to mw who is extremely interested in it being fixed. So it got fixed. But it would still probably have been fixed if somebody else complained.
--bawolff
On 8/12/14, 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".
--bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Looks like the only change here was to the Wikimedia config, not the MediaWiki software defaults (and thus be subject to a normal release schedule). Instead, this seems to have been done quickly just for the purpose of enforcing something against the wishes of the community.
On Mon, Aug 11, 2014 at 10: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".
--bawolff _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
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:
Was this functionality was ever supported by MediaWiki core?
Of course this is supported by MediaWiki core, although I cannot attest as to whether it was previously implemented on WMF wikis.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On 8/10/14, 6:27 AM, Erik Moeller wrote:
Hi folks,
Admins are currently given broad leeway to customize the user experience for all users, including addition of site-wide JS, CSS, etc. These are important capabilities of the wiki that have been used for many clearly beneficial purposes. In the long run, we will want to apply a code review process to these changes as with any other deployed code, but for now the system works as it is and we have no intent to remove this capability.
Sorry, I strongly disagree that the current system works. Every so often we discover that a wiki has been loading external resources in site-wide JS for months. Local sysops might have no idea on what they're doing, and just copy and paste what someone told them to do. Edits like [1] make that terribly obvious.
I filed bug 69445[2] as a tracking bug to implement a sane code review process for these pages. I don't imagine it will happen anytime soon, but now seems like a good time to start discussion about it.
[1] https://szl.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js&diff=p... [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
-- Legoktm
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.
Sorry, I strongly disagree that the current system works. Every so often we discover that a wiki has been loading external resources in site-wide JS for months. Local sysops might have no idea on what they're doing, and just copy and paste what someone told them to do. Edits like [1] make that terribly obvious.
I filed bug 69445[2] as a tracking bug to implement a sane code review process for these pages. I don't imagine it will happen anytime soon, but now seems like a good time to start discussion about it.
I'm fine with having some sort of code review system, so long as it is implemented in such a way that there are volunteers with +2 for it.
I'm not sure implementing this user right though was the best way to go about beginning that implementation, at least with the sort of charged atmosphere that currently exists within the Wikimedia editor communities.
Perhaps the change could be reverted and we could spend some time on this list discussing how such a code review system would work? Give some time for the editors to calm down and all of us to calm down. (A quick look at Meta shows a lot of hate.) I think if this is implemented slowly with lots of notice it might have a better chance of succeeding. I think Erik's commit is likely poisoned at this point and any work that stems from it is unlikely to be accepted by the wider community.
I like the discussion that is going on in #69445, thank you for filing that Legoktm.
If nothing else, this whole debacle brought this issue back to the center of discussion, somewhere where it needs to be.
Thank you, Derric Atzrott
Il 10/08/2014 15:27, Erik Moeller ha scritto:
In the long run, we will want to apply a code review process to these changes as with any other deployed code
The latest version of the Pywikibot framework could be useful to you. We recently introduced custom protection levels, and I think you could help testing the new feature by superprotecting every common.js in the farm. So you could spend your time thinking of other methods to 'empower' the community.
On Sun, 10 Aug 2014, at 23:19, 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
This change solves a problem that does not exist. We either trust sysops, or we don't.
Erik Moeller wrote:
In the long run, we will want to apply a code review process to these changes as with any other deployed code
I hope such things will not need to go through the WMF. Or is that what you'd like?
svetlana.
Le 10 août 2014 15:35, "svetlana" svetlana@fastmail.com.au a écrit :
On Sun, 10 Aug 2014, at 23:19, 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,...
This change solves a problem that does not exist. We either trust sysops, or we don't.
Erik Moeller wrote:
In the long run, we will want to apply a code review process to these changes as with any other deployed code
I hope such things will not need to go through the WMF. Or is that what
you'd like?
I hope it's not an other step from WMF to prevent the application of community decisions when they not agree with it. I fear that they will use this to bypass community decisions. For example like forcing again VE on everyone on enwki: last year, sysop were able to apply community decision against Erik wishes only because they had access to site wide js or CSS.
Nico
Wiadomość napisana przez Nicolas Vervelle nvervelle@gmail.com w dniu 10 sie 2014, o godz. 15:45:
I hope it's not an other step from WMF to prevent the application of community decisions when they not agree with it. I fear that they will use this to bypass community decisions. For example like forcing again VE on everyone on enwki: last year, sysop were able to apply community decision against Erik wishes only because they had access to site wide js or CSS.
I'd like to believe that code-reviewing would mean improving code quality, security and performance (applies to javascript).
Michał
On Sun, Aug 10, 2014 at 9:00 PM, Michał Łazowik mlazowik@me.com wrote:
Wiadomość napisana przez Nicolas Vervelle nvervelle@gmail.com w dniu 10 sie 2014, o godz. 15:45:
I hope it's not an other step from WMF to prevent the application of community decisions when they not agree with it. I fear that they will use this to bypass community decisions. For example like forcing again VE on everyone on enwki: last year, sysop were able to apply community decision against Erik wishes only because they had access to site wide js or CSS.
I'd like to believe that code-reviewing would mean improving code quality, security and performance (applies to javascript).
It could mean that, but of course it is actually introduced to prevent the German community from deactivating the Media Viewer.
https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&action=hi...
I remember when we used to beg for the WMF to deploy extensions. Now we really need to beg for the WMF to not deploy extensions ...
-- John Vandenberg
Hi,
It could mean that, but of course it is actually introduced to prevent the German community from deactivating the Media Viewer.
User JEissfeldt, removed `mw.config.set("wgMediaViewerOnClick", false);` from Common.js [0] and is the same person who sets `<protect-level-superprotect>`.
I have no idea what the German community wants or doesn't want but using `protect-level-superprotect` to block potential edits is rather questionable.
[0] https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=prev...
Cheers
On 8/10/14, John Mark Vandenberg jayvdb@gmail.com wrote:
On Sun, Aug 10, 2014 at 9:00 PM, Michał Łazowik mlazowik@me.com wrote:
Wiadomość napisana przez Nicolas Vervelle nvervelle@gmail.com w dniu 10 sie 2014, o godz. 15:45:
I hope it's not an other step from WMF to prevent the application of community decisions when they not agree with it. I fear that they will use this to bypass community decisions. For example like forcing again VE on everyone on enwki: last year, sysop were able to apply community decision against Erik wishes only because they had access to site wide js or CSS.
I'd like to believe that code-reviewing would mean improving code quality, security and performance (applies to javascript).
It could mean that, but of course it is actually introduced to prevent the German community from deactivating the Media Viewer.
https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&action=hi...
I remember when we used to beg for the WMF to deploy extensions. Now we really need to beg for the WMF to not deploy extensions ...
-- John Vandenberg
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 10 août 2014 17:06, "James HK" jamesin.hongkong.1@gmail.com a écrit :
Hi,
It could mean that, but of course it is actually introduced to prevent the German community from deactivating the Media Viewer.
User JEissfeldt, removed `mw.config.set("wgMediaViewerOnClick", false);` from Common.js [0] and is the same person who sets `<protect-level-superprotect>`.
I have no idea what the German community wants or doesn't want but using `protect-level-superprotect` to block potential edits is rather questionable.
[0]
https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=prev...
Thanks for the diff... That shows what this super protect power is really for: WMF forcing something against community wishes/discussion. My fear wasn't unfounded. Clearly a huge step backwards for the wiki philosophy
2014-08-10 17:00 GMT+03:00 Michał Łazowik mlazowik@me.com:
Wiadomość napisana przez Nicolas Vervelle nvervelle@gmail.com w dniu 10 sie 2014, o godz. 15:45:
I hope it's not an other step from WMF to prevent the application of community decisions when they not agree with it. I fear that they will use this to bypass community decisions. For example like forcing again VE on everyone on enwki: last year, sysop were able to apply community decision against Erik wishes only because they had access to site wide js or CSS.
I'd like to believe that code-reviewing would mean improving code quality, security and performance (applies to javascript).
I would like to believe that too. More likely though, without a serious comittment from the Foundation (which I heard nothing about), that would mean waiting for months, possibly years for reviews on small wikis.
Also, code review should be a strictly technical process and should not be used to overrule the community's decisions.
Strainu
Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything. The WMF has one codebase for MediaWiki and it explicitly defines with long lead times the things it is working on. It does invite the community to be involved in the process. However, this is where and when the technical future is decided. Several of the decisions do not have an option for a community to decide they want it or not when they are confronted with the realised software/future.
You know our projects, you know our licenses. If you, the "community"do not like what you have, you can fork. At Wikimania forking and leaving the community was very much discussed. Watch Jimbo's presentation for instance, he may be aghast that I quote him here but in his state of the Wiki he made it abundantly clear that it is your option to stay or go. Thanks, GerardM
On 11 August 2014 08:55, Strainu strainu10@gmail.com wrote:
2014-08-10 17:00 GMT+03:00 Michał Łazowik mlazowik@me.com:
Wiadomość napisana przez Nicolas Vervelle nvervelle@gmail.com w dniu
10 sie 2014, o godz. 15:45:
I hope it's not an other step from WMF to prevent the application of community decisions when they not agree with it. I fear that they will
use
this to bypass community decisions. For example like forcing again VE on everyone on enwki: last year, sysop were able to apply community
decision
against Erik wishes only because they had access to site wide js or CSS.
I'd like to believe that code-reviewing would mean improving code
quality, security
and performance (applies to javascript).
I would like to believe that too. More likely though, without a serious comittment from the Foundation (which I heard nothing about), that would mean waiting for months, possibly years for reviews on small wikis.
Also, code review should be a strictly technical process and should not be used to overrule the community's decisions.
Strainu
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, 11 Aug 2014, at 19:20, Gerard Meijssen wrote:
Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything. The WMF has one codebase for MediaWiki and it explicitly defines with long lead times the things it is working on. It does invite the community to be involved in the process.
It does not. It first designs a software and implements it, and then /tweaks/ it. Community should be asked what it'd like much, much earlier. Community participation in product design is currently impossible.
Hoi, This is simply not true. At Wikimania there were several sessions where the topic was what will the technical underpinnings be of our software. It was also discussed to some extend what kind of effect things may have on a community. When you are in those conversations you realise that many complications are considered; it is not easy nor obvious. Thanks, GerardM
NB there is not one community, there are many with often completely diverging opinions. Technically it is not possible to always keep backward compatibility / functionality. We are not backward we need to stay contemporary.
On 11 August 2014 10:36, svetlana svetlana@fastmail.com.au wrote:
On Mon, 11 Aug 2014, at 19:20, Gerard Meijssen wrote:
Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything. The WMF has one codebase for MediaWiki and it explicitly defines with long lead times the things it is working on. It does invite the community to be involved in the process.
It does not. It first designs a software and implements it, and then /tweaks/ it. Community should be asked what it'd like much, much earlier. Community participation in product design is currently impossible.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Then there's something wrong somewhere since what is eventually perceived by active "remote" community is just a wall of semi-clueless decisionism.
Vito
Inviato con AquaMail per Android http://www.aqua-mail.com
Il 11 agosto 2014 11:45:56 Gerard Meijssen gerard.meijssen@gmail.com ha scritto:
Hoi, This is simply not true. At Wikimania there were several sessions where the topic was what will the technical underpinnings be of our software. It was also discussed to some extend what kind of effect things may have on a community. When you are in those conversations you realise that many complications are considered; it is not easy nor obvious. Thanks, GerardM
NB there is not one community, there are many with often completely diverging opinions. Technically it is not possible to always keep backward compatibility / functionality. We are not backward we need to stay contemporary.
On 11 August 2014 10:36, svetlana svetlana@fastmail.com.au wrote:
On Mon, 11 Aug 2014, at 19:20, Gerard Meijssen wrote:
Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything. The WMF has one codebase for MediaWiki and it explicitly defines with long lead times the things it is working on. It does invite the community to be involved in the process.
It does not. It first designs a software and implements it, and then /tweaks/ it. Community should be asked what it'd like much, much earlier. Community participation in product design is currently impossible.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Il 11/08/2014 11:36, svetlana ha scritto:
On Mon, 11 Aug 2014, at 19:20, Gerard Meijssen wrote:
Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything. The WMF has one codebase for MediaWiki and it explicitly defines with long lead times the things it is working on. It does invite the community to be involved in the process.
It does not. It first designs a software and implements it, and then /tweaks/ it. Community should be asked what it'd like much, much earlier. Community participation in product design is currently impossible.
Agreed. Everything made by WMF to 'attract new readers' is actually disgusting real editors, more for the way they are introduced than for the actual features. I can think of VisualEditor, Typography refresh, now MediaViewer. The same is going to happen for Flow (which I strongly believe is needed, but is being deployed untimely) and Phabricator. When thinking of good features recently introduced by the WMF, only Echo comes to my mind (Wikidata is maintained by Wikimedia Deutschland). Why aren't they implementing a global repository for gadgets, modules, templates which is (IMHO) what the community needs first?
On 11 August 2014 10:56, Ricordisamoa ricordisamoa@openmailbox.org wrote:
The same is going to happen for Flow (which I strongly believe is needed, but is being deployed untimely)
Flow is neither ready nor proposed for wider deployment yet, so I do not understand your comment.
Other than its deployment to our test infrastructure, Flow has only been deployed to a very limited subset of pages (e.g. Wikiproject talk pages) by the explicit request of the people involved in maintaining those pages. Those deployments were invaluable for finding bugs, and were also generally well received by the people who requested the deployments.
Dan
On Aug 11, 2014 12:04 PM, "Dan Garry" dgarry@wikimedia.org wrote:
On 11 August 2014 10:56, Ricordisamoa ricordisamoa@openmailbox.org
wrote:
The same is going to happen for Flow (which I strongly believe is
needed,
but is being deployed untimely)
Flow is neither ready nor proposed for wider deployment yet, so I do not understand your comment.
I think this is where part of the problem lies. Will discussion on whether or not to deploy it to a local wiki still be possible when the WMF decides it is ready for wider deployment, with a possible no for an answer?
--Martijn
Other than its deployment to our test infrastructure, Flow has only been deployed to a very limited subset of pages (e.g. Wikiproject talk pages)
by
the explicit request of the people involved in maintaining those pages. Those deployments were invaluable for finding bugs, and were also
generally
well received by the people who requested the deployments.
Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11 August 2014 11:08, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
I think this is where part of the problem lies. Will discussion on whether or not to deploy it to a local wiki still be possible when the WMF decides it is ready for wider deployment, with a possible no for an answer?
I'm not in the senior management, so I don't have an answer to that question.
What I can tell you, as a person who is in charge of the day-to-day decisions about what goes into the software the WMF produces, is that the best time to make sure the software meets your needs is not at the step where it's being deployed, but as the step where it's being developed!
So, to make Flow meet your needs, get involved! Test the latest version of Flow (https://ee-flow.wmflabs.org). File bugs ( https://bugzilla.wikimedia.org). Take a look at the Flow team's Trello board (https://trello.com/b/lOh4XCy7/flow-sprint-f). Send the product manager of Flow an email (dhorn@wikimedia.org). Maybe even ask to have a hangout with him to discuss your concerns. Speaking from experience, this kind of feedback is one of the highest priority things a product manager can do. And this kind of contact shapes decisions, and shapes priorities.
This is the best way to be involved: early, and often.
Dan
Just a way more to contact flow (and others too) development (in addition to what Dan Garry wrote, which i can totally underline) is to go into IRC channel(s) [1]. Many developers are online in IRC, so you can ask, talk and discuss with them. Just as a note.
[1] https://meta.wikimedia.org/wiki/IRC/Channels#General_development_and_technic...
Freundliche Grüße / Kind regards Florian
-----Ursprüngliche Nachricht----- Von: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Dan Garry Gesendet: Montag, 11. August 2014 12:39 An: Wikimedia developers Betreff: Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you
On 11 August 2014 11:08, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
I think this is where part of the problem lies. Will discussion on whether or not to deploy it to a local wiki still be possible when the WMF decides it is ready for wider deployment, with a possible no for an answer?
I'm not in the senior management, so I don't have an answer to that question.
What I can tell you, as a person who is in charge of the day-to-day decisions about what goes into the software the WMF produces, is that the best time to make sure the software meets your needs is not at the step where it's being deployed, but as the step where it's being developed!
So, to make Flow meet your needs, get involved! Test the latest version of Flow (https://ee-flow.wmflabs.org). File bugs ( https://bugzilla.wikimedia.org). Take a look at the Flow team's Trello board (https://trello.com/b/lOh4XCy7/flow-sprint-f). Send the product manager of Flow an email (dhorn@wikimedia.org). Maybe even ask to have a hangout with him to discuss your concerns. Speaking from experience, this kind of feedback is one of the highest priority things a product manager can do. And this kind of contact shapes decisions, and shapes priorities.
This is the best way to be involved: early, and often.
Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Almost every WMF developer attended Wikimania this year, and there was quite a lot of fruitful discussion and feedback given. Somewhat surprisingly (to me, it was my first Wikimania) the tone in person was quite different than what you might expect from email list traffic. Perhaps that was self-selection, as the attendees at Wikimedia were the members of the community interested in constructively working on solutions.
But it's also worth noting that just about every Wikimania attendee is either traveling or on vacation today. The conversation on this thread might be a little lopsided as a result. --scott
"C. Scott Ananian" cananian@wikimedia.org wrote:
Almost every WMF developer attended Wikimania this year, and there was quite a lot of fruitful discussion and feedback given. Somewhat surprisingly (to me, it was my first Wikimania) the tone in person was quite different than what you might expect from email list traffic. Perhaps that was self-selection, as the attendees at Wikimedia were the members of the community interested in constructively working on solutions.
[...]
{{cn}}
Tim
On Mon, Aug 11, 2014 at 12:24 PM, Tim Landscheidt tim@tim-landscheidt.de wrote:
{{cn}}
More like the attendees were those who could afford to go and/or were given scholarship.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Aug 11, 2014 12:51 PM, "Tyler Romeo" tylerromeo@gmail.com wrote:
More like the attendees were those who could afford to go and/or were
given
scholarship.
Some people could afford to go if it were closer or can't take that much time off but if it happens to be nearby then they can come for a part at least.
So, we can't be close to everyone every year but we move around to different places each year and fill in the gaps with national conferences. (e.g. India, Netherlands and now USA too)
-Jeremy
On Aug 11, 2014 1:24 PM, "Tim Landscheidt" tim@tim-landscheidt.de wrote:
"C. Scott Ananian" cananian@wikimedia.org wrote:
Almost every WMF developer attended Wikimania this year, and there was quite a lot of fruitful discussion and feedback given. Somewhat surprisingly (to me, it was my first Wikimania) the tone in person was quite different than what you might expect from email list traffic.
Perhaps
that was self-selection, as the attendees at Wikimedia were the members
of
the community interested in constructively working on solutions.
[...]
{{cn}}
Tim
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I dont know which part you want cited... but i can also confirm that ancedotally people at wikimania were much more positive about certain feature developments than the general attitude online. What to make of this (whether its selection bias, or if online attitudes reflect just a vocal minority, or if people in real life are just more shy and dont want to get in a real world fight so they tell us what we think we want to hear, or if something else is the case. I dont know. All i know is it was surprising)
Otoh i encountered a number of people not thrilled over super protection (although still not as many as i would expect, all things considered)
--bawolff
Brian Wolff bawolff@gmail.com wrote:
Almost every WMF developer attended Wikimania this year, and there was quite a lot of fruitful discussion and feedback given. Somewhat surprisingly (to me, it was my first Wikimania) the tone in person was quite different than what you might expect from email list traffic.
Perhaps
that was self-selection, as the attendees at Wikimedia were the members
of
the community interested in constructively working on solutions.
[...]
{{cn}}
I dont know which part you want cited... but i can also confirm that ancedotally people at wikimania were much more positive about certain feature developments than the general attitude online.
The last subordinate clause. I highly doubt that all "mem- bers of the community interested in constructively working on solutions" were at Wikimania, leaving none elsewhere, and that all Wikimania attendees are "interested in construc- tively working on solutions" given that at least some were there at their employer's direction.
What to make of this(whether its selection bias, or if online attitudes reflect just a vocal minority, or if people in real life are just more shy and dont want to get in a real world fight so they tell us what we think we want to hear, or if something else is the case. I dont know. All i know is it was surprising)
[...]
As I wrote in http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/753...:
| [...]
| +1. In a physical meeting, there is higher bandwith, but a | lot of the payload can be pity, intimidation, "nobody leaves | before we have an agreement", etc.
Additionally, at a venue like Wikimania, most of the atten- dees are not there to "work", but take it as some form of "vacation", so there isn't much incentive to take a stand about something like Media Viewer, especially as in the end it is not up for discussion anyhow, so why bother?
Tim
Someone could also say the "coup d'état" has been done when too many people was traveling.
Anyway there are simply different views between many tech guys entusiasticly trying to push out new features and many people from the daily "community side" emphasizing need for partecipation and gradualness. None of the two views is absolutely wrong nor absolutly right. There's a periennial dialectic between them which can by broken by those muscular initiatives.
Vito
Inviato con AquaMail per Android http://www.aqua-mail.com
Il 11 agosto 2014 12:59:52 "C. Scott Ananian" cananian@wikimedia.org ha scritto:
Almost every WMF developer attended Wikimania this year, and there was quite a lot of fruitful discussion and feedback given. Somewhat surprisingly (to me, it was my first Wikimania) the tone in person was quite different than what you might expect from email list traffic. Perhaps that was self-selection, as the attendees at Wikimedia were the members of the community interested in constructively working on solutions.
But it's also worth noting that just about every Wikimania attendee is either traveling or on vacation today. The conversation on this thread might be a little lopsided as a result. --scott _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11 August 2014 10:56, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Why aren't they implementing a global repository for gadgets, modules, templates which is (IMHO) what the community needs first?
We are.
SUL finalisation (which is broadly a blocker to much of this work) is currently underway and should help make a lot of cross-cluster desired tools a great deal easier to build. This isn't the only piece of work, but it's been enough to discourage work on these areas for many years.
At Wikimania, a number of staff and volunteer developers re-started work on a global repository for gadgets. I was part of initial discussions around a global repository for source references with structured data stored on Wikibase somehow, and similar considerations for Wikiquote and Wikisource.
I'm sure lots of helpful follow-up e-mails, suggestions, RfCs and the like will be written in the next few weeks as people get back from the conference and have the time to communicate their work.
So… "we" are. But why aren't you, too? Development is and has always been a group effort. Patches welcome!
J.
Il 11/08/2014 12:27, James Forrester ha scritto:
On 11 August 2014 10:56, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Why aren't they implementing a global repository for gadgets, modules, templates which is (IMHO) what the community needs first?
We are.
SUL finalisation (which is broadly a blocker to much of this work) is currently underway and should help make a lot of cross-cluster desired tools a great deal easier to build. This isn't the only piece of work, but it's been enough to discourage work on these areas for many years.
At Wikimania, a number of staff and volunteer developers re-started work on a global repository for gadgets. I was part of initial discussions around a global repository for source references with structured data stored on Wikibase somehow, and similar considerations for Wikiquote and Wikisource.
I'm sure lots of helpful follow-up e-mails, suggestions, RfCs and the like will be written in the next few weeks as people get back from the conference and have the time to communicate their work.
So… "we" are. But why aren't you, too? Development is and has always been a group effort. Patches welcome!
J.
Good to see your efforts! Some time ago I proposed Global-Wiki https://meta.wikimedia.org/wiki/Global-Wiki, which has 28 interested people so far. And I make it a point to make my scripts and modules as localization-friendly as possible. But I would not support, e.g., forcing users to create a 'global' user page or intimidating sysops who keep their gadgets locally.
Good changes get always supported by the community, sooner or later. Sometimes you will have to speed them up, but you can't enforce them.
Il 11/08/2014 12:27, James Forrester ha scritto:
On 11 August 2014 10:56, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Why aren't they implementing a global repository for gadgets, modules, templates which is (IMHO) what the community needs first?
We are.
SUL finalisation (which is broadly a blocker to much of this work) is currently underway and should help make a lot of cross-cluster desired tools a great deal easier to build. This isn't the only piece of work, but it's been enough to discourage work on these areas for many years.
At Wikimania, a number of staff and volunteer developers re-started work on a global repository for gadgets. I was part of initial discussions around a global repository for source references with structured data stored on Wikibase somehow, and similar considerations for Wikiquote and Wikisource.
Where can I see any of that?
On 8/11/14, 5:11 PM, svetlana wrote:
Why aren't they implementing a global repository for gadgets, modules, templates which is (IMHO) what the community needs first?
We are.
SUL finalisation (which is broadly a blocker to much of this work) is currently underway and should help make a lot of cross-cluster desired tools a great deal easier to build. This isn't the only piece of work, but it's been enough to discourage work on these areas for many years.
At Wikimania, a number of staff and volunteer developers re-started work on a global repository for gadgets. I was part of initial discussions around a global repository for source references with structured data stored on Wikibase somehow, and similar considerations for Wikiquote and Wikisource.
Where can I see any of that?
The tracking bug for global gadgets (aka Gadgets 2.0) is https://bugzilla.wikimedia.org/show_bug.cgi?id=gadgets-2.0. If you want to take a look at the work in gerrit, https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/Gadgets+branch:RL2,n,z shows the patches happening in the "RL2" branch. We've also been making some changes to core in the process.
-- Legoktm
On Aug 11, 2014 7:58 AM, "svetlana" svetlana@fastmail.com.au wrote:
On Mon, 11 Aug 2014, at 19:56, Ricordisamoa wrote:
Why aren't they implementing a global repository for gadgets, modules, templates which is (IMHO) what the community needs first?
THANK YOU! you are, alone, worth a whole engineering team
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
With all due respect, fixing things is worth while. Complaining about things is easy.
Whatever you think about wmf priorities, engineering teams do actually fix things. So do many volunteers. Everyone is welcome to submit patches, and high quality patches from volunteers are accepted every day.
[This of course does not excuse wmf from doing controversial actions, just a please put your money where your mouth is comment if you want to call wmf engineers (who often arent even the ones making these desecions) useless]
--bawolff
Hi Gerard,
Some answers (in a random order).
2014-08-11 12:20 GMT+03:00 Gerard Meijssen gerard.meijssen@gmail.com:
You know our projects, you know our licenses. If you, the "community"do not like what you have, you can fork. At Wikimania forking and leaving the community was very much discussed. Watch Jimbo's presentation for instance, he may be aghast that I quote him here but in his state of the Wiki he made it abundantly clear that it is your option to stay or go.
I gave up watching Jimbo's keynotes a few years ago, as I would invariably get pissed off. So, should we understand that the vast ammounts of money and resources spent on editor retention are a waste of our money? I sincerely hope this is a heat-of-the-moment argument, just like the one about closing de.wp.
Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything.
Agreed. How about letting the WMF decide for anonymous users and the community decide for logged-in users? Presumably, the logged-in users have access to a large panel of options and can make up their own mind if they disagree with the consensus. Of course, discussions should not disappear because of such a separation, but even become more active and hopefully less aggressive.
When you are in those conversations you realise that many complications are considered; it is not easy nor obvious. NB there is not one community, there are many with often completely diverging opinions. Technically it is not possible to always keep backward compatibility / functionality. We are not backward we need to stay contemporary.
As a software engineer in a publicly traded company, I understand the reasoning behind more than 90% of the decisions made by the Engineering staff - and this worries me terribly, because they *don't* work for a company. Their objectives and approaches should be different.
There are three main wiki-use-cases that should receive similar levels of attention: * reading * basic editing * advanced editing
The first two receive a lot of love, but the third one not so much, it's even hindered by initiatives designed for the first two. I'm not saying that we should keep backwards compatibility forever, but since the WMF wants to deploy stuff early in order to get feedback, it should begin by offering it as a beta (they do that now), then, when reaching a decent level of stability, deploy it for anonymous users and opt-in users and only when it reaches feature-parity with the feature being replaced should it be pushed for everybody (keeping an opt-out feature for some time - months or a couple of years).
Take for instance the media viewer: the current version is useless for editors, as it has basically no controls visible by default (without scrolling). The future version, presented at Wikimania, has a lot more stuff visible on the first screen, making it much easier to use for editing. I believe that the media viewer should have been kept as opt-in for logged in users until this future version arrives.
Strainu
Hoi, When I watch Jimmy, it is a lot like Wikipedia. There is a lot I like but I do not like everything. This time was no different. However LIKE Wikipedia there is so much that I like that I will not abandon it.
The notion that the "community" is free to choose whatever negates the technical point that certain innovations are intended to NOT be backwards compatible. Choices are made all the time that are NOT backwards compatible, often it does not affect user land really and then there is supposed to be no problem. It is just a different public that "suffers" the consequences. At Wikimania the Wikidatafication of Commons was mentioned often and in many contexts. This needs to happen when we want to have multi lingual search and other goodie goodies that is the point of it all. In my understanding it is a game changer and it will change things more than what is being discussed at the moment.
I can see the Media Viewer as a precursor of these changes.
NB several of the proposals re Wikidatafication are imho a bit daft. However, the need for it is such that I prefer something that is half baked to start off with than nothing at all.
We disagree on the amount of attention that is given.. In my appreciation we do not invest in tools that affect readers that much and it only started fairly recently. It is the editors and even more so the admins / power users that have the most attention available to them. They often role their own tools and consequently are not assured of continued support for their tools. These more sophisticated users are often mistaken for the community. It certainly is the most vocal subgroup of our eco-system but it is not them we aim to serve.
I am not into second guessing what the WMF could or should do. I have opinions and they typically are about how and where I think we could do better. So my two pennies worth is that:
- Reasonator like functionality is our future for much of the information we have. - Wikipedia can have its sources but Wikidata, certainly for now, cannot be relied on having sources. Confidence is to be had by comparing the information it holds with other sources (including individual Wikipedias) - When our data is not used, we might be better off not having it.
Thanks, GerardM
On 12 August 2014 10:43, Strainu strainu10@gmail.com wrote:
Hi Gerard,
Some answers (in a random order).
2014-08-11 12:20 GMT+03:00 Gerard Meijssen gerard.meijssen@gmail.com:
You know our projects, you know our licenses. If you, the "community"do
not
like what you have, you can fork. At Wikimania forking and leaving the community was very much discussed. Watch Jimbo's presentation for
instance,
he may be aghast that I quote him here but in his state of the Wiki he
made
it abundantly clear that it is your option to stay or go.
I gave up watching Jimbo's keynotes a few years ago, as I would invariably get pissed off. So, should we understand that the vast ammounts of money and resources spent on editor retention are a waste of our money? I sincerely hope this is a heat-of-the-moment argument, just like the one about closing de.wp.
Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything.
Agreed. How about letting the WMF decide for anonymous users and the community decide for logged-in users? Presumably, the logged-in users have access to a large panel of options and can make up their own mind if they disagree with the consensus. Of course, discussions should not disappear because of such a separation, but even become more active and hopefully less aggressive.
When you are in those conversations you realise that many complications are considered; it is not easy nor obvious. NB there is not one community, there are many with often completely diverging opinions. Technically it is not possible to always keep
backward
compatibility / functionality. We are not backward we need to stay contemporary.
As a software engineer in a publicly traded company, I understand the reasoning behind more than 90% of the decisions made by the Engineering staff - and this worries me terribly, because they *don't* work for a company. Their objectives and approaches should be different.
There are three main wiki-use-cases that should receive similar levels of attention:
- reading
- basic editing
- advanced editing
The first two receive a lot of love, but the third one not so much, it's even hindered by initiatives designed for the first two. I'm not saying that we should keep backwards compatibility forever, but since the WMF wants to deploy stuff early in order to get feedback, it should begin by offering it as a beta (they do that now), then, when reaching a decent level of stability, deploy it for anonymous users and opt-in users and only when it reaches feature-parity with the feature being replaced should it be pushed for everybody (keeping an opt-out feature for some time - months or a couple of years).
Take for instance the media viewer: the current version is useless for editors, as it has basically no controls visible by default (without scrolling). The future version, presented at Wikimania, has a lot more stuff visible on the first screen, making it much easier to use for editing. I believe that the media viewer should have been kept as opt-in for logged in users until this future version arrives.
Strainu
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Straniu, Jimbo's comments in his keynote about forking concerned encouraging competent editors who can't work cooperatively with other people to fork in a way that would be better for everyone in the long run. I don't believe this disappointing confrontation between the WMF and volunteers were what Jimbo had in mind.
Pine On Aug 12, 2014 1:44 AM, "Strainu" strainu10@gmail.com wrote:
Hi Gerard,
Some answers (in a random order).
2014-08-11 12:20 GMT+03:00 Gerard Meijssen gerard.meijssen@gmail.com:
You know our projects, you know our licenses. If you, the "community"do
not
like what you have, you can fork. At Wikimania forking and leaving the community was very much discussed. Watch Jimbo's presentation for
instance,
he may be aghast that I quote him here but in his state of the Wiki he
made
it abundantly clear that it is your option to stay or go.
I gave up watching Jimbo's keynotes a few years ago, as I would invariably get pissed off. So, should we understand that the vast ammounts of money and resources spent on editor retention are a waste of our money? I sincerely hope this is a heat-of-the-moment argument, just like the one about closing de.wp.
Hoi, Code review should be a strictly technical process surely. However the community CANNOT decide on everything.
Agreed. How about letting the WMF decide for anonymous users and the community decide for logged-in users? Presumably, the logged-in users have access to a large panel of options and can make up their own mind if they disagree with the consensus. Of course, discussions should not disappear because of such a separation, but even become more active and hopefully less aggressive.
When you are in those conversations you realise that many complications are considered; it is not easy nor obvious. NB there is not one community, there are many with often completely diverging opinions. Technically it is not possible to always keep
backward
compatibility / functionality. We are not backward we need to stay contemporary.
As a software engineer in a publicly traded company, I understand the reasoning behind more than 90% of the decisions made by the Engineering staff - and this worries me terribly, because they *don't* work for a company. Their objectives and approaches should be different.
There are three main wiki-use-cases that should receive similar levels of attention:
- reading
- basic editing
- advanced editing
The first two receive a lot of love, but the third one not so much, it's even hindered by initiatives designed for the first two. I'm not saying that we should keep backwards compatibility forever, but since the WMF wants to deploy stuff early in order to get feedback, it should begin by offering it as a beta (they do that now), then, when reaching a decent level of stability, deploy it for anonymous users and opt-in users and only when it reaches feature-parity with the feature being replaced should it be pushed for everybody (keeping an opt-out feature for some time - months or a couple of years).
Take for instance the media viewer: the current version is useless for editors, as it has basically no controls visible by default (without scrolling). The future version, presented at Wikimania, has a lot more stuff visible on the first screen, making it much easier to use for editing. I believe that the media viewer should have been kept as opt-in for logged in users until this future version arrives.
Strainu
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 10-08-2014 15:35, svetlana wrote:
This change solves a problem that does not exist. We either trust sysops, or we don't.
I concur. There are enough admins available to revert bad code additions. Also, this measure is completely without effect.
*Suppose* I were a rogue admin wanting to add some bad code to common.js that disables some WMF feature; I will be reverted by staff and common.js is superprotected.
Oh well, I'll just create a hidden default gadget... Happy hunting!
Regards,
This seems like an unfortunate escalation on the WMF's part. Both sides have a responsibility to try to work together, but as a practical matter, the community does not answer to a single person, and the WMF staff do: it's likely that the first olive branch is going to need to come from the WMF side.
Erwin Dokter wrote:
On 10-08-2014 15:35, svetlana wrote:
This change solves a problem that does not exist. We either trust sysops, or we don't.
I concur. There are enough admins available to revert bad code additions. Also, this measure is completely without effect.
*Suppose* I were a rogue admin wanting to add some bad code to common.js that disables some WMF feature; I will be reverted by staff and common.js is superprotected.
Oh well, I'll just create a hidden default gadget... Happy hunting!
Page protection doesn't persist if you delete and restore the page, as a German Wikipedia admin has now pointed out with "MediaWiki:Common.js".
I agree with svetlana as well: the security of the entire MediaWiki infrastructure, which in turn is the security of a large portion of Wikimedia wikis, relies on the idea that local administrators can be trusted. Erik has now personally re-super-protected "MediaWiki:Common.js" and he continues to stoke the fires of war with the German Wikipedia.
MZMcBride
Op 10 aug. 2014 om 20:12 heeft Ricordisamoa ricordisamoa@openmailbox.org het volgende geschreven:
<hopeless>I'd really like to hear Jimbo's opinion on the matter</hopeless>
You should really watch Jimmy's speech at the Wikimania closing session. You might be surprised.
Cheers!
-- Siebrand
Wow this is pretty depressing, although in today's age I cannot say I'm surprised. Corporations have always been about controlling their consumers, and it was really only a matter of time before the WMF fell into that as well. I wonder whether there's any legitimate justification for all of this, or whether it's just a repeat of the VisualEditor fiasco, aka, "the WMF knows best" kind of thing.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Sun, Aug 10, 2014 at 3:19 PM, Siebrand Mazeland siebrand@kitano.nl wrote:
Op 10 aug. 2014 om 20:12 heeft Ricordisamoa <
ricordisamoa@openmailbox.org> het volgende geschreven:
<hopeless>I'd really like to hear Jimbo's opinion on the
matter</hopeless>
You should really watch Jimmy's speech at the Wikimania closing session. You might be surprised.
Cheers!
-- Siebrand _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sun, Aug 10, 2014 at 3:12 PM, Ricordisamoa ricordisamoa@openmailbox.org wrote:
<hopeless>I'd really like to hear Jimbo's opinion on the matter</hopeless>
A few years ago, Jimbo came by en.wn, and we were trying to explain to him how our project infrastructure works. Understand, a central part of our concept at en.wn is that the community chooses reviewers in whom we place an enormous amount of trust. Of course I can't know what the exchange looked like from Jimbo's side, but from where I was sitting, it appeared that as we were explaining to him how this works, at first he was incredulous we were actually putting that much trust in the hands of users merely selected by the community, and then, when he did realize what we were entrusting to reviewers, he reckoned we had to be insane. As I say, I don't know what it looked like from his perspective; but it sure did look like that from mine.
This attitude, of not trusting the community to select people worthy of trust, seems to be a sort of conceptual trap, that's easy to fall into, probably without even noticing, and hard to get out of. One suspects it's got a bunch of folks at the Foundation in its grip. It makes a striking contrast with "assume good faith" --- mind you, I don't subscribe to AGF, in fact at en.wn we have instead "Never assume"; but one of the subtler reasons I disapprove of AGF is that I think it actually transmutes, in practice, into "trust no-one".
Pi zero
Is wikitech-l really the best place for this discussion?
-- Lewis Cawte (Lcawte)
On 11 August 2014 18:44, pi zero wn.pi.zero@gmail.com wrote:
On Sun, Aug 10, 2014 at 3:12 PM, Ricordisamoa < ricordisamoa@openmailbox.org> wrote:
<hopeless>I'd really like to hear Jimbo's opinion on the
matter</hopeless>
A few years ago, Jimbo came by en.wn, and we were trying to explain to him how our project infrastructure works. Understand, a central part of our concept at en.wn is that the community chooses reviewers in whom we place an enormous amount of trust. Of course I can't know what the exchange looked like from Jimbo's side, but from where I was sitting, it appeared that as we were explaining to him how this works, at first he was incredulous we were actually putting that much trust in the hands of users merely selected by the community, and then, when he did realize what we were entrusting to reviewers, he reckoned we had to be insane. As I say, I don't know what it looked like from his perspective; but it sure did look like that from mine.
This attitude, of not trusting the community to select people worthy of trust, seems to be a sort of conceptual trap, that's easy to fall into, probably without even noticing, and hard to get out of. One suspects it's got a bunch of folks at the Foundation in its grip. It makes a striking contrast with "assume good faith" --- mind you, I don't subscribe to AGF, in fact at en.wn we have instead "Never assume"; but one of the subtler reasons I disapprove of AGF is that I think it actually transmutes, in practice, into "trust no-one".
Pi zero _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Aug 11, 2014 at 1:56 PM, Lewis Cawte lewiscawte@googlemail.com wrote:
Is wikitech-l really the best place for this discussion?
-- Lewis Cawte (Lcawte)
Perhaps not. I'd actually replied to the message, and didn't even notice which list it was on.
Pi zero
No, it is not. Unless we are continuing to discuss the technical implications of this change, I suggest this be moved to wikimedia-l.
Also, can we please stop using Wikipedia templates in this thread (e.g., {{cc}}). Not everybody here is a Wikipedia editor and knows what they mean. I’d prefer not to have to look up templates online just to figure it out. -- Tyler Romeo 0x405D34A7C86B42DF
From: Lewis Cawte lewiscawte@googlemail.com Reply: Wikimedia developers wikitech-l@lists.wikimedia.org> Date: August 11, 2014 at 13:56:11 To: Wikimedia developers wikitech-l@lists.wikimedia.org> Subject: Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you
Is wikitech-l really the best place for this discussion?
-- Lewis Cawte (Lcawte)
Superprotect is a feature, the way it will be used must be determined by consensus, on a theoretical basis there are different possible good uses. But, anyway, anyone using this feature should be accountable to the community, like anyone holding any advanced rights.
Vito
Inviato con AquaMail per Android http://www.aqua-mail.com
Il 10 agosto 2014 20:01:19 Erwin Dokter erwin@darcoury.nl ha scritto:
On 10-08-2014 15:35, svetlana wrote:
This change solves a problem that does not exist. We either trust sysops, or we don't.
I concur. There are enough admins available to revert bad code additions. Also, this measure is completely without effect.
*Suppose* I were a rogue admin wanting to add some bad code to common.js that disables some WMF feature; I will be reverted by staff and common.js is superprotected.
Oh well, I'll just create a hidden default gadget... Happy hunting!
Regards,
Erwin Dokter
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
So I'd just like to make one point, I think this "superprotect" right has proper technical implications and use cases. In other words, while you guys may disagree with how it is currently being used (e.g., the MediaViewer drama and whatnot), I think it is a good idea, and I am actually surprised such a protection level has not already been enacted.
There are many legitimate cases (e.g., office actions and copyright-related issues) where I could see the superprotect level coming in handy. There are some cases where the WMF simply cannot afford (usually b/c of legal reasons) to trust the community, even if they're 99.9% sure nothing will happen. Sometimes all it takes is one rogue admin to trigger a lawsuit.
With that said, it's obviously a political matter as to what the proper uses of this new protection level are, but I do think the existence of the level itself is appropriate.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Sun, Aug 10, 2014 at 9:19 AM, K. Peachey p858snake@gmail.com 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. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11/08/14 16:54, Tyler Romeo wrote:
There are many legitimate cases (e.g., office actions and copyright-related issues) where I could see the superprotect level coming in handy. There are some cases where the WMF simply cannot afford (usually b/c of legal reasons) to trust the community, even if they're 99.9% sure nothing will happen. Sometimes all it takes is one rogue admin to trigger a lawsuit.
With that said, it's obviously a political matter as to what the proper uses of this new protection level are, but I do think the existence of the level itself is appropriate.
But copyright- and performance-related issues don't need superprotection. As administrators, we need to understand the importance of these things (or just avoid them). Should we try to go against such, that would be a more appropriate time for a blocking and/or deopping, not page protection.
Similarly, if the WMF cannot afford to trust the community, that's not a technical problem. That's a problem with a lack of understanding of what it means to run a wiki (nevermind several hundred), because if it can be edited, 'something' can and will happen. Lawsuits do happen. Perfomance hits due to bad gadgets etc do happen. They are resolved as they come up.
I just don't see how such a right could ever be useful in the hands of staff, especially in light of the trouble it causes.
That being said, it's not that superprotection couldn't be useful elsewhere, indeed. Consider stewards - say there is a dispute between a bunch of admins and it needs sorting out, so protecting the page to prevent further damage while doing the actual sorting could simplify things a bit. Even then, though, it's hardly necessary, since you can also just chuck the specific folks out the window as they show up, but options can be nice, perhaps.
-I
wikitech-l@lists.wikimedia.org