[Foundation-l] models for adminship/wiki leadership

Delphine Ménard notafishz at gmail.com
Tue Apr 10 08:54:20 UTC 2007


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
>


-- 
~notafish
NB. This address is used for mailing lists. Personal emails sent to
this address will probably get lost.
NB. Cette adresse est utilisée pour les listes de diffusion. Tout
email personnel envoyé à cette adresse sera probablement perdu.



More information about the foundation-l mailing list