ArchWiki:Access levels and roles

ArchWiki differentiates two types of groups in order to independently define access levels and user roles. Compared to the convention, popular in other MediaWiki projects, where each role is represented by a group with its own set of rights, this approach is more flexible, allowing to fine-tune the access level for each user regardless of their roles.

Access levels

Access levels are groups with a non-empty set of granted rights: their purpose is to define the extent of the permissions that users have in the wiki.

The following access levels are assigned automatically by MediaWiki:

  • user is the default group for all users, which grants the basic read/write permissions.
  • autoconfirmed is a group for users with at least 20 edits and 3 days since their account creation . Before these thresholds are reached, user actions are subject to some restrictions aimed at preventing spam attacks.

The following access levels can be assigned manually by a bureaucrat. Members of specific roles may request temporary or permanent assignment of these levels, for example following the acquisition or change of a role, or to address specifically-justified individual needs. Permanent assignments are possible only after internal discussion and approval by the Administrators.

  • privileged is a group for trusted community members with the purpose of allowing to edit most protected pages, such as those in the DeveloperWiki namespace.
  • cosysop is a group for users who have been trusted to partake in wiki maintenance. They are also able to edit most protected pages.
  • sysop is a group for highly trusted users who are responsible for critical wiki-administrative tasks like page deletion or user blocking, thus requiring the demonstration of extensive knowledge of how the wiki is organized. They also have all rights of the checkuser, interface-admin and suppress groups which are created automatically by MediaWiki.
  • bureaucrat is a group for sysops who can grant access levels and roles to other users.
  • bot is a group for ArchWiki:Bots.

Roles

Roles are groups with an empty set of granted rights: their purpose is to clarify the function of wiki users within the Arch community. In general, roles are not removed from users who may become inactive. The Administrators reserve the right to make per-user variations to the default access levels for each role.

  • Maintainers (maintainer) is a group for the ArchWiki:Maintenance Team members.
    • All maintainers are given the cosysop access level by default. Maintainers with the sysop access level are called Administrators. There is also an Administrator fellows (administrator_fellow) group for retired Administrators.
  • Translators (translator) is a group for the most productive members of an ArchWiki Translation Team or individual translators.
  • Arch Linux Developers (archdev) is a group for Arch Developers.
    • All Arch Linux Developers are given the privileged access level by default.
  • Arch Linux Trusted Users (archtu) is a group for Arch Trusted Users.
  • Arch Linux Support Staff (archstaff) is a group for users with other roles within the Arch Linux community:
gollark: Fire is more backwards-compatible and uses simpler tooling.
gollark: No.
gollark: The hilarity of a joke is directly proportional to the square of its length, you know.
gollark: (note: I like Linux and this is a joke, do not potato me)
gollark: What do Linux users do to change a lightbulb?First, a user creates a bug report, only for it to be closed with "could not reproduce" as the developers got to it in the day. Eventually, some nights later, someone realizes that it is actually a problem, and decides to start work on a fix, soliciting the help of other people.Debates soon break out on the architecture of the new lightbulb - should they replace it with an incandescent bulb (since the bulb which broke was one of those), try and upgrade it to a halogen or LED bulb, which are technically superior if more complex. or go to a simpler and perhaps more reliable solution such as a fire?While an LED bulb is decided on, they eventually, after yet more debate, deem off-the-shelf bulbs unsuitable, and decide to make their own using commercially available LED modules. However, some of the group working on this are unhappy with this, and splinter off, trying to set up their own open semiconductor production operation to produce the LEDs.Despite delays introduced by feature creep, as it was decided halfway through to also add RGB capability and wireless control, the main group still manages to produce an early alpha, and tests it as a replacement for the original bulb. Unfortunately it stops working after a few days of use, and debugging of the system suggests that the problem is because of their power supply - the bulb needs complex, expensive, and somewhat easily damaged circuitry to convert the mains AC power into DC suitable for the LEDs, and they got that bit a bit wrong.So they decide to launch their own power grid and lighting fixture standard, which is, although incompatible with every other device, technically superior, and integrates high-speed networking so they can improve the control hardware. Having completely retrofitted the house the original lightbulb failed in and put all their designs and code up on GitHub, they deem the project a success, and after only a year!

See also
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.