Thank you! I was super excited to test it. :)
Here are my notes.

Special:EnrollAsMentor

• This special page should not be accessible to non autocomfirmed users. People with less than 500 edits AND 90 days of presence is the usual protection threshold most communities have defined for their mentor lists.
• Introduction message:
  • It says that it introduces you as a mentor. The context is not obvious for someone who doesn't know about mentoring. Maybe we should say "This introduction message introduces you as a mentor to your future mentees. For instance, tell them that you are ready to help, and what are your favorite topics".
  • Please keep this shorter than 240 characters. Having a counter would help there.
  • No wikitext is allowed. Should we mention HTML not being allowed as well?
• Introduction reason: I don't get what is it and what it does. And as it is not mandatory, should it be kept?

MediaWiki:GrowthMentors.json

• Mentors are identified by their user id. As an admin who'd like to edit a mentor description, it is not easy to use.

Overall

• Despite these details, it is really a great feature!
• I'd like to highlight T311137: Inform mentors about coordination messages left by other mentors as something to consider for the next steps. Enabling this new structured format will make it more difficult for mentors to discuss together.

I think @Iniquity would be happy to test it!

Mentors are identified by their user id. As an admin who'd like to edit a mentor description, it is not easy to use.

I had the same thought. @Urbanecm_WMF I think you could keep the structure, but add a field for username: in the array?

In T312102#8053352, @kostajh wrote:

Mentors are identified by their user id. As an admin who'd like to edit a mentor description, it is not easy to use.

I had the same thought. @Urbanecm_WMF I think you could keep the structure, but add a field for username: in the array?

Thanks for the suggestion. The user ID is used intentionally, to keep the list working when a mentor renames. While I can add the username to the list, I don't think it's reasonably-easy to ensure it stays updated when it changes (although it should be significantly easier, compared to a wikitext list). I think that T312181: Make it possible for admins to edit information stored about other mentors is a better and more accessible solution, as it would allow admins to fully edit the content of the page without even needing to understand JSON. What do you think?

@Urbanecm_WMF Looks good! I have just a few minor UI suggestions and questions:

Special:EnrollAsMentor

• "You can enroll mentorship by filling out this form." This should likely be "You can enroll as a mentor by filling out this form." or "You can enroll in mentorship by filling out this form."
• "Introduction reason" I'm not sure what this is or where this would be used / visible?
• A character counter that matches the "Change your introduction message" UI would be great! (But I also don't think that needs to be a blocker to rollout).
  
• I can't seem to claim a mentee. I still see the "No mentees found" message after trying to claim some test accounts. Is that expected on Beta wiki, or should this be working?

MediaWiki:GrowthMentors.json

• I don't think it's possible to quit mentorship if I don't have any mentees. Or maybe that's related to T311747?
• I agree that it would be nice if we could see a username along with the ID. But I'm fine with waiting for T312181 if you think admins and mentors will be OK with the ID list for now.
• Should we add anything to the intro explaining the fields? message is self explanatory, but weight and automaticallyAssigned are less obvious and don't match the UI language. (Although I just tested and it looks like my assumptions were correct: weight relates to "Number of mentees assigned to me" and automaticallyAssigned is false if I select "None" for "Number of mentees assigned to me").

Thanks for your notes @KStoller-WMF!

"You can enroll mentorship by filling out this form." This should likely be "You can enroll as a mentor by filling out this form." or "You can enroll in mentorship by filling out this form."

Good idea. Uploaded a patch to change that message.

"Introduction reason" I'm not sure what this is or where this would be used / visible?

Since this confuses both you and @Trizek-WMF, this is very likely a poor wording. It isn't meant as "introduction reason", but as a reason for enrollment (why are you enrolling). This is propagated as an edit summary to the MediaWiki:GrowthMentors.json file (like the word "test" at https://en.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki:GrowthMentors.json&diff=552161&oldid=552160).

I see three things we can do to make it more understandable: (1) change the label to "Edit summary" (even though it's not visibly an edit) (2) add a help text under the field to explain where it goes (3) remove the field, and use a fixed summary, such as "enrolling as a mentor". What do you think we should do?

A character counter that matches the "Change your introduction message" UI would be great! (But I also don't think that needs to be a blocker to rollout).

Agreed! I filled this as T312575: Add a character counter to Special:EnrollAsMentor, so we don't forget about this.

I can't seem to claim a mentee. I still see the "No mentees found" message after trying to claim some test accounts. Is that expected on Beta wiki, or should this be working?

I'm not sure what is your betawiki username, so I can't check this directly, but the mentor dashboard doesn't display all mentees, only mentees who were recently active, and it only updates every three hours. Criteria for a mentee to show up are in the (i) icon, see:

You can see all your mentees (with no restrictions) via https://en.wikipedia.beta.wmflabs.org/w/api.php?action=query&format=xml&list=growthmentormentee&gemmmentor=Martin_Urbanec (replace Martin_Urbanec with your own username).

Several other Growth team members ran into this same issue too, which shows it's also not easy to understand. I'm not sure how to make this more visible than the table, but i'm open to suggestions.

I don't think it's possible to quit mentorship if I don't have any mentees. Or maybe that's related to T311747?

Very good catch! Special:QuitMentorship should not check whether you have any mentees when the structured mentor list is in use. Filled as T312577: When structured mentor list is enabled, Special:QuitMentorship does not let mentors with no mentees to quit.

I agree that it would be nice if we could see a username along with the ID. But I'm fine with waiting for T312181 if you think admins and mentors will be OK with the ID list for now.

Yeah. I think most people won't use the JSON file itself, as cases when an admin needs to change someone else's mentorship properties is not going to be common (at least so I hope). There's also action=growthmanagementorlist API that allows admins to write to the mentor list if they need to (granted, that's not at all discoverable). I'll note it in T312181 just in case.

If we want, we can temporarily add the username key, knowing it's not 100% reliable, and remove it later once T312181 is ready. Personally, I don't think that's necessary.

Should we add anything to the intro explaining the fields? message is self explanatory, but weight and automaticallyAssigned are less obvious and don't match the UI language. (Although I just tested and it looks like my assumptions were correct: weight relates to "Number of mentees assigned to me" and automaticallyAssigned is false if I select "None" for "Number of mentees assigned to me").

I think this should be a part of the (to-be-written) technical documentation of the mentor list, as it is hard to get it into MediaWiki itself.

@Urbanecm_WMF Great, glad I could be helpful!

I see three things we can do to make it more understandable: (1) change the label to "Edit summary" (even though it's not visibly an edit) (2) add a help text under the field to explain where it goes (3) remove the field, and use a fixed summary, such as "enrolling as a mentor". What do you think we should do?

I prefer simplicity when possible, so (3) seems like the best solution unless you really think that admins and other mentors find that edit summary helpful in understanding the Mentor's intent.

I'm not sure what is your betawiki username, so I can't check this directly, but the mentor dashboard doesn't display all mentees, only mentees who were recently active, and it only updates every three hours.

Gotcha, OK it looks like I did successfully claim mentees, but they likely weren't recently active. The No mentees found empty state is somewhat misleading, I suppose we could change the language to No recently active mentees found. But I'm not sure how necessary that is: I suppose this is one of those edge cases that comes up in testing and not as much in production when Mentors are assigned recently created (and thus recently active) Mentee accounts. Thanks for the explanation!

If we want, we can temporarily add the username key, knowing it's not 100% reliable, and remove it later once T312181 is ready. Personally, I don't think that's necessary.

OK, let's not worry about it for now; we can always adjust the approach if there is significant community feedback that the username is needed.

I think this should be a part of the (to-be-written) technical documentation of the mentor list, as it is hard to get it into MediaWiki itself.

Perfect, that makes sense to me!

Regarding the change of the "Introduction reason", I think you should just have something like "Adding myself as a mentor" as the diff left by the system. Let's not confuse users by asking them to justify their involvement. :)

In T312102#8065003, @Trizek-WMF wrote:

Regarding the change of the "Introduction reason", I think you should just have something like "Adding myself as a mentor" as the diff left by the system. Let's not confuse users by asking them to justify their involvement. :)

In T312102#8062826, @KStoller-WMF wrote:

I see three things we can do to make it more understandable: (1) change the label to "Edit summary" (even though it's not visibly an edit) (2) add a help text under the field to explain where it goes (3) remove the field, and use a fixed summary, such as "enrolling as a mentor". What do you think we should do?

I prefer simplicity when possible, so (3) seems like the best solution unless you really think that admins and other mentors find that edit summary helpful in understanding the Mentor's intent.

Sounds good to me! Filled as T313252, will upload a patch soon.

In T312102#8062826, @KStoller-WMF wrote:

I'm not sure what is your betawiki username, so I can't check this directly, but the mentor dashboard doesn't display all mentees, only mentees who were recently active, and it only updates every three hours.

Gotcha, OK it looks like I did successfully claim mentees, but they likely weren't recently active. The No mentees found empty state is somewhat misleading, I suppose we could change the language to No recently active mentees found. But I'm not sure how necessary that is: I suppose this is one of those edge cases that comes up in testing and not as much in production when Mentors are assigned recently created (and thus recently active) Mentee accounts. Thanks for the explanation!

I think it would be happening quite often: mentors sign up via the interface (or wikitext page). As soon as they do so, they are offered the mentor dashboard. The mentor dashboard is propagated through its discovery feature (a blue dot, highlighting the newly available option in the menu). If the mentor decides to try things out by claiming users, the same confusion would likely happen.

The wording you suggested makes sense to me – filled as T313261.

FYI: I deployed structured mentor list to beta ar.wiki as well, per @Dyolf77_WMF's request.

Thank you, @Urbanecm_WMF .
I was thinking when I saw the Special:ManageMentors, if it could display the mentors' status (Active/Away). It will be very helpful to monitor mentor's activities.

Checked in betalabs - looks good.

(1) I added a comment - https://phabricator.wikimedia.org/T312575#8093058 - about negative count displayed in the counter (an edge case issue).

(2) About "Data is updated every three hours." not communicated clearly - probably it'd make sense to display it not in the pop-up but underneath "See your mentees below. Use the filters to change which mentees are shown." on Special:MentorDashboard? Especially, now users enrolling as mentors may start immediately claim mentees, expecting them to be added to the table.

(3) Another tiny issue: Special:ManageMentors has an url that reflects the revision, so after an admin removes a mentor and logs out, the link would be contain the revision number, which probably not necessary to display.

(2) About "Data is updated every three hours." not communicated clearly - probably it'd make sense to display it not in the pop-up but underneath "See your mentees below. Use the filters to change which mentees are shown." on Special:MentorDashboard? Especially, now users enrolling as mentors may start immediately claim mentees, expecting them to be added to the table.

I've been meaning to comment or file a task about this. @Urbanecm_WMF, maybe we could say "Data last updated on {timestamp}" where {timestamp} is a config variable that the update mentees script sets when it finishes running? And then we could inform the user about the expected next update timestamp?

@Etonkovidova Thanks for the review! I'll have a look at it later.

In T312102#8093951, @kostajh wrote:

(2) About "Data is updated every three hours." not communicated clearly - probably it'd make sense to display it not in the pop-up but underneath "See your mentees below. Use the filters to change which mentees are shown." on Special:MentorDashboard? Especially, now users enrolling as mentors may start immediately claim mentees, expecting them to be added to the table.

I've been meaning to comment or file a task about this. @Urbanecm_WMF, maybe we could say "Data last updated on {timestamp}" where {timestamp} is a config variable that the update mentees script sets when it finishes running? And then we could inform the user about the expected next update timestamp?

Good idea! We already store the last update timestamp in user preferences, it was added as part of T293454: Mentor dashboard: M1 mentee overview: Add "last updated" indicator and ability to manually refresh mentee data, so adding a sentence about next update should be quite easy.

In T312102#8093064, @Etonkovidova wrote:

Checked in betalabs - looks good.

Thanks for checking!

(1) I added a comment - https://phabricator.wikimedia.org/T312575#8093058 - about negative count displayed in the counter (an edge case issue).

Thanks! I'll reply in the other task.

(2) About "Data is updated every three hours." not communicated clearly - probably it'd make sense to display it not in the pop-up but underneath "See your mentees below. Use the filters to change which mentees are shown." on Special:MentorDashboard? Especially, now users enrolling as mentors may start immediately claim mentees, expecting them to be added to the table.

Thank you (and @kostajh) for the idea. I think this is sufficiently covered by the above discussion. I also filled this as T313617: Indicate next update in Special:MentorDashboard's mentee overview module for the future.

(3) Another tiny issue: Special:ManageMentors has an url that reflects the revision, so after an admin removes a mentor and logs out, the link would be contain the revision number, which probably not necessary to display.

Interesting, thanks for noting this. A small correction: the URL reflects the mentor that's being removed, not the revision ID. I think this behavior is consistent with what other user-based special pages do (cf. Special:Block/Username), but I agree it is not really user friendly now.

Currently, when user logs out (while on the removing URL) and then clicks the "Return to" link, they see the list of mentors (as they don't have the relevant right). That's not really helpful. We can change the behavior to show a permission error instead, like in this screenshot:

This would make the behavior equivalent to the one of Special:Block/Username. We can also change the user ID to username, but I feel like that's putting more work than the issue is worth. What do you think?