MDN/Get involved/Becoming editor

Onboarding strategy options

The current discussion suggest we have two possible strategies to onboard new editors:

• A "gatekeeper" strategy: It requires new editors to be vouched by someone (another editor, an admin, etc.) who grants them a large set of rights.
• A "progressive enhancement" strategy: It gives new editors a limited set of rights and progressively enhances their privileges based on their behaviors.

Open questions

In order to get a solid onboarding pathway, the following questions needs to be discussed.

• Do we want new users to be vouched and give them more initial rights?
  • The actual number of people asking for a new account seems to make this hardly sustainable.
  • To sustain that process we need to define what "vouch" means and who's able to vouch.
• What level of automation do we want to put into this pathway?
  • A way to soften the constraints?
  • A way to push user to the next level? to all of them?
  • A way to push candidates to upgrade to those who can promote them?
    • Could it be possible to do it by hand by reviewing editors contribution at regular intervals?
• Do we want a process to downgrade privileges?

Draft process

The following steps describe the suggested process to onboard a user from simple reader up to a full MDN administrator.

NOTE: Every point flagged with New Feature are things that are not yet available on the Kuma platform and will requires some dev work.

Step 1: MDN Reader

Definition: An MDN Reader is anybody accessing MDN (https://developer.mozilla.org) without being identified on the site.

• Rights
  • Can read MDN content
• Constraints:
  • None
• How to reach the next step
  • The user must sign up to MDN

Step 2: New editor

Definition: Someone who has signed up to become an MDN editor

• New rights:
  • Can edit existing contents
  • Can revert its own edits
  • Can access beta display features (new feature)
• Extra constraints:
  • Can edit(/save) only once every 5min (new feature)
  • Cannot edit more than 20 times a day (new feature)
  • Cannot add external link in their edits (new feature)
  • All change are checked with spam filters (new feature)
• Condition to soften constraints:
  • TBD (new feature)
• Condition to reach next step
  • Must introduce themselves on IRC or mailing list
  • Must be manually upgraded by a Core editor or an Admin (new feature for core editors)

Step 3: Regular editor

Definition: Someone who signs up to become an MDN editor and that we know about.

• New rights:
  • Can create new articles
  • Can add tags
  • Can validate review requests
  • Can access beta edit features (new feature)
• Extra constraints:
  • Can edit only once every 2min (new feature)
  • Can create content only every 5min (new feature)
  • No more limit to the number of edits or creation
• Condition to soften constraints:
  • TBD (new feature)
• Condition to reach next level
  • Must be manually upgraded by an Admin

Step 4: Trusted editor

Definition: Someone who has proven being a good MDN citizen.

• New rights:
  • Can revert all users edits
  • Can move pages
  • Can upload attachments
  • No more constraints of any kind
• Condition to reach next level
  • Must be manually upgraded by an Admin

Step 5: Core editor

Definition: Someone who is extremely dedicated to MDN

• New rights:
  • Can edit kuma macros
  • Can upgrade new editors
  • Can ban users (new feature)
• Condition to reach next level
  • Must be vouched by two Admin
  • Must sign an NDA, as Admins can access confidential data.

Step 6: Admin

Definition: Us!

• Everything without constraints, which mean too much (Do we needs super admin?)