[Foundation-l] models for adminship/wiki leadership

Carolyn Doran cdoran at wikimedia.org
Tue Apr 10 09:05:26 UTC 2007


Quit making sense! ;)


Delphine Ménard wrote:
> I would argue that for such a survey, a wiki page would be a good
> idea, that could be linked from one wiki to the other.
>
> The idea being tthat one wiki's community could answer those questions
> within a delimited time (say, 3 weeks) and that this page is updated
> as rules change and evolve.
>
> I think such surveys on various topics can be very helpful in the
> cross-cultural communication between projects (and here I mean project
> culture, not necessarily national culture).
>
> A million subjects come to mind as to what those "cross wiki surveys" could be:
>
> Adminship: how it works, what it does, how has it evolved, and a part
> about "suggestions from improvement".
>
> Articles for deletion: How it works, what it does, advantages and drawbacks etc.
>
> Copyright issues: how are they noted, how are they treated, what's the
> tolerance, what are the specific rules in place in your project..
>
> And so on.
>
> A list is too much of a troll magnet, in my opinion. ;-)
>
> Whatcha think?
>
> Delphine
>
> On 4/10/07, Brianna Laugher <brianna.laugher at gmail.com> wrote:
>   
>> Hello,
>>
>> I am interested in finding out what models or processes different
>> projects use to decide adminship. And especially how those processes
>> adapt as the wiki community grows.
>>
>> Note: this is not an invitation to bitch about the administrators at
>> your (least)favourite project.
>>
>> There are some common views about adminship:
>> * Adminship is an expression of trust of an individual by the community.
>> * Adminship is decided by community consensus.
>> * Adminship represents a person taking on a janitorial role, doing
>> maintenance or "meta community" work rather than [in addition to?]
>> content-building work.
>> * Admins are wiki community leaders?
>> * Adminship is no big deal?
>>
>> In technical terms, the admin has several extra functions at their disposal:
>> * un/protect pages from editing or moving, edit protected pages
>> * un/delete pages, view deleted pages
>> * un/block users
>> * rollback edits (basically redundant since the introduction of 'undo'
>> functionality)
>>
>> Admin status is easier to get than it is to revoke. Admin status
>> doesn't have an expiry date [...yet???] and de-adminship requires
>> contacting a steward and demonstrating community consensus for the
>> de-adminship decision.
>>
>> The word 'status' implies something that is often felt, that adminship
>> is recognitition of one's work/worth in a wiki, like a reward; that
>> admins are "above" "regular" users or their opinions hold more sway.
>> Admins generally can perform actions like declaring a discussion
>> closed, even though any user, even unregistered, could make the same
>> edit. I have a suspicion that an admin performing the action is seen
>> as making it "official", though.
>> Admins are often looked to for help, by new users. Sometimes an
>> "administrator's noticeboard" exists, although all users can generally
>> edit it.
>>
>> Does it matter if admins are inactive? Does it matter if admins edit
>> actively but don't use their admin tools? Do they have to keep using
>> them to "deserve" them?
>>
>> If admins are looked to for help and as community leaders, is not
>> having inactive admins somewhat deceptive?
>>
>> Meta has an adminship policy I am quite fond of:
>> http://meta.wikimedia.org/wiki/Administrator_on_Meta
>> "Sysop-hood is not a lifetime status. Get it if you need it. Keep it
>> if people trust you. Quit it if you do not need it. Lose it if people
>> feel they cannot trust you. Sysop status on meta will be granted for
>> one year. After that time, people will be able to vote to oppose a
>> sysop. If there is no opposition for the sysop to stay sysop, then
>> they stay sysop. If opposition is voiced, then the sysop may lose
>> sysopship if support falls below 75%. No quorum is required. It is not
>> a vote to gain support status, but a poll to express disagreement with
>> the current situation. The point is not to bug everyone to vote to
>> support the sysop again (if there is no opposition, there is no point
>> in voting your support again), the point is to not allow sysop-hood
>> status to stay a lifetime status. If a sysop is not really strongly
>> infringing rules, but is creating work for the community because of a
>> lack of trust, then it is best that people have the possibility to
>> express their opposition."
>>
>> But I wonder if it is not kind of a lot of work.
>>
>> Who are the RfA voters?
>> Once a community reaches a certain size, it's not possible to know
>> everyone and notice their work just by glancing over Recentchanges
>> every few days. It becomes more necessary to rely on trusted
>> testimonials. I trust User A's judgement, and User A endorses
>> Candidate B, so I will endorse Candidate B too. It encourages
>> something of the dreaded "cabal", a tight-knit group which it is not
>> possible to break into simply by doing good work - you need to "know"
>> the right people to succeed. I guess we all want to avoid that, but
>> when the wiki is so big, how is it possible?
>>
>> Many people here will be familiar with English Wikipedia RfA, where
>> people's support or opposition for a candidate can rely on seemingly
>> trivial and ever-more-specific requirements. It is doubtful whether
>> all the current admins would pass such requirements, but they manage
>> to keep their adminship by virtue of not doing anything worrying or
>> damaging enough to have it removed.
>>
>> I guess I am not the only person who is active on a non-enwp project,
>> and who wonders how RfA evolving like enwp can be avoided. I want to
>> know what other possible evolutionary paths are there? How can I help
>> influence my project to a more healthy, sustainable model?
>>
>> So I want to know some ideas that other wikis use. Meta's "1 year
>> confirmation" is one. What else is there? What else could there be?
>>
>> While writing this mail it occurred to me that perhaps part of the
>> problem is multiple   goals being conflated in adminship, ie "janitor
>> role" "community leadership". There are few ways to be considered a
>> community leader, I would posit, apart from adminship. Sure, if you're
>> lucky, someone might throw you a barnstar, but it's not like
>> *official* *community endorsement*.
>>
>> Perhaps we need to create a post for designated community leaders.
>> (Community Leaders -please brainstorm a better term...)
>> Declaring someone a Community Leader would be an expression of trust
>> and endorsement. It would be an explicit recognition of a user's
>> worth, their contribution, to that wiki. It would be decided by
>> community consensus. It would not represent a janitorial role or
>> maintenance work, quite the opposite - it would represent someone who
>> excels at a particular (or multiple) aspect of collaborative content
>> building.
>>
>> There would be a page with a list - official endorsement. Community
>> Leaders would represent very good "go to" people for new users needing
>> help in some area.
>>
>> There would probably be very high overlap between admins and Community
>> Leaders, especially at the start. As the process became stronger, it
>> would be much clearer for new users who want to contribute, which
>> process (RfCL/RfA) is appropriate for what they want to achieve. For
>> status in the community, one should aim to be a Community Leader.
>> And then maybe adminship would really become "no big deal". Instead of
>> dealing with so many disputes, admins would be more about enacting the
>> decisions made by Community Leaders - a better reflection of the
>> division between the community role and the technical/maintenance role
>> that are currently both conflated within "adminship".
>>
>> I welcome any ideas about all of this.
>>
>> regards,
>> Brianna
>> user:pfctdayelise
>>
>> _______________________________________________
>> foundation-l mailing list
>> foundation-l at lists.wikimedia.org
>> http://lists.wikimedia.org/mailman/listinfo/foundation-l
>>
>>     
>
>
>   
qui


More information about the foundation-l mailing list