MDN/Get involved/Becoming editor: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎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 make the process flood sensitive.
* 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
* Constrains:
* 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 constrains:
* 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 to their edits (''new feature'')
** 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 constrains:
* 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 sign up to become an MDN editor and that we know about.''
'''Definition:''' ''Someone who signs up to become an MDN editor and that we know about.''


* New rights:
* New rights:
** Can create new contents
** Can create new articles
** Can create tags
** 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 constrains:
* 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 edit or creation
** No more limit to the number of edits or creation
* Condition to soften constrains:
* 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 attachement
** Can upload attachments
** No more constrains of any kind
** 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 macro
** 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 vouch by two Admin
** Must be vouched by two Admin
** Must be approved by the legal team as Admin can access confidential data.
** Must sign an NDA, as Admins can access confidential data.


=== Step 6: Admin ===
=== Step 6: Admin ===
'''Definition:''' ''Us!''
'''Definition:''' ''Us!''


* Everything without constrain, which mean too much (''Do we needs super admin?'')
* 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

  • Prevents Spam very efficiently

CON

  • Requires a manual validation at the lowest level of onboarding which makes the process flood sensitive.
  • Can push away casual editors

PRO

  • Allows simple casual editing
  • Does not require a manual attention at the lowest level of rights.

CON

  • Limits Spam but cannot prevent it 100%

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?)