Hello everyone,
For a long time now, we have had the default behaviour of admins can unblock themselves if blocked.
In my opinion, this is a poor default. In the event of a compromised admin account, the compromised account can just unblock themselves and continue being malicious.
To that end, and in light of some recent admin accounts being compromised, we now disallow admins to unblock themselves. This doesn't apply to self blocks - Admins who block themselves can still unblock themselves. However admins who are blocked by other admins can no longer unblock themselves.
I'm still open to communities who want to continue to have the old behaviour to opt out of the new behaviour - The primary thing here is that the default has now changed, so that anywhere that was using the old behaviour for no other reason then it was the default is now using the new behaviour.
-- Brian Wolff ([[User:BWolff_(WMF)]]) Wikimedia Security Team
Brian Wolff, 27/11/18 18:45:
I'm still open to communities who want to continue to have the old behaviour to opt out of the new behaviour - The primary thing here is that the default has now changed, so that anywhere that was using the old behaviour for no other reason then it was the default is now using the new behaviour.
The problem with this is that the right to unblock yourself is clearly something of use in unforeseen emergencies, not something for which you'd usually write up a consensus discussion or a guideline 5 years in advance.
I understand the feeling of urgency in doing such changes by fiat in response to apparent threats, but I hope you do appreciate the potential for such permission changes to alter the power structure and social workings of the wikis in ways we don't fully anticipate. This change may seem small, but it does dismantle one component of the reciprocality of administrative powers on the wiki. https://meta.wikimedia.org/wiki/Administrator
In particular, such a new default means, on wikis with 2 sysops, that one sysop has the capacity to unilaterally and irreversibly block the second sysop, and that in any last-resort controversy the permissions encourage and give a prize to whoever shoots first. (Which is already a common problem in online communities, see StackExchange with their "fastest gun in the west" dilemma.)
I think it would be wise for such a default to be changed only on wikis which have at least 3 administrators *and* a bureaucrat.
Federico
On Wed, Nov 28, 2018 at 4:34 PM Federico Leva (Nemo) nemowiki@gmail.com wrote:
Brian Wolff, 27/11/18 18:45:
I'm still open to communities who want to continue to have the old behaviour to opt out of the new behaviour - The primary thing here is that the default has now changed, so that anywhere that was using the old behaviour for no other reason then it was the default is now using the new behaviour.
The problem with this is that the right to unblock yourself is clearly something of use in unforeseen emergencies, not something for which you'd usually write up a consensus discussion or a guideline 5 years in advance.
I understand the feeling of urgency in doing such changes by fiat in response to apparent threats, but I hope you do appreciate the potential for such permission changes to alter the power structure and social workings of the wikis in ways we don't fully anticipate. This change may seem small, but it does dismantle one component of the reciprocality of administrative powers on the wiki. https://meta.wikimedia.org/wiki/Administrator
In particular, such a new default means, on wikis with 2 sysops, that one sysop has the capacity to unilaterally and irreversibly block the second sysop, and that in any last-resort controversy the permissions encourage and give a prize to whoever shoots first. (Which is already a common problem in online communities, see StackExchange with their "fastest gun in the west" dilemma.)
I think it would be wise for such a default to be changed only on wikis which have at least 3 administrators *and* a bureaucrat.
There's an ongoing discussion about reaching out to wikis and ask them if this will be a problem, and how to solve the problem of one admin blocking the other(s) on small wikis, in this Phabricator task: https://phabricator.wikimedia.org/T150826
//Johan Jönsson --
Well said Nemo Bis. There is an ever increasing autocratic approach to what used to be community decisions. Societall matters used to be discussed openly on wiki, or in list, then to have the technical components on phabricator. Now it seems that the societal are taking place in phabricator, away from the society and predominantly with the technical. That is undesirable IMNSHO.
I would think that the easiest and means to apply this is for large wikis only, and run some checks on the medium sized wikis to understand the size of the issue, and the consequences prior to implementation. Leave the small wikis alone.
-- billinghurst
------ Original Message ------ From: "Johan Jönsson" jjonsson@wikimedia.org To: "Wikitech Ambassadors" wikitech-ambassadors@lists.wikimedia.org Sent: 29/11/2018 3:06:34 AM Subject: Re: [Wikitech-ambassadors] Removal of unblockself rights on wiki
On Wed, Nov 28, 2018 at 4:34 PM Federico Leva (Nemo) nemowiki@gmail.com wrote:
Brian Wolff, 27/11/18 18:45:
I'm still open to communities who want to continue to have the old behaviour to opt out of the new behaviour - The primary thing here
is
that the default has now changed, so that anywhere that was using
the
old behaviour for no other reason then it was the default is now
using
the new behaviour.
The problem with this is that the right to unblock yourself is clearly something of use in unforeseen emergencies, not something for which you'd usually write up a consensus discussion or a guideline 5 years in advance.
I understand the feeling of urgency in doing such changes by fiat in response to apparent threats, but I hope you do appreciate the potential for such permission changes to alter the power structure and social workings of the wikis in ways we don't fully anticipate. This change may seem small, but it does dismantle one component of the reciprocality of administrative powers on the wiki. https://meta.wikimedia.org/wiki/Administrator
In particular, such a new default means, on wikis with 2 sysops, that one sysop has the capacity to unilaterally and irreversibly block the second sysop, and that in any last-resort controversy the permissions encourage and give a prize to whoever shoots first. (Which is already a common problem in online communities, see StackExchange with their "fastest gun in the west" dilemma.)
I think it would be wise for such a default to be changed only on wikis which have at least 3 administrators *and* a bureaucrat.
There's an ongoing discussion about reaching out to wikis and ask them if this will be a problem, and how to solve the problem of one admin blocking the other(s) on small wikis, in this Phabricator task: https://phabricator.wikimedia.org/T150826
//Johan Jönsson
I agree with what's been said in this thread so far.
An admin of a large wiki shouldn't be allowed to unblock themselves, if another admin blocked them.
However, on small wikis, this would lead to a first-mover advantage situation, so admins should be forbidden from unblocking themselves if there are more than a certain number of admins (and bureaucrats).
I would recommend a threshold of five admins. Notice that if there are only three admins (with Nemo's proposal), if one admin blocks another admin, the situation reduces to a "shoot first to win" between the two remaining admins. If there are five admins and one blocks another, there will still be three uninvolved admins left to argue it out :)
The Cantonese Wikipedia recently came close to a situation where an admin might get blocked for bad behaviour. A few users presented a strong case that an admin had been acting against policy. Because we have a dozen admins, a few other admins were able to discuss the matter, and issued strong words of admonishment to the unbehaving admin, and the unbehaving admin disappeared from the wiki since then. Thinking back, one of the concerns we had was that an admin could unblock themselves anyway, so there was actually no real course of action to take other than desysopping (we have a bureaucrat; not me). If this feature of "no self-unblocks on wikis with lots of admins" was in place, then the threat of a block would have had more teeth.
Deryck ([[User:Deryck Chan]], yue.wp sysop)
On Thu, 29 Nov 2018 at 12:32, billinghurst billinghurstwiki@gmail.com wrote:
Well said Nemo Bis. There is an ever increasing autocratic approach to what used to be community decisions. Societall matters used to be discussed openly on wiki, or in list, then to have the technical components on phabricator. Now it seems that the societal are taking place in phabricator, away from the society and predominantly with the technical. That is undesirable IMNSHO.
I would think that the easiest and means to apply this is for large wikis only, and run some checks on the medium sized wikis to understand the size of the issue, and the consequences prior to implementation. Leave the small wikis alone.
-- billinghurst
------ Original Message ------ From: "Johan Jönsson" jjonsson@wikimedia.org To: "Wikitech Ambassadors" wikitech-ambassadors@lists.wikimedia.org Sent: 29/11/2018 3:06:34 AM Subject: Re: [Wikitech-ambassadors] Removal of unblockself rights on wiki
On Wed, Nov 28, 2018 at 4:34 PM Federico Leva (Nemo) nemowiki@gmail.com wrote:
Brian Wolff, 27/11/18 18:45:
I'm still open to communities who want to continue to have the old behaviour to opt out of the new behaviour - The primary thing here is that the default has now changed, so that anywhere that was using the old behaviour for no other reason then it was the default is now using the new behaviour.
The problem with this is that the right to unblock yourself is clearly something of use in unforeseen emergencies, not something for which you'd usually write up a consensus discussion or a guideline 5 years in advance.
I understand the feeling of urgency in doing such changes by fiat in response to apparent threats, but I hope you do appreciate the potential for such permission changes to alter the power structure and social workings of the wikis in ways we don't fully anticipate. This change may seem small, but it does dismantle one component of the reciprocality of administrative powers on the wiki. https://meta.wikimedia.org/wiki/Administrator
In particular, such a new default means, on wikis with 2 sysops, that one sysop has the capacity to unilaterally and irreversibly block the second sysop, and that in any last-resort controversy the permissions encourage and give a prize to whoever shoots first. (Which is already a common problem in online communities, see StackExchange with their "fastest gun in the west" dilemma.)
I think it would be wise for such a default to be changed only on wikis which have at least 3 administrators *and* a bureaucrat.
There's an ongoing discussion about reaching out to wikis and ask them if this will be a problem, and how to solve the problem of one admin blocking the other(s) on small wikis, in this Phabricator task: https://phabricator.wikimedia.org/T150826
//Johan Jönsson
Wikitech-ambassadors mailing list Wikitech-ambassadors@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
On Thu, Dec 13, 2018 at 8:20 PM Deryck Chan deryckchan@gmail.com wrote:
I agree with what's been said in this thread so far.
An admin of a large wiki shouldn't be allowed to unblock themselves, if another admin blocked them.
However, on small wikis, this would lead to a first-mover advantage situation, so admins should be forbidden from unblocking themselves if there are more than a certain number of admins (and bureaucrats).
I would recommend a threshold of five admins. Notice that if there are only three admins (with Nemo's proposal), if one admin blocks another admin, the situation reduces to a "shoot first to win" between the two remaining admins. If there are five admins and one blocks another, there will still be three uninvolved admins left to argue it out :)
The Cantonese Wikipedia recently came close to a situation where an admin might get blocked for bad behaviour. A few users presented a strong case that an admin had been acting against policy. Because we have a dozen admins, a few other admins were able to discuss the matter, and issued strong words of admonishment to the unbehaving admin, and the unbehaving admin disappeared from the wiki since then. Thinking back, one of the concerns we had was that an admin could unblock themselves anyway, so there was actually no real course of action to take other than desysopping (we have a bureaucrat; not me). If this feature of "no self-unblocks on wikis with lots of admins" was in place, then the threat of a block would have had more teeth.
Just to keep everyone aware of what's been happening in https://phabricator.wikimedia.org/T150826 – to avoid the "shoot first to win" situation, a blocked admin can block the admin who blocked them but no one else. Our balance of terror.
//Johan Jönsson --
Call me a simpleton, though sometimes I wonder whether we have the technical team of WMF staff and developers trying to get ahead of (around?) society, and societal models.
The societal model that the wikis have implemented is a thing called a bureaucrat, their role is to implement the change of status of members of the community. Soooo how about we go back and investigate utilising that model with regard to this matter?
Please explain in the current deliberations that there was the consideration for how the community's existing model of rights utilising bureaucrats? I just see a technical implementation, primarily focusing around a single wiki.
This is and will always be a community issue, and I look forward to seeing this more broadly proposed and discussed at Metawiki. Not stuck here in a small email forum for ambassadors. Not stuck in a phabricator ticket in the back of nowhere. I look forward to this being open to the whole community, not one particularly controlled by developers and staff of WMF. That has been the wiki way through times, though not in more recent times where we have what is this approach to more technical-only solutions, and divorced from the broader wiki community.
This is a societal issue, and the technical team should be developing the tools that the society needs to manage. It needs to come out of Phabricator for the community discussion. It needs to come out of the limited scope of this mailing list. This is not about operating in your comfort zone.
Yes, the community is noisy, and has a diversity of opinion, and one that will take time to reach a consensus. Yes, it is not our technical peoples general skill set, so we have others moderate the conversation. This is not solely a technical problem, get over it.
-- billinghurst
------ Original Message ------ From: "Johan Jönsson" jjonsson@wikimedia.org To: "Wikitech Ambassadors" wikitech-ambassadors@lists.wikimedia.org Sent: 14/12/2018 6:25:59 AM Subject: Re: [Wikitech-ambassadors] Removal of unblockself rights on wiki
On Thu, Dec 13, 2018 at 8:20 PM Deryck Chan deryckchan@gmail.com wrote:
I agree with what's been said in this thread so far.
An admin of a large wiki shouldn't be allowed to unblock themselves, if another admin blocked them.
However, on small wikis, this would lead to a first-mover advantage situation, so admins should be forbidden from unblocking themselves if there are more than a certain number of admins (and bureaucrats).
I would recommend a threshold of five admins. Notice that if there are only three admins (with Nemo's proposal), if one admin blocks another admin, the situation reduces to a "shoot first to win" between the two remaining admins. If there are five admins and one blocks another, there will still be three uninvolved admins left to argue it out :)
The Cantonese Wikipedia recently came close to a situation where an admin might get blocked for bad behaviour. A few users presented a strong case that an admin had been acting against policy. Because we have a dozen admins, a few other admins were able to discuss the matter, and issued strong words of admonishment to the unbehaving admin, and the unbehaving admin disappeared from the wiki since then. Thinking back, one of the concerns we had was that an admin could unblock themselves anyway, so there was actually no real course of action to take other than desysopping (we have a bureaucrat; not me). If this feature of "no self-unblocks on wikis with lots of admins" was in place, then the threat of a block would have had more teeth.
Just to keep everyone aware of what's been happening in https://phabricator.wikimedia.org/T150826 – to avoid the "shoot first to win" situation, a blocked admin can block the admin who blocked them but no one else. Our balance of terror.
//Johan Jönsson
After learning about yet another case of WMF forcing down changes without discussion (bad MediaWiki 2FA implementation being mandatory for certain roles), I can only endorse it in its entirety.
Something is rotten in the way changes are being discussed and communicated, and it must be fixed. The approach to major changes (not talking about some design fix) should involve community and be entirely international, right now, sadly, WMF asks English Wikipedia on a better day and no one on a worse day.
On 14/12/2018 02:39, billinghurst wrote:
Call me a simpleton, though sometimes I wonder whether we have the technical team of WMF staff and developers trying to get ahead of (around?) society, and societal models.
The societal model that the wikis have implemented is a thing called a bureaucrat, their role is to implement the change of status of members of the community. Soooo how about we go back and investigate utilising that model with regard to this matter?
Please explain in the current deliberations that there was the consideration for how the community's existing model of rights utilising bureaucrats? I just see a technical implementation, primarily focusing around a single wiki.
This is and will always be a community issue, and I look forward to seeing this more broadly proposed and discussed at Metawiki. Not stuck here in a small email forum for ambassadors. Not stuck in a phabricator ticket in the back of nowhere. I look forward to this being open to the whole community, not one particularly controlled by developers and staff of WMF. That has been the wiki way through times, though not in more recent times where we have what is this approach to more technical-only solutions, and divorced from the broader wiki community.
This is a societal issue, and the technical team should be developing the tools that the society needs to manage. It needs to come out of Phabricator for the community discussion. It needs to come out of the limited scope of this mailing list. This is not about operating in your comfort zone.
Yes, the community is noisy, and has a diversity of opinion, and one that will take time to reach a consensus. Yes, it is not our technical peoples general skill set, so we have others moderate the conversation. This is not solely a technical problem, get over it.
-- billinghurst
------ Original Message ------ From: "Johan Jönsson" <jjonsson@wikimedia.org mailto:jjonsson@wikimedia.org> To: "Wikitech Ambassadors" <wikitech-ambassadors@lists.wikimedia.org mailto:wikitech-ambassadors@lists.wikimedia.org> Sent: 14/12/2018 6:25:59 AM Subject: Re: [Wikitech-ambassadors] Removal of unblockself rights on wiki
On Thu, Dec 13, 2018 at 8:20 PM Deryck Chan <deryckchan@gmail.com mailto:deryckchan@gmail.com> wrote:
I agree with what's been said in this thread so far. An admin of a large wiki shouldn't be allowed to unblock themselves, if another admin blocked them. However, on small wikis, this would lead to a first-mover advantage situation, so admins should be forbidden from unblocking themselves if there are more than a certain number of admins (and bureaucrats). I would recommend a threshold of five admins. Notice that if there are only three admins (with Nemo's proposal), if one admin blocks another admin, the situation reduces to a "shoot first to win" between the two remaining admins. If there are five admins and one blocks another, there will still be three uninvolved admins left to argue it out :) The Cantonese Wikipedia recently came close to a situation where an admin might get blocked for bad behaviour. A few users presented a strong case that an admin had been acting against policy. Because we have a dozen admins, a few other admins were able to discuss the matter, and issued strong words of admonishment to the unbehaving admin, and the unbehaving admin disappeared from the wiki since then. Thinking back, one of the concerns we had was that an admin could unblock themselves anyway, so there was actually no real course of action to take other than desysopping (we have a bureaucrat; not me). If this feature of "no self-unblocks on wikis with lots of admins" was in place, then the threat of a block would have had more teeth.Just to keep everyone aware of what's been happening in https://phabricator.wikimedia.org/T150826 – to avoid the "shoot first to win" situation, a blocked admin can block the admin who blocked them but no one else. Our balance of terror.
//Johan Jönsson
Wikitech-ambassadors mailing list Wikitech-ambassadors@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
On Sat, Dec 15, 2018 at 7:47 AM stjn ole.yves@gmail.com wrote:
The approach to major changes (not talking about some design fix) should involve community and be entirely international
You *are* talking about some design fix. When blocking was added as a feature, it was only integrated with some actions - it was checked during editing, but not during unblocking. That was an oversight that has started causing problems now so it's being fixed. Even our largest wikis only see about ten self-unblocks a year, most of which are unblocks of self-blocks (which are not affected by the change). By no sane definition is this a major change. Had it not been announced here, no one would even have noticed it.
Tisza Gergő, 15/12/18 22:38:
Even our largest wikis only see about ten self-unblocks a year, most of which are unblocks of self-blocks
This is an irrelevant piece of data. Of course so far there was very little incentive to block a sysop, since they could unblock themselves.
We may never discover the impacts of this change, or maybe we'll find out in 5 years about a wiki or two and then discuss for 5 more years how to deal with a "local" problem which has become intractable.
Federico
Speaking about self-blocks, why ist this option possible?
Dan ----------------------------------------------------------- Mobil telefon 1 (Comviq): 0767 15 45 70 Mobil telefon 2 (Telia): 0739 17 17 89 Skype: DanKoehl ICQ: 40467 87 ------------------------------------------------------------
Den sön 16 dec. 2018 kl 09:34 skrev Federico Leva (Nemo) <nemowiki@gmail.com
:
Tisza Gergő, 15/12/18 22:38:
Even our largest wikis only see about ten self-unblocks a year, most of which are unblocks of self-blocks
This is an irrelevant piece of data. Of course so far there was very little incentive to block a sysop, since they could unblock themselves.
We may never discover the impacts of this change, or maybe we'll find out in 5 years about a wiki or two and then discuss for 5 more years how to deal with a "local" problem which has become intractable.
Federico
Wikitech-ambassadors mailing list Wikitech-ambassadors@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
AFAIK there are two main usecases for self-blocks: * Testing different features of blocks. * As a means of self-imposed wikibreak.
-- Brian
On Sun, Dec 16, 2018 at 8:35 AM Dan Koehl dan.koehl@gmail.com wrote:
Speaking about self-blocks, why ist this option possible?
Dan
Mobil telefon 1 (Comviq): 0767 15 45 70 Mobil telefon 2 (Telia): 0739 17 17 89 Skype: DanKoehl ICQ: 40467 87
Den sön 16 dec. 2018 kl 09:34 skrev Federico Leva (Nemo) nemowiki@gmail.com:
Tisza Gergő, 15/12/18 22:38:
Even our largest wikis only see about ten self-unblocks a year, most of which are unblocks of self-blocks
This is an irrelevant piece of data. Of course so far there was very little incentive to block a sysop, since they could unblock themselves.
We may never discover the impacts of this change, or maybe we'll find out in 5 years about a wiki or two and then discuss for 5 more years how to deal with a "local" problem which has become intractable.
Federico
Wikitech-ambassadors mailing list Wikitech-ambassadors@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
Wikitech-ambassadors mailing list Wikitech-ambassadors@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
I was endorsing the whole sentiment, not exactly the topic it belongs to. But even then, self-unblocking was a default option, so it could’ve been discussed what must be done with it. Having the ability to self-destruct on other people with the only option available in blocking the bad guy himself is a valid concern to have about this decision.
On 15/12/2018 23:38, Tisza Gergő wrote:
On Sat, Dec 15, 2018 at 7:47 AM stjn <ole.yves@gmail.com mailto:ole.yves@gmail.com> wrote:
The approach to major changes (not talking about some design fix) should involve community and be entirely internationalYou *are* talking about some design fix. When blocking was added as a feature, it was only integrated with some actions - it was checked during editing, but not during unblocking. That was an oversight that has started causing problems now so it's being fixed. Even our largest wikis only see about ten self-unblocks a year, most of which are unblocks of self-blocks (which are not affected by the change). By no sane definition is this a major change. Had it not been announced here, no one would even have noticed it.
Wikitech-ambassadors mailing list Wikitech-ambassadors@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
On Sun, Dec 16, 2018 at 7:51 AM stjn ole.yves@gmail.com wrote:
I was endorsing the whole sentiment, not exactly the topic it belongs to. But even then, self-unblocking was a default option, so it could’ve been discussed what must be done with it.
You can still go to the Phabricator task and do that. (It was linked before but for convenience it is https://phabricator.wikimedia.org/T150826 .) The patch was about five lines, it's not hard to rewrite if someone has a better idea of what to do. What's frustrating to me in these kinds of threads is that people are very eager to discuss how the discussion should have happened, but don't seem very interested in the discussion itself.
Possibly because some of see this should be a case of removal of rights, be it temporary or permanent, rather than this argument about blocks and unblocks in a competition between admins. This is the purpose of bureaucrats to manage rights and for stewards to manage an emergency.
-- billinghurst
------ Original Message ------ From: "Tisza Gergő" gtisza@gmail.com To: "Coordination of technology deployments across languages/projects" wikitech-ambassadors@lists.wikimedia.org Sent: 17/12/2018 7:43:15 AM Subject: Re: [Wikitech-ambassadors] Removal of unblockself rights on wiki
On Sun, Dec 16, 2018 at 7:51 AM stjn ole.yves@gmail.com wrote:
I was endorsing the whole sentiment, not exactly the topic it belongs to. But even then, self-unblocking was a default option, so it could’ve been discussed what must be done with it.
You can still go to the Phabricator task and do that. (It was linked before but for convenience it is https://phabricator.wikimedia.org/T150826 .) The patch was about five lines, it's not hard to rewrite if someone has a better idea of what to do. What's frustrating to me in these kinds of threads is that people are very eager to discuss how the discussion should have happened, but don't seem very interested in the discussion itself.
On Thu, Dec 13, 2018 at 8:20 PM Deryck Chan deryckchan@gmail.com wrote:
Just to keep everyone aware of what's been happening in
https://phabricator.wikimedia.org/T150826 – to avoid the "shoot first to win" situation, a blocked admin can block the admin who blocked them but no one else. Our balance of terror.
I would recommend a threshold of five admins. Notice that if there are only
three admins (with Nemo's proposal), if one admin blocks another admin, the situation reduces to a "shoot first to win" between the two remaining admins. If there are five admins and one blocks another, there will still be three uninvolved admins left to argue it out :)
In fact, in small wikis it is more likely that the rest of admins will not want to get involved. I've seen it, experienced it. In wikis with more than five admins (and some may not be active - you loose rights only after two years of inactivity). I have even seen admins blocking themselves and taking wikibreak after blocking another admin, just to show that the were unhappy that they had to do it.
On Fri, Dec 14, 2018 at 1:39 AM billinghurst billinghurstwiki@gmail.com wrote:
Yes, the community is noisy, and has a diversity of opinion, and one that will take time to reach a consensus. Yes, it is not our technical peoples general skill set, so we have others moderate the conversation. This is not solely a technical problem, get over it.
Indeed, it is not solely a technical problem. No problem is solely technical. One should think all possible consequences within the community when affecting the status quo. Do not expect that the communities will not find ways to manipulate any technical change in ways unpredicted. For example, the "interface-admins" change resulted in some wikis to not have any interface admins, while it had before admins that where able to do the work and they did it. But the removal of the rights let some members of the community to push a policy that "interface-admins" should be _elected_. So for existing admins that would be a reelection, and in fact a way for some to remove some rights from existing admins without proposing a de-adminship). I recall that it was said that it is up to the communities to decide how the rights should given, but the rights were not removed by decision of the communities.
Any technical change should examine all expected and unexpected scenarios for manipulation before implemented.
On Sat, 15 Dec 2018 at 15:47, stjn ole.yves@gmail.com wrote:
Something is rotten in the way changes are being discussed and communicated, and it must be fixed. The approach to major changes (not talking about some design fix) should involve community and be entirely international, right now, sadly, WMF asks English Wikipedia on a better day and no one on a worse day.
We are a decentralized movement though. Publicizing proposed changes on the Ambassadors list, discussing it on Phabricator, and cross-posting on every VPT, is pretty much the best we can do in terms of getting true international involvement.
On Tue, 18 Dec 2018 at 10:30, geraki geraki@gmail.com wrote:
On Thu, Dec 13, 2018 at 8:20 PM Deryck Chan deryckchan@gmail.com wrote:
Just to keep everyone aware of what's been happening in
https://phabricator.wikimedia.org/T150826 – to avoid the "shoot first to win" situation, a blocked admin can block the admin who blocked them but no one else. Our balance of terror.
I would recommend a threshold of five admins. Notice that if there are
only three admins (with Nemo's proposal), if one admin blocks another admin, the situation reduces to a "shoot first to win" between the two remaining admins. If there are five admins and one blocks another, there will still be three uninvolved admins left to argue it out :)
In fact, in small wikis it is more likely that the rest of admins will not want to get involved. I've seen it, experienced it. In wikis with more than five admins (and some may not be active - you loose rights only after two years of inactivity). I have even seen admins blocking themselves and taking wikibreak after blocking another admin, just to show that the were unhappy that they had to do it.
:(.
Any technical change should examine all expected and unexpected scenarios for manipulation before implemented.
We should endeavour to explore the impact of all plausible scenarios, but
can't reasonably expect a wiki community to examine *all unexpected* scenarios - if we imposed this requirement, nothing will ever happen. In fact the wiki would never have happened if that was the case.
wikitech-ambassadors@lists.wikimedia.org