There is no sense in giving developers administrative power. Developers are good at programming, not management of a community. By wrapping up their ability to contribute with their ability to rule, they are made effectively unaccountable. Nobody wants to remove someone's developer access if it means they can't do much needed progrmaming work. Administration of the encyclopedia also distracts them from programming, a task which they have a rare skill and motivation for.
Wikipedia should not be a technocracy, ruled by those with knowledge of computer systems. Wikipedia should be a democracy. Those in power should be accountable to the community at large, and ideally selected from and by the community at large.
I have written a feature giving people with the "developer" flag set in their wiki user accounts a level of administrative ability similar to what developers with shell access are capable of. Specifically, such users are able to set arbitrary user rights for any user on any Wikimedia project. They may create sysops, desysop, create bureaucrats or other developers, or any other user-rights operation you care to mention. This feature is operational right now, and I've been using it for the last couple of weeks to make bureaucrats on various wikis.
The feature is easy to use and does not carry the security risks of write-access to the database. At the moment, it is not possible to rename user accounts or change the history of articles through the web interface, but such features are planned.
I suggest we use this feature to split the roles of developer and site administrator. Specifically, here is what I think should happen:
1. A policy should be instituted disallowing any developer from using their power for administrative purposes, except where there is no other way to perform the relevant operation. New developers applying for shell access should be made aware of this policy.
By "administrative purposes", I mean exercises of power for any other purpose than testing and implementing software.
2. A small number of users should be made "honorary developers" (perhaps a better title can be found). These users should be selected by putting forward nominations and then conducting a vote, similar to the vote now conducted at the English Wikipedia for sysop access.
3. These "honorary developers" can lose their developer access by a community vote giving a majority in favour, by an arbitration committee ruling, or by Jimbo's decree.
It should be possible for a developer to hold both shell access and community blessing. Such people would take the role of both programmer and administrator. However as I said above, we really have a lot of programming work to do.
--------------------------------------------------------------------
I'll also take this opportunity to drop a few subtle hints.
Maveric149
Wikipedia's most active contributor, Maveric149 has done a tremendous amount of work for Wikipedia over the last two years. Mav is always cool and rational when dealing with a dispute, and works hard to find a compromise amenable to all parties. Respect for him in the community is universal.
Angela
Angela has been extremely active in the Wikipedia and Wikipedia talk namespaces over the last 6 months, organising the formation of many policies. In her enthusiasm for weeding and quality control, she has edited almost every functioning Wikimedia wiki. She also lives in a different time zone to Mav, so she'll be able to deal with situations arising when Mav is unavailable.
-- Tim Starling
I agree with Tim. This reminds me of the "three powers" (and I know this is not a State and there is no such thing as a "government"). *Division* of work and functions is
a) more transparent (there is not even the remote possibility of dictatorship, and mistakes are mistakes in only one part of the project). b) easier to maintain (someone with just one function may be removed as there will easily be substitutes. Someone for just one function is more easily found than for two). c) easier to work in (the person needs only care about "one" aspect of the project).
My 2c. I probably ought to have quoted Tim, but my mail client is far away and editing is a pain....
Pedro.
Salve!
I already posted this alternative idea for the administrative power on the German mailinglist because I have the experiances of some radiostations:
Radio/TV stations have one "Chef vom Dienst" (CvD) (Wiktionary is needed, I had to call www.dw-world.de for thier offical translation): "chief duty editor"(duty=liability). The chief duty editor has only a special task during his shift, he does not play a special role in the hirachy nor in conferences. He is a journalist like the other editors, but in his shift as chief duty editor he cares about the administration stuff: what breaking news is important, which editor cares about which story, the timetable... so during his shift he is to busy to write own storrys/news.
Often this job is rotaiting, so an editor takes this role as chief duty editor only once a week.
Why do I proposed this idea for the Wikipedia to think about this modell?
Because in my eyes (as normal Wikipdianer) I found > 50 administrators not transparent. Would someone ask me next time to become admin, I would reject this, because I think this system is sub-perfect. I do not use my PC with root-rights, especialy not for internet communication, so why should I use wikipedia everytime as administrator? When I would be an admin an d write an articel and have a dispute with other users - there is the danger that I nor the user user could seperate between my admin function and my normal subjective wikipedia-work.
==Reducing the power to bann IPs/user== Going on with this idea I came to the point, that the right to ban IPs and user should have only one person at once. Image all experienced trusted user, which would become admin today are canditated for the "chief duty editor".
1. When a trusted user logs in he can declare that he would candidate for chief duty editor in that session.
2. The first candidate who logged in become the demand note by the Wikipedia System to be the "chief duty editor" for the next 2 hours. (He can accept or reject, for example when he is drunk at that time).
3. When two or more candidates are online they have to agree who takes the job, in case of a stalemate (stand-off) an algorithmus like the one with the most edits since be the last time chief duty editor could help.
4. In case that one chief duty editor time of 2 hours are finish, he goes offline before or he does not answer on requests to ban one IP/User inbetween 3 minutes, the system calls again all candidates to find one new chief duty editor
5. In case that no candidate is only all trusted users become a message (pop-up) to become candidate inbetween next 2 minutes ;)
6. On a populare wikipedia page is shown who is chief duty editor right now and has a log of all shifts, with all action in the name of chief duty editor.
7. The chief duty editor use his special account only for administration and statments as administrator, but not for normal editings - for that he must use his normal account, but he should work full time with reading, giving comments on disscussion pages and delete nonsens, and not try to write or change own article during his shift.
8. In case that the chief duty editor is going mad, every trusted user can request a despose of the chief duty editor but the one who request this can`t become chief duty editor for next 24h. If he has to argue well and to try to solve the problem in dialog with the chief duty editor before and every trusted wikipedian who is online become a call to vote. The one who lost this vote lost his status trusted wikipedian after a final voting inbetween 48h clears this case.
==Reducing the power to delete== At the moment we have lists where we propose candidats for deleating, these have to be deleted 7 days after the proposel. But also some trolls and stupid articles, which have to deleated instancely. IMHO it would be nice to see how many people does care about this work at this time. When > 50 admins does care about this job, but also write artikles at the same time, this isn`t very systematic. So I would like to see an algorithmus, but more easy like I proposed for the chief duty editor that every trusted wikipedian could choose if he concentrate on doing administration work, or just only work on articles of his interest.
The admins will complain now, but I be admin honorable and I do like to work on articles on my interests - write, edit and when I think there is one article bullshit, I deleat it. THATS the point that I whant to avoid, because this is subjective work and will bring confilcts with other non-admin users, especialy when the number of admins will grow.
I think I would be better when admins would more split their work, the normal contributings and the administration stuff. Those who say, I like to do administration stuff when they log in should take more responsability than only to check their wathchlist. Mybe by an algrorithm that admins/editors are supported by a softwaretool that they have to read systematicaly every new article and every changed articel once a month.
But admins should think about the option to do not work as admin and concentrate on what they like to do. Sure, you would say you have already the freedom as admin to do this. But so we have no systematic, no overview how works as admin today - 50? 30? 10? none?
Am Dienstag, 9. März 2004 08:30 schrieb Tim Starling:
There is no sense in giving developers administrative power. Developers are good at programming, not management of a community.
Am Dienstag, 9. März 2004 09:51 schrieb Pedro Fortuny:
I agree with Tim. This reminds me of the "three powers" (and I know this is not a State and there is no such thing as a "government"). *Division* of work and functions is
a) more transparent (there is not even the remote possibility of dictatorship, and mistakes are mistakes in only one part of the project). b) easier to maintain (someone with just one function may be removed as there will easily be substitutes. Someone for just one function is more easily found than for two). c) easier to work in (the person needs only care about "one" aspect of the project).
This is funny, the admins are working with root-account for deleating and ban users and get in trouble with normal users, because they mix thier admin role and their subjective wikipdianer role and argue that developers can`t have the softskill to manage social conflicts. With this arguments a,b,c you be in favor that admins are not allowed to write or edit articles. *g*
I want the admins to have no admin rights from time to time, e.G. every second week, because than they reflect more their skills of social managment. Probably it is more work to argue and request other admins to take final action, but in this situation admins learn to reflect and to argue why an other admin should take action. Secondary effect is that there isn´t a two class comunity in todays way that more rights are linked to a person, it would be more transparent that it is linked to a task and trusted wikipedianer takeover the task from time to time (or you can say monarchie vers. democraty) And finaly I would like see a general and a personal log of admin action, to see what is done, not only to controll admins, also to see who does honorable good work.
On the other hand, one developer could learn, too when he works as admin from time to time to see how it works and to get ideas how to make the software better. But this period should be only like stagiers for developers and during their stagiers they should not have the access to the webserver to find out more than normal admins know.
Think about this point: every article could be modified, why not also who is admin today?
I would like to become admin one day, but only when I have the right to say, I do not be admin today. Someone said becoming admin can`t harm, but I beleave that a high number of admins and the mixing of personal and admin task/role harm already, and will be a growing problem.
Till now I got ony 3 contras like "don`t/(no need) to change the status quo" in Germany, instead of finding people how like to go on with thinking about an alternative solution. Probably the normal reaction when someone propose to reduse the power of other people. But my aime is not bureaucracy or to make it more compicated than neccessary, I want to avoid the office admin and like to replace it with the task admin, that some user can take as (full)job from time to time, like a "chief duty editor": -one "chief duty admin" -and some "duty admins" recruted day by day, hour of hour from a number of trusted wikipedianers (wikpedians).
Anyone who likes this idea and likes to go on to think about alternativities?
rob
Robert Michel wrote in part:
- When a trusted user logs in he can declare that he would candidate for
chief duty editor in that session.
- The first candidate who logged in become the demand note by the
Wikipedia
System to be the "chief duty editor" for the next 2 hours. (He can accept
or
reject, for example when he is drunk at that time).
- When two or more candidates are online they have to agree who takes the
job, in case of a stalemate (stand-off) an algorithmus like the one with
the
most edits since be the last time chief duty editor could help.
- In case that one chief duty editor time of 2 hours are finish, he goes
offline before or he does not answer on requests to ban one IP/User
inbetween
3 minutes, the system calls again all candidates to find one new chief
duty
editor
- In case that no candidate is only all trusted users become a message
(pop-up) to become candidate inbetween next 2 minutes ;)
- On a populare wikipedia page is shown who is chief duty editor right
now
and has a log of all shifts, with all action in the name of chief duty editor.
- The chief duty editor use his special account only for administration
and
statments as administrator, but not for normal editings - for that he must use his normal account, but he should work full time with reading, giving comments on disscussion pages and delete nonsens, and not try to write or change own article during his shift.
- In case that the chief duty editor is going mad, every trusted user can
request a despose of the chief duty editor but the one who request this
can`t
become chief duty editor for next 24h. If he has to argue well and to try
to
solve the problem in dialog with the chief duty editor before and every trusted wikipedian who is online become a call to vote. The one who lost
this
vote lost his status trusted wikipedian after a final voting inbetween 48h clears this case.
Yes, that's a very nice fantasy. Are you going to program it? Because I have better things to do. My objective has always been to produce a practical model, one which I can code in a few hours of my spare time. We can all dream up fantastic power models, but they lead to nothing but stalling and tangential unproductive debate.
Maybe some programmer will come along wanting to spend weeks coding a power model which will quite possibly meet strong opposition from the users. I would advise such a programmer to instead spend that time on improving our seriously inadequate database schema, optimising the parser or working on load balancing, thus allowing us to keep the site operating with an acceptable response time for a while longer.
-- Tim Starling
Salve Tim,
Am Dienstag, 9. März 2004 14:36 schrieb Tim Starling:
Yes, that's a very nice fantasy. Are you going to program it?
Well, I know that it would not be easy to explain another system, in short: the answer would be - not possible in detail: the answer would be - to complicated Or just "Are you going to program it".
I think you mean "very nice fantasy" in a ironic way
Because I have better things to do.
Ok, it`s up to you to deside to
My objective has always been to produce a practical model, one which I can code in a few hours of my spare time.
A lot of software can`t be programmed in few hours steps. But also for small stepps an utopie could be an aim. For a free project it is ok that you say you will not spend time in this idea - its up to you - and I did not wrote my idea is perfect and you have to progamm it.
But to write "that`s a very nice fantasy. Are you going to program it?" isn`t this a bit unfair? Programing is more than to code it, and why killing an just buting idea?
We can all dream up fantastic power models, but they lead to nothing but stalling and tangential unproductive debate.
This is my time that I spend into the idea to make it better and that I haven`t enthuse you to find a new better working model, and to find a solution to code it is already clear.
Maybe some programmer will come along wanting to spend weeks coding a power model which will quite possibly meet strong opposition from the users.
Which user, the admin or the normal users? And BTW do I`m on the software-developer mailinglist or on the user mailing list?
I would advise such a programmer....
Ahh, here comes your message - there are a lot of more important, burning problems waiting for to less developers and because of this you judge that it would be inproductive to go on with my idea.
Ok, I can live with this, I already expected it.
I´m interrested in raising the reliability of the wikipedia project, server response will not influence this IMHO importend point very much. I also beleave that admins could work more efficent when they do not work everytime as user and admin - to have a short (self choosed) admin shift and than spare time for own articles could rise the produtivity of the admins.
At last, consider that the number of articels, the popularity of the project, the request/second and also the number of users has grown rapid. So the problem of administration has grown in the same way as the caching problem. Like the caching problem, only new and faster server does not solve the problem, in the same way the social and content administration of all new articles and users is not solveable with only more admins. ;)
So with more people it is possible to take care about more details at once - nobody is stopping people "waisting" their free time for interviews or to preparing a WikiReader, one printed extract of the Wikipedia. New wikipedia-user could care about new ideas - that´s the way it goes.
When some old/urgend problems are unsolved, raise your voice for help.
I does only raise my voice to support developers who want to become admin for getting experiances - and to get feedback from users if someone understund the advantage of an admin shift with a chief duty admin (like the professional radiostations works) and if some user/admins agree that this would be a possible way for a big wikiwiki like ours.
greetings rob
PS: Be carefull with provoking others with words like "very nice fantasy" the most likly reaction will be that the other person will do everythink to make this fantasy come true - Or was this your intention - a skill from a workshop "modern motivation strategies for top manager"? ;-)
Don`t get me wrong (this was a kind of joke) and I do not take our thread personal - I just think you have good resons, and so do I - you try to make the wikipedia better - and so do I :)
Pedro Fortuny wrote:
I agree with Tim. This reminds me of the "three powers" (and I know this is not a State and there is no such thing as a "government")
But, even though this is not a State and there is no such thing as a "government", we all tend to talk this way, and with good reasons. We are a social community and we have social problems ("crime", "disputes") and the mechanisms of government do provide us with analogous concepts to guide us in selecting better mechanisms.
--Jimbo
Tim-
There is no sense in giving developers administrative power.
I tend to agree, although I think it's not a matter of ability (I do not share the "programmers are good at this, not at that" belief; programmers are human beings like anyone else) but a matter of scalability. We can't make everyone a developer for security reasons. Encapsulating community functions like desysopping in the "bureaucrat" flag seems like the most reasonable way forward to me.
That of course does not address the question what these bureaucrats are *allowed* to do.
Regards,
Erik
Erik Moeller:
Tim-
There is no sense in giving developers administrative power.
I tend to agree, although I think it's not a matter of ability (I do not share the "programmers are good at this, not at that" belief; programmers are human beings like anyone else) but a matter of scalability. We can't make everyone a developer for security reasons. Encapsulating community functions like desysopping in the "bureaucrat" flag seems like the most reasonable way forward to me.
That of course does not address the question what these bureaucrats are *allowed* to do.
I tried to make the bureaucrat access work across wikis but Brion was livid. I tested the water on giving bureaucrats the power to desysop on #wikipedia, and the answer I got was firmly negative. What I'm proposing is a minimal change, by replacing developer power with the power of a small set of users who are selected by an appropriate process. Currently, any software engineer can get shell access by putting in a few hours of work, or by bringing a unique skill to the group. It's hardly a good way to select the management of an organisation.
-- Tim Starling
On Mar 9, 2004, at 05:09, Tim Starling wrote:
Erik Moeller:
That of course does not address the question what these bureaucrats are *allowed* to do.
I tried to make the bureaucrat access work across wikis but Brion was livid.
Not exactly. When we first set up the 'bureaucrat' system, somebody (snok?) snuck in interwiki control to it. This made the Sysop Cabal refuse to *allow* the people who needed it to get it (sysops on smaller wikis to manage their own affairs) on the fear that Some Bad Person would use sock puppet accounts on small wikis, trick people into getting bureaucrat access, and then make sysops on the English Wikipedia to do Bad Things.
Later, Tim tried to hack it back in. In addition to the fact that having it destroys the entire point because of the reaction (see above), the code was tied to Wikipedia's setup and not a clean thing to have in the general code.
I tested the water on giving bureaucrats the power to desysop on #wikipedia, and the answer I got was firmly negative. What I'm proposing is a minimal change, by replacing developer power with the power of a small set of users who are selected by an appropriate process. Currently, any software engineer can get shell access by putting in a few hours of work, or by bringing a unique skill to the group. It's hardly a good way to select the management of an organisation.
As developers we do *not* manage the social structure of the wiki. We are servants. We try to keep the servers running smooth and clean and improve the functioning of the wiki. I'm not sure I understand what you're suggesting be _changed_.
-- brion vibber (brion @ pobox.com)
From: "Brion Vibber" brion@pobox.com
As developers we do *not* manage the social structure of the wiki. We are servants. We try to keep the servers running smooth and clean and improve the functioning of the wiki.
And all of you do an excellent job of it! Kudos! You have my admiration for all the work you do, and I include my very sincere thanks. Jay B.
P.S. We should have a Wiki Developer appreciation Month or something like that... ;-)
Following on from my proposal regarding developer access, I've created a meta page:
http://meta.wikipedia.org/wiki/Developer_access
I was thinking that we could flesh out the details, and start taking nominations.
-- Tim Starling
I am not entirely sure I understood all what you proposed Tim :-(
Tim Starling a écrit:
There is no sense in giving developers administrative power. Developers are good at programming, not management of a community. By wrapping up their ability to contribute with their ability to rule, they are made effectively unaccountable. Nobody wants to remove someone's developer access if it means they can't do much needed progrmaming work. Administration of the encyclopedia also distracts them from programming, a task which they have a rare skill and motivation for.
Understood. Developper are good at programming They may or may not be good at administration, and they may like or not like taking care of administration.
I hesitate at using the word management, because I do not see pushing button "ban", "sysop", "unsysop" etc... as management.
pushing these buttons sounds to me like "we trust the guy to listen to the community global opinion, and to do what is a natural consequence of the global opinion and to report what has been done to the community".
As you do.
I do not think the actual power of *decision* is in the hand of the one pushing the button.
Wikipedia should not be a technocracy, ruled by those with knowledge of computer systems. Wikipedia should be a democracy. Those in power should be accountable to the community at large, and ideally selected from and by the community at large.
Accountable and selected by the community yes
Selected like with a vote Accountable such as having to follow rules set by the community, and having to report
I have written a feature giving people with the "developer" flag set in their wiki user accounts a level of administrative ability similar to what developers with shell access are capable of. Specifically, such users are able to set arbitrary user rights for any user on any Wikimedia project. They may create sysops, desysop, create bureaucrats or other developers, or any other user-rights operation you care to mention. This feature is operational right now, and I've been using it for the last couple of weeks to make bureaucrats on various wikis.
So, there are people with a flag of developper, with extended bureaucrat powers, with no shell access
And other people with a flag of developper, with shell access and extended bureaucrat power
did I understand well ?
The feature is easy to use and does not carry the security risks of write-access to the database. At the moment, it is not possible to rename user accounts or change the history of articles through the web interface, but such features are planned.
I suggest we use this feature to split the roles of developer and site administrator. Specifically, here is what I think should happen:
- A policy should be instituted disallowing any developer from using
their power for administrative purposes, except where there is no other way to perform the relevant operation. New developers applying for shell access should be made aware of this policy.
ok
By "administrative purposes", I mean exercises of power for any other purpose than testing and implementing software.
- A small number of users should be made "honorary developers" (perhaps
a better title can be found). These users should be selected by putting forward nominations and then conducting a vote, similar to the vote now conducted at the English Wikipedia for sysop access.
- These "honorary developers" can lose their developer access by a
community vote giving a majority in favour, by an arbitration committee ruling, or by Jimbo's decree.
It should be possible for a developer to hold both shell access and community blessing. Such people would take the role of both programmer and administrator. However as I said above, we really have a lot of programming work to do.
You do not mention rules. Would they have specific rules to follow ? New power should implies more rules to follow
Right now, Erik is typically having this kind of power and administrative task. That means *he participates in setting the rules *he decides when the rules must be applied *he implement the decision *he eventually forget to report :-)
I would like to suggest that at least two rules are necessary
rule 1 : no decision alone : depending on the urgency, Jimbo decision, arbitration committee decision, full vote (like for sysoping someone), poll (like urgent desysoping) I think this rule is very important. No decision taken by a ''honorary developper alone''
rule 2 : report mandatory. Depending on the action taken, on the mailing list, on the wikipedia sysop vote page, on the poll page
Breaking of any of these two rules (without a damn good reason) means suspension of "honorary developer" position.
No power should be entirely in a couple of people hands without rules. And the more power, the more the rules need to be enforced.
-------
Last : when there are questions about the actions of a "honorary developer", the one questioning should be granted free speech and public place to talk.
Anthere wrote:
So, there are people with a flag of developper, with extended bureaucrat powers, with no shell access
And other people with a flag of developper, with shell access and extended bureaucrat power
did I understand well ?
That's how it will be, yes.
You do not mention rules. Would they have specific rules to follow ? New power should implies more rules to follow
Right now, Erik is typically having this kind of power and administrative task. That means *he participates in setting the rules *he decides when the rules must be applied *he implement the decision *he eventually forget to report :-)
I would like to suggest that at least two rules are necessary
rule 1 : no decision alone : depending on the urgency, Jimbo decision, arbitration committee decision, full vote (like for sysoping someone), poll (like urgent desysoping) I think this rule is very important. No decision taken by a ''honorary developper alone''
rule 2 : report mandatory. Depending on the action taken, on the mailing list, on the wikipedia sysop vote page, on the poll page
Breaking of any of these two rules (without a damn good reason) means suspension of "honorary developer" position.
No power should be entirely in a couple of people hands without rules. And the more power, the more the rules need to be enforced.
Last : when there are questions about the actions of a "honorary developer", the one questioning should be granted free speech and public place to talk.
That's all fine by me, as long as the decision to revoke developer access on the basis of rule violation comes from Jimbo, the arbitration committee or a community vote, rather than from a real developer.
-- Tim Starling
wikipedia-l@lists.wikimedia.org