I participated in this vote (you're not really requesting comments, you're requesting votes), but I think that user groups in general should be much more flexible. The strict rigidity that currently exists seems to be a purely technical issue (it's a huge pain in the ass to get a new group added or modified), not a social issue. It'd be nice if rights could be added or removed from local user groups by bureaucrats just as they can be with global user groups by stewards. -- MZMcBride ( talk) 15:59, 12 April 2011 (UTC)
- Would this require any major code restructuring? Because my understanding of usergroups is that it would. Then again, my understanding of usergroups is about nil.
NW (
Talk) 16:28, 12 April 2011 (UTC)
- It would require moving the data storage from the server configuration files to the database. Currently all of the user group information (including which groups exist on which wiki and what their associated user rights are) is stored in the PHP files (somewhere at http://noc.wikimedia.org/conf/). You'd need to put the information into the database and then implement logging, a user interface, and access control for it. Access control would be a bit tricky, I imagine. With global user groups, stewards can adjust all groups and all rights, which is a fairly binary system. For local user groups, you probably wouldn't want bureaucrats to be able to assign the "checkuser" user right (for example) to a particular user group (not that they would without consensus, though...). -- MZMcBride ( talk) 17:10, 12 April 2011 (UTC)
- I don't disagree with anything you said, but I was going for simple and easily described solutions to the immediate barriers. –
xeno
talk 17:22, 12 April 2011 (UTC)
- It's definitely doable, but it would be a not-inconsiderable amount of work. As MZMcBride says, solving the quis custodiet problem would be a significant challenge. Happy‑ melon 22:43, 12 April 2011 (UTC)
- I thought some people were seeing social reasons to want to make adding groups harder rather than easier (just like the US president isn't allowed to amend the Constitution by clicking in a browser), so I commented on that in the rfc, but maybe I'm wrong. A hackish way to make new permission combinations trivial might be to have a separate group for each permission bit. Then you could implement "roles" with a browser script that turned combinations of bits on and off with a userrights API call (or similarly, have a protected/private wiki page with a form on it, if that's not how Special:Userrights already works). 69.111.194.167 ( talk) 04:33, 13 April 2011 (UTC)
This RFC is about making "user groups" self-sufficient, not "user rights," isn't it? The current title ("Wikipedia:Requests for comment/Make userrights self-sufficient") doesn't make sense to me. -- MZMcBride ( talk) 16:09, 12 April 2011 (UTC)
- Yes, well, kinda-sorta. The terms seem to be somewhat interchangable. For example, if I want to give you the ability to use rollback, I visit Special:UserRights, the page is entitled "User rights management" - but I am invited to manage user groups. I have no objection the page being moved if it is an issue - I went based on the special page title. – xeno talk 17:22, 12 April 2011 (UTC)
Xeno, Risker, and JClemens, are you asking to be able to basically flip all the userright bits separately, i.e. is that a desirable end result of all this? I'm not totally against that, I just !voted "oppose" because I think there's too much confusion right now to make a clear decision. If that's what you're looking for, can you say so and make a case for it directly? I'm not into the cabal-phobia thing that some people are, I just see the existing set of groups as having evolved rather slowly through social movement, and it may not be such a great idea to make it change a lot faster by flipping switches. In short I'm confused and I can't tell if it even makes sense to think of the issue in these terms. Thanks 69.111.194.167 ( talk) 04:45, 13 April 2011 (UTC)
- I don't see how you got that idea from what is proposed, though I think that is what MZMcBride is suggesting above. As for the groups evolving slowly: while they were here before I got here, I don't think that's how they came about. Apparently they were created rather urgently on a need basis. And in fact, according to MuZeMike on the project page the reason the 'bureaucrat' usergroup does not contain the rights necessary to fully carry out a rename is because the Mediawiki default is that sysops can perform renames. So when the 'crat group was created, no one thought to include those necessary provisions (because all bureaucrats were already administrators). I see this as simply a bug that should be fixed, and I do not think that I am seeking the major change (fine grain control) you have written about. Perhaps just take the proposals at face value - there is no underlying motive here beyond what is proposed. – xeno talk 14:13, 13 April 2011 (UTC)
- In answer to your question, each of these three permissions were hived off of the responsibilities of developers with root access when their workload became too much to continue having these increasingly time-consuming responsibilities. CheckUser and Oversight were initially created to be used by specific individuals, but as the project and the workload have grown, the number of people required to carry out these tasks has increased. (I'm a little less certain of how the first 'crats were selected, whether the community was involved in creating the role or if it was handed to specific individuals at first too.) Because they were going to specific individuals, they were only created with permissions those individuals didn't currently have, and it has never been a priority to go back and realign the permissions accordingly. (Personally, I have no problem with developers (a) concentrating on actual development rather than what is essentially database and user management and (b) not spending a lot of time worrying about redevelopment of user rights and whether there is consistency across the system.) Risker ( talk) 02:33, 14 April 2011 (UTC)
I participated in this vote (you're not really requesting comments, you're requesting votes), but I think that user groups in general should be much more flexible. The strict rigidity that currently exists seems to be a purely technical issue (it's a huge pain in the ass to get a new group added or modified), not a social issue. It'd be nice if rights could be added or removed from local user groups by bureaucrats just as they can be with global user groups by stewards. -- MZMcBride ( talk) 15:59, 12 April 2011 (UTC)
- Would this require any major code restructuring? Because my understanding of usergroups is that it would. Then again, my understanding of usergroups is about nil.
NW (
Talk) 16:28, 12 April 2011 (UTC)
- It would require moving the data storage from the server configuration files to the database. Currently all of the user group information (including which groups exist on which wiki and what their associated user rights are) is stored in the PHP files (somewhere at http://noc.wikimedia.org/conf/). You'd need to put the information into the database and then implement logging, a user interface, and access control for it. Access control would be a bit tricky, I imagine. With global user groups, stewards can adjust all groups and all rights, which is a fairly binary system. For local user groups, you probably wouldn't want bureaucrats to be able to assign the "checkuser" user right (for example) to a particular user group (not that they would without consensus, though...). -- MZMcBride ( talk) 17:10, 12 April 2011 (UTC)
- I don't disagree with anything you said, but I was going for simple and easily described solutions to the immediate barriers. –
xeno
talk 17:22, 12 April 2011 (UTC)
- It's definitely doable, but it would be a not-inconsiderable amount of work. As MZMcBride says, solving the quis custodiet problem would be a significant challenge. Happy‑ melon 22:43, 12 April 2011 (UTC)
- I thought some people were seeing social reasons to want to make adding groups harder rather than easier (just like the US president isn't allowed to amend the Constitution by clicking in a browser), so I commented on that in the rfc, but maybe I'm wrong. A hackish way to make new permission combinations trivial might be to have a separate group for each permission bit. Then you could implement "roles" with a browser script that turned combinations of bits on and off with a userrights API call (or similarly, have a protected/private wiki page with a form on it, if that's not how Special:Userrights already works). 69.111.194.167 ( talk) 04:33, 13 April 2011 (UTC)
This RFC is about making "user groups" self-sufficient, not "user rights," isn't it? The current title ("Wikipedia:Requests for comment/Make userrights self-sufficient") doesn't make sense to me. -- MZMcBride ( talk) 16:09, 12 April 2011 (UTC)
- Yes, well, kinda-sorta. The terms seem to be somewhat interchangable. For example, if I want to give you the ability to use rollback, I visit Special:UserRights, the page is entitled "User rights management" - but I am invited to manage user groups. I have no objection the page being moved if it is an issue - I went based on the special page title. – xeno talk 17:22, 12 April 2011 (UTC)
Xeno, Risker, and JClemens, are you asking to be able to basically flip all the userright bits separately, i.e. is that a desirable end result of all this? I'm not totally against that, I just !voted "oppose" because I think there's too much confusion right now to make a clear decision. If that's what you're looking for, can you say so and make a case for it directly? I'm not into the cabal-phobia thing that some people are, I just see the existing set of groups as having evolved rather slowly through social movement, and it may not be such a great idea to make it change a lot faster by flipping switches. In short I'm confused and I can't tell if it even makes sense to think of the issue in these terms. Thanks 69.111.194.167 ( talk) 04:45, 13 April 2011 (UTC)
- I don't see how you got that idea from what is proposed, though I think that is what MZMcBride is suggesting above. As for the groups evolving slowly: while they were here before I got here, I don't think that's how they came about. Apparently they were created rather urgently on a need basis. And in fact, according to MuZeMike on the project page the reason the 'bureaucrat' usergroup does not contain the rights necessary to fully carry out a rename is because the Mediawiki default is that sysops can perform renames. So when the 'crat group was created, no one thought to include those necessary provisions (because all bureaucrats were already administrators). I see this as simply a bug that should be fixed, and I do not think that I am seeking the major change (fine grain control) you have written about. Perhaps just take the proposals at face value - there is no underlying motive here beyond what is proposed. – xeno talk 14:13, 13 April 2011 (UTC)
- In answer to your question, each of these three permissions were hived off of the responsibilities of developers with root access when their workload became too much to continue having these increasingly time-consuming responsibilities. CheckUser and Oversight were initially created to be used by specific individuals, but as the project and the workload have grown, the number of people required to carry out these tasks has increased. (I'm a little less certain of how the first 'crats were selected, whether the community was involved in creating the role or if it was handed to specific individuals at first too.) Because they were going to specific individuals, they were only created with permissions those individuals didn't currently have, and it has never been a priority to go back and realign the permissions accordingly. (Personally, I have no problem with developers (a) concentrating on actual development rather than what is essentially database and user management and (b) not spending a lot of time worrying about redevelopment of user rights and whether there is consistency across the system.) Risker ( talk) 02:33, 14 April 2011 (UTC)