Hi all.
I understand the Engineering folks used superprotect instead of /undoing/ the edit and adding 'This is a WMF action.' in edit summary. Could I please be enlightened on the reasoning behind that?
I suppose people could go and try editing other JS pages and cause havoc, but that's still possible where superprotect only affects a single page and not a namespace. Or can entire namespaces be protected and this new user right was intended to be able to prevent that easily?
Svetlana.
Hi all,
I'm sorry to repeat, but I would like to hear some thoughts on this question. Also added a clarification for one of the lines.
On Thu, 21 Aug 2014, at 22:26, svetlana wrote:
Hi all.
I understand the Engineering folks used superprotect instead of /undoing/ the edit and adding 'This is a WMF action.' in edit summary. Could I please be enlightened on the reasoning behind that?
I suppose people could go and try editing other JS pages and cause havoc, but that's still possible where superprotect only affects a single page and not a namespace. Or can entire namespaces be protected and this new user right was intended to be able to prevent that easily?
This is worded poorly, I mean - "or can entire namespaces be protected and the new user right was intended as a means to easily revoke mediawiki:* access?
Svetlana.
svetlana
I think the problem is that your question does not really relate to the subject line, Svetlana. Office actions are specifically directed at content (e.g., removal of specific content for copyvio reasons or court orders). Office actions are almost never undertaken by Engineering staff; it's usually Legal & Community Advocacy staff, or rarely another administrative staff member.
What you are talking about is something that has only been done very occasionally over the years by Engineering/Operations staff/sysadmins. There has been no designated manner in which those actions should be flagged. One must remember that until the last few years, the majority of individuals who could have taken (and in some cases, did take) such serious action were volunteer sysadmins, so labeling it a "WMF action" would not have been correct. We also have to remember that many of the systems that developers and engineers work with on a daily basis do not permit edit summaries, so adding what for many of us is an automatic and routine comment is for some of them a rare and unusual event. (Perhaps they should set their work account preferences to be "reminded" to include an edit summary?)
Risker/Anne
On 22 August 2014 11:50, svetlana svetlana@fastmail.com.au wrote:
Hi all,
I'm sorry to repeat, but I would like to hear some thoughts on this question. Also added a clarification for one of the lines.
On Thu, 21 Aug 2014, at 22:26, svetlana wrote:
Hi all.
I understand the Engineering folks used superprotect instead of
/undoing/ the edit and adding 'This is a WMF action.' in edit summary. Could I please be enlightened on the reasoning behind that?
I suppose people could go and try editing other JS pages and cause
havoc, but that's still possible where superprotect only affects a single page and not a namespace. Or can entire namespaces be protected and this new user right was intended to be able to prevent that easily?
This is worded poorly, I mean - "or can entire namespaces be protected and the new user right was intended as a means to easily revoke mediawiki:* access?
Svetlana.
svetlana
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Risker wrote:
Office actions are almost never undertaken by Engineering staff; it's usually Legal & Community Advocacy staff, or rarely another administrative staff member.
How should an Engineering Staff member indicate that he'd like an edit undone and not done again? Through an Office Action? One'd think that an edit summary is the only way. Why is it not being used?
An undo with appropriate edit summary would also avoid a need in escalating the issue - local sysops would consciously hold off their edit. If they went against an office action, introducing superprotect /then/ could make sense (although I would personally iterate through 2 undos with a massive warning in the second one).
Now, in your reply, why do I fail to see a reason why such approach was or is not used? Could you please clarify?
Risker wrote:
What you are talking about is something that has only been done very occasionally over the years by Engineering/Operations staff/sysadmins. There has been no designated manner in which those actions should be flagged.
This doesn't appear to be a problem to me. Sysops surely read edit summaries. (Note how Erik doesn't use a (WMF) account either - he wrote a message and appended 'this is a wmf action' to the end, which /WAS ENOUGH/.
Risker wrote:
One must remember that until the last few years, the majority of individuals who could have taken (and in some cases, did take) such serious action were volunteer sysadmins, so labeling it a "WMF action" would not have been correct.
OK, some context - doesn't really apply to this case. In this case it was not a volunteer sysadmin.
Risker wrote:
We also have to remember that many of the systems that developers and engineers work with on a daily basis do not permit edit summaries, so adding what for many of us is an automatic and routine comment is for some of them a rare and unusual event. (Perhaps they should set their work account preferences to be "reminded" to include an edit summary?)
"Our Eng Staff don't know how to use wiki software" is perhaps a way to tell why they "forgot to do it", but it doesn't mean that doing it wouldn't've been a good idea.
I might perhaps even suggest going and removing superprotect, and actually going and using an edit summary /instead/, now. It's late, but better late then never.
svetlana
On Fri, Aug 22, 2014 at 10:53 PM, svetlana svetlana@fastmail.com.au wrote:
An undo with appropriate edit summary would also avoid a need in escalating the issue - local sysops would consciously hold off their edit. If they went against an office action, introducing superprotect /then/ could make sense
Note that's exactly what was tried in the dewiki situation. The first WMF revert[1] refers to a warning on the talk page[2] that (according to Google Translate, and Erik's later statements) seems to basically say "Please don't do this again. Otherwise we might have to remove the editability of this page."
But the local sysop didn't hold off; according to Google Translate he replied "With threats you will achieve nothing."
[1]: https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=1329... [2]: https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&am...
On Sun, 24 Aug 2014, at 07:02, Brad Jorsch (Anomie) wrote:
On Fri, Aug 22, 2014 at 10:53 PM, svetlana svetlana@fastmail.com.au wrote:
An undo with appropriate edit summary would also avoid a need in escalating the issue - local sysops would consciously hold off their edit. If they went against an office action, introducing superprotect /then/ could make sense
Note that's exactly what was tried in the dewiki situation. The first WMF revert[1] refers to a warning on the talk page[2] that (according to Google Translate, and Erik's later statements) seems to basically say "Please don't do this again. Otherwise we might have to remove the editability of this page."
But the local sysop didn't hold off; according to Google Translate he replied "With threats you will achieve nothing."
And then they draw comics stating that that's WMF's fault? https://meta.wikimedia.org/wiki/File:WMF_building_wiki_wall_in_August_2014_c...
What a wonderful community (clique of active editors and sysops) we have.
svetlana
On Sun, Aug 24, 2014 at 1:48 AM, svetlana svetlana@fastmail.com.au wrote:
And then they draw comics stating that that's WMF's fault? https://meta.wikimedia.org/wiki/File:WMF_building_wiki_wall_in_August_2014_c...
What a wonderful community (clique of active editors and sysops) we have.
Svetlana,
With a whole week left in August, you've managed to hit 30 posts (actually more, if you count those made with your previous address) in the span of a month. The reason is fairly obvious, given the number that, like this one, are purely rhetorical.
I've temporarily flagged your address for moderation, and will let more carefully considered posts through as they come.
Everyone else should refer to my recent e-mail reminding everyone of the post limit and why it exists, and perhaps check http://www.infodisiac.com/Wikipedia/ScanMail/Wikimedia-l.html to see your current tally.
Best,
Austin
On Sun, 24 Aug 2014, at 07:02, Brad Jorsch (Anomie) wrote:
On Fri, Aug 22, 2014 at 10:53 PM, svetlana svetlana@fastmail.com.au wrote:
An undo with appropriate edit summary would also avoid a need in escalating the issue - local sysops would consciously hold off their edit. If they went against an office action, introducing superprotect /then/ could make sense
Note that's exactly what was tried in the dewiki situation. The first WMF revert[1] refers to a warning on the talk page[2] that (according to Google Translate, and Erik's later statements) seems to basically say "Please don't do this again. Otherwise we might have to remove the editability of this page."
But the local sysop didn't hold off; according to Google Translate he replied "With threats you will achieve nothing."
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation
By the way, while there is a downside to what the folks did (as in, edit war and insist on stuff), I suppose it's partly justified by the thing being a first point in time where a local consencus was considered insufficient.
I took some notes of this, and possible solutions, on this draft essay: https://meta.wikimedia.org/wiki/Regaining_trust_in_local_consencus
I expect that superprotect is just a consequence of such missing trust; once the trust is regained, there is no need in superprotect in principle.
svetlana
wikimedia-l@lists.wikimedia.org