MDN/Get involved/Becoming editor: Difference between revisions
(→Open questions: copy-editing) |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 17: | Line 17: | ||
* Prevents Spam very efficiently | * Prevents Spam very efficiently | ||
'''CON''' | '''CON''' | ||
* Requires a manual validation at the lowest level of onboarding which | * Requires a manual validation at the lowest level of onboarding which makes the process flood sensitive. | ||
* Can push away casual editors | * Can push away casual editors | ||
| <!-- Progressive enhancement --> | | <!-- Progressive enhancement --> | ||
| Line 32: | Line 32: | ||
* Do we want new users to be vouched and give them more initial rights? | * 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''. | ** ''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? | * What level of automation do we want to put into this pathway? | ||
** A way to soften the constraints? | ** A way to soften the constraints? | ||
| Line 49: | Line 50: | ||
* Rights | * Rights | ||
** Can read MDN content | ** Can read MDN content | ||
* | * Constraints: | ||
** ''None'' | ** ''None'' | ||
* How to reach the next step | * How to reach the next step | ||
| Line 61: | Line 62: | ||
** Can revert its own edits | ** Can revert its own edits | ||
** Can access beta display features (''new feature'') | ** Can access beta display features (''new feature'') | ||
* Extra | * Extra constraints: | ||
** Can edit only once every 5min (''new feature'') | ** Can edit(/save) only once every 5min (''new feature'') | ||
** Cannot edit more than 20 times a day (''new feature'') | ** Cannot edit more than 20 times a day (''new feature'') | ||
** Cannot add external link | ** Cannot add external link in their edits (''new feature'') | ||
** All change are checked with spam filters (''new feature'') | ** All change are checked with spam filters (''new feature'') | ||
* Condition to soften | * Condition to soften constraints: | ||
** ''TBD'' (''new feature'') | ** ''TBD'' (''new feature'') | ||
* Condition to reach next step | * Condition to reach next step | ||
| Line 73: | Line 74: | ||
=== Step 3: Regular editor === | === Step 3: Regular editor === | ||
'''Definition:''' ''Someone who | '''Definition:''' ''Someone who signs up to become an MDN editor and that we know about.'' | ||
* New rights: | * New rights: | ||
** Can create new | ** Can create new articles | ||
** Can | ** Can add tags | ||
** Can validate review requests | ** Can validate review requests | ||
** Can access beta edit features (''new feature'') | ** Can access beta edit features (''new feature'') | ||
* Extra | * Extra constraints: | ||
** Can edit only once every 2min (''new feature'') | ** Can edit only once every 2min (''new feature'') | ||
** Can create content only every 5min (''new feature'') | ** Can create content only every 5min (''new feature'') | ||
** No more limit to the number of | ** No more limit to the number of edits or creation | ||
* Condition to soften | * Condition to soften constraints: | ||
** ''TBD'' (''new feature'') | ** ''TBD'' (''new feature'') | ||
* Condition to reach next level | * Condition to reach next level | ||
| Line 95: | Line 96: | ||
** Can revert all users edits | ** Can revert all users edits | ||
** Can move pages | ** Can move pages | ||
** Can upload | ** Can upload attachments | ||
** No more | ** No more constraints of any kind | ||
* Condition to reach next level | * Condition to reach next level | ||
** Must be manually upgraded by an Admin | ** Must be manually upgraded by an Admin | ||
| Line 104: | Line 105: | ||
* New rights: | * New rights: | ||
** Can edit kuma | ** Can edit kuma macros | ||
** Can upgrade new editors | ** Can upgrade new editors | ||
** Can ban users (''new feature'') | ** Can ban users (''new feature'') | ||
* Condition to reach next level | * Condition to reach next level | ||
** Must be | ** Must be vouched by two Admin | ||
** Must | ** Must sign an NDA, as Admins can access confidential data. | ||
=== Step 6: Admin === | === Step 6: Admin === | ||
'''Definition:''' ''Us!'' | '''Definition:''' ''Us!'' | ||
* Everything without | * Everything without constraints, which mean too much (''Do we needs super admin?'') | ||
Latest revision as of 11:13, 25 March 2016
NOTE: This page is a draft and its content is discuss on the MDN mailing list
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.
| Gatekeeper | Progressive enhancement |
|---|---|
|
PRO
CON
|
PRO
CON
|
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?)