Requests for Comment/Future of Wikicreators

There has been a bit of thought lately (mostly from me) that given the increase responsibility of wikicreators and that it's sort of changed from 100% technical role where trust was necessary to a role now that over time, the level of trust needed has decreased but the responsibilities have increased massively - it's time to redefine both the role and management of wikicreators.

For a bit of history and current knowledge:
 * wikicreators were made back when Special:CreateWiki was made to allow non-sysadmins to make wikis.
 * wikicreators were appointed on the sole discretion of a sysadmin, the community had no say in the appointment or even removal of the right.
 * With the introduction of ManageWiki, wikicreators naturally were given the ability to use the global interface on meta (being able to edit every Miraheze wiki).
 * The natural development of ManageWiki has lead to a lot more abilities being added, naturally giving wikicreators a lot of control of individual communities and the ability to do a form of consensus-management.

This RfC will be split into role statement, rights, appointment, removal, exceptions and then anything else others wish to add/clarify.

Proposal 1
Wiki creators are responsible for managing wiki requests and creating wikis.

Proposal 2
Wiki creators are responsible for manage wiki requests, creating wikis and helping communities through the use ManageWiki subject to communities consensus and global/local policies.

Rights
This is a section where supporting/opposing individual local rights for the 'wikicreator' group will happen.

createwiki
The createwiki right allows users to create wiki using [{Special:CreateWiki]].

managewiki
The managewiki right allows users to access Special:ManageWiki and associated special pages, allowing them to change settings on all wikis (including metawiki) that are not deemed dangerous (restricted). This behaviour is similar to having access to Special:ManageWiki on every wiki at the bureaucrat level.

managewiki-restricted
The managewiki-restricted rights extends the right above allowing the user to edit all settings including ones deemed by sysadmins to be either dangerous or requiring extra work. This is the level above local wiki bureaucrats and requires a level of trust to have.

Discretion of sysadmins
This is the current status quo, and if all proposals fail this will be the outcome regardless of this sections approval.

Sysadmins will have the sole discretion to give wikicreator to any user they deem fit enough or trusted to carry out the role. Stewards will grant the rights as requested by a sysadmin.

Proposal 1
A user requests the right at Requests for permissions. A request will a minimum of 7 days. The closing steward will weigh up the comments and decide whether to grant the rights or not (no minimum support percentage, comments count not votes).

Proposal 2
A user requests the right at Requests for permissions. A request will last a minimum of 7 days. The close steward will weigh up the comments and decide whether to grant the rights or not (ideally there should be around 70% support).

Proposal 3
A user requests the right at Requests for permissions. A request will last a minimum of 7 days. The close steward will weigh up the comments and decide whether to grant the rights or not (ideally there should be around 80% support).

Proposal 4
A user requests the right at Requests for permissions. A request will a minimum of 3 days. The closing steward will weigh up the comments and decide whether to grant the rights or not (no minimum support percentage, comments count not votes).

Proposal 5
A user requests the right at Requests for permissions. A request will last a minimum of 3 days. The close steward will weigh up the comments and decide whether to grant the rights or not (ideally there should be around 70% support).

Proposal 6
A user requests the right at Requests for permissions. A request will last a minimum of 3 days. The close steward will weigh up the comments and decide whether to grant the rights or not (ideally there should be around 80% support).

Removal
The sysadmin, steward + community clause can all pass and form three ways to be removed outside of inactivity.

Sysadmin discretion
Sysadmins, being the solely responsible for the technical and smooth running of Miraheze, may request a steward remove a wikicreator's rights if in their opinion: that user has either caused damaged, has the potential to cause damage, is creating unnecessary workload for sysadmins directly related to their access being granted by wikicreator.

Steward discretion
Stewards, being responsible for ensuring community consensus is enforced and the communities views are respected, may remove a wikicreators rights if a user is repeatedly violating policies related to wiki creation (Content Policy) or is using their managewiki rights (if granted above) in contravention to expected standards or local wiki policies.

Community consensus 1
Any member of the community may open a request for the removal of a users rights and if neither of the above two clauses apply, the users rights will be removed if the discussion reaches 50% in favour of removal within a reasonable time period.

Community consensus 2
Any member of the community may open a request for the removal of a users rights and if neither of the above two clauses apply, the users rights will be removed if the discussion reaches 70% in favour of removal within a reasonable time period.

Inactivity 1
A user may have their rights removed if they do not contribute to the global community in any form within the last 3 months.

Inactivity 2
A user may have their rights removed if they do not contribute to the global community in any form within the last 6 months.

Sysadmins avoid appointment clause
Any user who is made a sysadmin by internal procedure, will be able to be given the wikicreator rights regardless of the appointment clause that is passed.

Sysadmins avoid inactivity clause
Any user who is made a sysadmin by internal procedure, will be exempt from meeting the activity requirements passed above.