At the moment, the page that lists mentors is not really easy to create and maintain. We've been able to have this page made of wikitext, with some advice at the top, only because the page was manually created under supervision. And sometimes, some elements were missing: advice at the top, mentors' descriptions badly formatted, etc.
Scaling to more wikis en masse will make impossible to monitor that page creation. We need a special page integrated to the Growth experience to replace it.
Idea #1: a special page
This special page would display the list of all mentors.
- Limit access. If a user hasn't reached a given threshold, they can't add their name to this page. (By default: 500 edits + 30 days of experience)
- Only you can edit the page. It is not possible to edit other's descriptions (maybe have a workaround, for very trusted users (bureaucrats & stewards?), so that they can remove any offensive content because a mentor went rogue). IT would also solve the problem of names or links interfering, like T255666: [scale] Have the mentorship module to pick people only from the list of mentors, but not from other usernames listed on the page
- Have a description at the top, with a link to best practices: https://www.mediawiki.org/wiki/Growth/Communities/How_to_interact_with_newcomers
- Provide a field for mentors to add their description, matching the 240 characters limits we've set. This would also prevent any kind of wikitext formatting being added.
- Have a way to distinguish two roles: Teacher and Mentor (see T245639#6509843)
Comments about requirements listed on description
- Limit access. If a user hasn't reached a given threshold, they can't add their name to this page. (By default: 500 edits + 30 days of experience)
⚠ Such a change would be fairly trivial to introduce by using user rights, generally speaking. However, the specified defaults would make this a bit harder. 500/30 is enwiki's extended confirmed user group, adopted by few other wikis as well. However, it is not MediaWiki default. If we really want to use 500/30 rather than MediaWiki's native autoconfirmed group, we would have to introduce such a group globally. Technically speaking, that would not be a problem, but this could be a concern from the community perspective. @Trizek-WMF or @MMiller_WMF have probably some opinions about this.
- Only you can edit the page. It is not possible to edit other's descriptions (maybe have a workaround, for very trusted users (bureaucrats & stewards?), so that they can remove any offensive content because a mentor went rogue). IT would also solve the problem of names or links interfering, like T255666: [scale] Have the mentorship module to pick people only from the list of mentors, but not from other usernames listed on the page
✅ This should be easy. We can use MediaWiki's native user rights system, and assign this permission to some (default) group. I personally propose administrators, since bureaucrats are traditionally responsible for user rights management.
- Have a description at the top, with a link to best practices: https://www.mediawiki.org/wiki/Growth/Communities/How_to_interact_with_newcomers
✅ That is trivial to do, and standard for special pages. We can even link to mw.org for docs, as we do with Special:ClaimMentee already.
- Provide a field for mentors to add their description, matching the 240 characters limits we've set. This would also prevent any kind of wikitext formatting being added.
✅ No issues with this one.
- Have a way to distinguish two roles: Teacher and Mentor (see T245639#6509843)
✅ Should be ok.
Implementation notes
It should be possible to store the information to user properties table (used for user preferences). However, I believe that it would be better to create a new database table for mentors, That would allow us to scale mentorship feature easily, add more information for each mentor, etc. easily, without having to re-think the whole model. Second reason is that storing it into the user_properties table would require us to search by up_value, which isn't something the table is built for.
Creating a new database table is something that's currently being tried by our team for add a link recommendations. The DBA team would be certainly happy to help, if needed.
How hard will this be?
Building the interface for the sign up form is easy. However, figuring out where to store the information about the list of mentors is tricky. We can try to edit the backend wiki page via the sign up form, which is hopeless, because wikitext is not structured. We can store it as an user property; that would mean we would have no ability to enforce who can be a mentor (ie. no permission checks), since anyone can edit their own user properties via the API. Third option would be creating a database table for mentors, which would fix all the issues with other methods, but it is not a trivial amount of work, and would probably require more than a week of work.
Idea #2: using Special:MentorDashboard
Now that we have the Mentor dashboard being built, we can imagine to have this dashboard as the sign-up page. We would rely on the database to actually sign up.
Possible path:
- a user wants to become a mentor
- they visit special:MentorDashboard
- this page can display some explainations about what it means to be a mentor, and what is expected.
- if they pass the threshold defined by the community (at the moment, the level of protection of the sign-up page), they have access to a button for the next step.
- If they don't, they get a message about the conditions
- this page can display some explainations about what it means to be a mentor, and what is expected.
- the user is invited to define their personal message, and their mentor status (global or workshop). They are warned that, as soon as they click on "next" they will potentially get some questions soon!
- the dashboard is enabled, mentor is active.
The current sign-up page would not be necessary anymore, or should be transformed to become the "official" list of mentors with their description, with a possibly to see their activity, to spot inactive mentors, for newcomers to request to change mentors based on the existing choices...
Mentors can quit and reassign their mentees anytime, using the appropriate dashboard module.
Points of vigilence
Some wikis use the mentor's list talk page as a coordination page. We need to take these pages in consideration if we change the list format.