So, over the years, we have had a few discussions here and there in various pubs regarding administrative rights. Wikitravel Shared being the multi-version coordination site should of course have been used all along, but as things are, it wasn't. I reckon it is time to bring the issue(s) to attention here. I split the question in two and hope that we can reach some form of consensus. Riggwelter
Today, admins on any language version is also entitled to have administrative tools on Shared. Admin nominations are therefor not really applicable, but as of now the only way we can highlight a new, keen sweeper to get the tools he/she needs to work on Shared. However, I think this isn't really a good idea. I therefor move to suggest that the automatic "function" is removed and that formal admin rights should be applied for on each and every language version incl Shared. Riggwelter
I disagree. Essentially, admin privileges are given to users who a) are interested in janitorial tasks, and b) understand our policies and are trusted. If someone goes through this nomination process on a language version and meets these criteria, why would we force a redundant nomination here? I think the current practice also helps foster as sense of, well, sharedness on Wikitravel Shared—that it is not something separate and alien from the other projects, and it is a place where all users should be able to come together outside of the language versions for inter-version coordination. --PeterTalk 18:57, 10 August 2011 (EDT)
"Unused high-privilege user accounts are a security risk. For this reason, administrators who don't use their user accounts for 3 months will be notified by email and their privileges will be revoked. Administrators who know they don't have the time or interest to continue as admins should request to have their privileges revoked voluntarily."
Here are a few arguments:
Anyone knowing about/working with IT security knows about the security risks with unused accounts/user privileges. Most comp users also have an understanding, of course.
It is easy to revert changes made by a vandal getting hold of a user account - but it is not very nice, or easy, for the real user to hsve to try to explain what happened. Noone should have to risk ending up in that situation.
Discussing each and every revoke of user rights for an unused account is not a very practicval way to go. It might take a lot of time and the same pros and cons will be vented each time.
There is a risk of unused accounts/rights being there for ages - years at worst.
Having administrative user rights is not a privilege - being an admin is tough and more often met with irritation rather than encouragement.
It is not a lifelong right to have administrative rights, but I think it takes more work than we want to have to keep user rights limited in time, for example having to reapply each year to have such rights.
Actually, the security risk of having an inactive admin account has never been explained, although it has been questioned.
Has this ever happened? And doesn't this hold true for any user, regardless of privileges?
The reasons I would like to avoid, for the most part, revoking sysop privileges would be simply that absence only makes the heart grow fonder (rather than suspicious)—I would be happy to see dormant admins return and pick up the invaluable work right where they left off, with the same tools. If they were to come back and see their status had been changed, I would consider that a bit unwelcoming. At the very least, I would like dormant admins to be contacted and to have the opportunity to respond prior to any change in status. --PeterTalk 18:57, 10 August 2011 (EDT)
I tend to agree with Peter, though if we keep the inactivity de-admining, it ought to be based on activity on the user's home wiki, not just here on shared. LtPowers 10:31, 11 August 2011 (EDT)
I think the only compelling reason to de-admin someone is that it might be a security risk to have lots of admin accounts around, but I don't think the risk from an inactive account is any greater than from an active one, so I'm not convinced that any security advantage gained from de-admining outweighs the disadvantages Peter outlined. My preference would be to change the shared: policy to a much longer interval, and to also require discussion and consensus before de-admining. -- Ryan 12:39, 11 August 2011 (EDT)