*signs up*

This was discussed at our meeting on January 30 2017.

We've noted that there was a mentoring project already, but it died out. In fact, there seem to be more than one:

• https://fedoraproject.org/wiki/Mentors (Process: https://fedoraproject.org/wiki/Mentors/Process)
• https://fedoraproject.org/wiki/Fedora_Student_Mentor_Program

So, this time, we'd like to organise it in a way that makes the system sustainable. What I can think of to this effect:

• the project must not rely on only one or two POCs (points of contact). Their absence usually results in the project dying out.
• we should ensure that the workload is well spread out - ensures that mentors are not overworked, and that they can pay the required attention to menatees (an upper limit on how many menatees a mentor can take up?).
• we need to ensure a constant stream of new mentors coming in to replace ones that turn inactive (common issue with FOSS projects tbh)

Questions I can think of off the top of my head:

• who can be a mentor?
• how do we link mentors to newbies?
• do we need to track mentoring like the ambassadors do? tickets and things?

@jflory7 , @mattdm , @mailga , @robyduck , @eischmann @tuanta, @bochecha, @cwickert - ideas, comments, questions? Please tag others who can give us suggestions/advice too.

Personally I think this is the right way to get more contributors in all teams, and it could also avoid people asking immediately for ambassadors membership. We agree since a long time people should first try to contribute and then eventually apply for becoming an ambassador.
I see many advantages in this process, and each team should nominate mentors, so, answering your questions:
Who can be a mentor?
People nominated by the single groups, mentors not necessarily must be the team leaders. I would rather say, mentors are not team leaders, they should be new contributors who recently applied for that group and found their way into the specific group.

How do we link mentors to newbies?
Through the "Join" process each group has. We should clearly say, once you are subscribed to the ML,and and and.....you should go to "this page and choose a mentor". The mentor will be your POC to get you started, which doesn't mean you cannot talk to others or ask through the channels this group uses normally (ML or IRC).

Do we need to track mentoring like the ambassadors do? tickets and things?
IMO no, although it could be useful for statistics and to measure the workload of each mentor. The problem I see is, there would be no control over the mentor's activities, and after some months or years the process would become uncoordinated.

maybe @bex also has some thoughts on that.

Yes, I would say that we should have a few admins or project leads for this who would actually take care of onboarding of new mentors in very controlled way - to first find out who they are, do they have good enough background to actually teach others, etc... Example: I have industry experience with C++ and Python, for a year or so on World of Tanks and Angry Birds which are nice references right? And yet I still would not dare to teach others either one of these languages, not because I don't know them, but because I do not think that I know all the best practices and the best tricks for performance in case of Python...

IDEA (s)

• Below used term Admin refers to someone responsible for this project (ie project lead or lead mentor) - probably two-three people for redundancy :D
• Admins to properly background-check Mentors and their qualification to actually teach others.
• Use pagure issues to keep track of students and mentors:
  • Every mentor would have a ticket with information about them including short reference - their background, and what can they help students with.
  • Mentor would have the ticket open if they are currently active, and closed if they are too busy with something else at the time.
  • Tags for free and full kind of a status (better wording needed heh)
  • Tickets would be tagged for better orientation by some sort of category like Packaging, Programming, Community, Design, etc...
  • Student would be able to browse these (or simply search for whatever they're looking for)
  • Student would then apply by commenting on the mentor's issue (we would have templates for that, with some basic info...)
• Completely rewrite wiki... I'll draft new page before the next meeting I hope, so we can discuss it, add stuff, ...
• Might even be worth to fire off a new group for this? If that isn't included in the "restart it" already. (And by that i mean irc channel, mailing list, ... i dont know whats there from before...)

And on that note, i think that I can take responsibility for this whole thing (?)

I would not split the mentors off their teams, so no group or separate channels or whatever. I like the admin idea (FMA? Fedora mentor administrator?), but the pagure tickets seem too complicated for new people, though I dislike that. What I see more as a tracking solution, could be a tag for groups-specific issues, where you can set a ticket as mentored. These tickets, through all groups on pagure, could flow into a summarizing page for the FMA and/or all mentors.
You talk a lot about background, but is this really important? I don't care about what you did or if you are an expert in Angry Birds.(taking your statement as example) I care about your knowledge within a specific team, being able to teach others the most important things to get started, how to get help, how to get out of dead ends and so on.
Remember, it will not be easy to find mentors who dedicate most time to others instead of doing stuff by themselves.

Just my 2 cents.

@robyduck yes background is important and relevant as it is the only metric we can use to judge their ability to teach. E.g. you're trying to mentor packaging - do you own packages? No? Good bye. Need some kind of proof of skill. I stated the games I was working on as an example of having the proof and yet i'm probably still not qualified enough to talk about Python, this is to show that people without industry experience are probably even worse off than I am.

Pagure is definitely user-friendly enough, it's as simple as "dear student, go here, use the obvious search bar to find whatever you're looking to learn, and comment on it using this template." Frankly if they can't do that, then they've got nothing to do contributing here... That's like MS Word + printer requirement for a front desk job :D

To clarify, which probably wasn't clear from the pagure mess...

IDEA

• This is the other approach to pagure issues for tracking mentors/students. The first version of using the tickets to keep track of mentors/students is described in the previous IDEA comment.
• No per-mentor tickets, only master tickets for major topics (e.g. packaging, etc...)
  • This would replace the tags described in previous IDEA comment.
  • This ticket would contain brief description of the topic and what can we help with there, and a list of mentors (with links to their profiles)
• Student would not apply to a mentor, but the other way around. Student would merely submit a comment on major topic-ticket (above described) and then one of the mentors would get in touch with them.
• Downside is that mentors themselves would not be able to edit the ticket to add/remove themselves as available (unless given such permissions..) and an admin would have to take care of that.

@robyduck yes background is important and relevant as it is the only metric we can use to judge their ability to teach. E.g. you're trying to mentor packaging - do you own packages? No? Good bye.

Sorry but evidently you didn't get my point here.

Oh and remember, new contributors are not always students, and most of them have difficulties to join IRC, so let's not set other hurdles just for the sake of making tickets in places where they are not useful to the specific teams.

Your last comment is too complicated for me to understand it clearly. Imagine for a user who wants to start contributing.

You're both saying the same thing in different ways, actually. :)
Let me attempt to put everything together in one mega comment with my suggestions added to it. Folks can then quote relevant portions and suggest improvements. it's rather long. Tea/coffee/beer suggested:

What is a mentor?

So, in my puny head, the definition of a mentor is closer to that of a knowledgeable guide than a teacher, in the sense that a mentor isn't supposed to teach you things regularly, give you homework, then chase you to see if you've done it etc. I see a mentor more as someone that just generally guides you wherever required, someone you can go to when you get stuck maybe, or who can tell you where to look or who to speak to, maybe teach you some tips and tricks in the process, someone that you can approach for advice - technical or otherwise - that sort of thing.

This encompasses both your points in a way - the person should have some knowledge of how the Fedora team functions, and they will be a students POC that pays a little more attention to the student than we normally do to our fellow contributors.

Addition of mentors

I'm not really in favour of an admin that does background checks etc. To add mentors, I had thought of two ways that are similar to how the packaging team works:
- existing mentors invite/request other contributors to volunteer
- contributors can be nominated (self nominated too) by non mentors, and maybe they need two or three other community members to add a +1 to their nominations

I don't foresee an issue where we'll have inexperienced community members volunteering to be mentors, and I'd rather not create too many rules - let's keep it open, and without unnecessary process - none of the rules are written in stone, and they can evolve as required. But I'd like it to remain easy and simple for both mentors and menatees.

Removal of mentors

We'll ask mentors to mark themselves as "dormant" if they expect to be busy for short periods of time (a few weeks), and "inactive" if for longer periods of time, say a release cycle. Once every releases, the list can be cleaned up - mentors that have been "inactive" for two release cycles can be removed.

Structure/hierarchy

I don't see the need to create a hierarchy. Mentors can manage the process themselves (once it's been fleshed out), and a subset of the mentors can deal with the housekeeping (call them ticket wranglers?). Folks from Fedora Join will be happy to help with these tasks too.

Mentors have zero extra powers. Being a mentor does not give you access to any extra infra even, apart from the ticket system maybe. All it pretty much does is earn you some more of the community's respect and gratitude.

We can set up a system where mentors earn badges for helping newbies - they'll earn cookies anyway, and their reward will be the satisfaction of seeing their hatchlings contribute to Free software via Fedora. :)

Process

How does this feel?

• Create a new "Mentoring" repository under the Fedora Join group which will own this repository
• All mentors can be part of the Fedora Join pagure group and thus have write access to this repository
• The Fedora-join list + IRC channel can be used (their only purpose is to link contributors with newbies)

Information on mentors

• The main README of the repository will contain an introduction to mentoring, what it intends
• It can contain a list of mentors by region like this:

Some region
------------------
- Mentor name (skills) (mentoring/total capacity) (more information -> link to user page)
- Ankur Sinha (active) (packaging, general community process) (0/3) (link to user page)
..
- Another me (dormant - till dd/mm/yyyy)

- Another another me (inactive)

Since mentors will have write access to the repo, this text file can be kept up to date:

• Update how many one can mentor
• Update how many one is currently mentoring
• Update skills
• Update status (active/dormant/inactive)

If we end up with lots of mentors, we can have separate lists for the various regions and the readme can link to these. Good thing about git - complete file history is stored, and easy to access + parse.

(This ensures that all the info regarding the mentoring movement stays in one place on Pagure, and there is no confusion because some wiki page was not updated. We can ditch the wiki. One does not need to use the command line either - files can be edited using the pagure web interface)

For addition of new mentors:
- File a ticket, using the nomination tag. When a decision is made, the ticket is closed, list updated, mentor added to pagure group.

For yearly/bi-annual clean up:
- Get list of mentors inactive for two cycles
- File a ticket with tag housekeeping
- Update list, pagure join group

For students
- Readme will contain instructions on what to do:
- File a ticket with title Name (FAS username) - would like a mentor please
- In summary, list interests (general if nothing specific)
- Optionally list three mentors from list
- Subscribe to Fedora Join ML, hang out in IRC channel when possible
- Anyone with write access tag it mentoring
- A mentor takes it up, assigns to self, updates count in readme
- When mentor feels menatee sufficiently independent, closes ticket as FIXED, updates count in readme

Students will always have access to the ticket, so they can comment if the rare issue turns up.

Status checks:
- We will invite all mentors and their menatees to attend the regular Fedora Join meetings where we can add "how are you getting along" to the agenda.
- we can even follow the infrastructure group's system of a monthly status check thread on the Join ML

Metrics

How about Fedora Join write a post on commblog and the planet every quarter detailing:
- Number of mentors active
- The increase/decrease in mentor numbers
- Number of students being mentored
- The increase/decrease

Visibility and co-ordination with other teams

Mentors will be involved in other teams already. We can mention the mentoring project on the team's onboarding pages as an extra aid for newbies. (I don't want to make it compulsory because not every newbie may need a mentor). I know the ambassadors team use tickets to track new members, but I don't think any other teams do, so the mentoring pagure repo can be the central place for all mentoring?

The ambassadors mentoring will then be stage 2 - you're a contributor to various teams, now can apply to be an ambassador, a face of Fedora. (I expect people that sign up for ambassadorship after contributing to other teams will have a much easier time of quickly learning and qualifying for ambassadorship.)

CommOps already does posts on community members (how do Fedora etc.), and we can pick some of our new contributors as subject for these for something like a "where are they now?" series.

So, how does that sound?

@robyduck these are proposals and ideas to be discussed on a meeting. I'm not setting ground rules here - no point arguing it.

Like I said in the other ticket, I suggest we flesh out as much as we can on the ticket - more people can chime in here, and a discussion can ensue. The meetings are better left for the final votes - it's quite hard for all parties to attend the meetings and given that they're an hour long only, we cannot have detailed discussions on all aspects of all our tickets there.

Like I said in the other ticket, I suggest we flesh out as much as we can on the ticket

I was referring to the actual IDEA, not really pitching in more ideas and alternatives. We should not dismiss ideas right here... Have a bunch of proposals, sit down in meeting, "which one you like most" and/or maybe even "how can we improve it"

it's quite hard for all parties to attend the meetings

And for me personally it's way harder to keep up with tickets than meetings. I am unable to read the whole thing above. I don't have that one minute. I do however have dedicated time in my schedule for a whole meeting.
I still haven't read your huge comment.

and given that they're an hour long only, we cannot have detailed discussions on all aspects of all our tickets there.

To be discussed in today's meeting!

We've begun working on this. I'm leaving this ticket open as the master ticket tracker - we'll file tickets for the details that we need to focus on - more organised that way. Stay tuned for a lot of updates and a lot of tickets!

Outdated. Closing. If someone wants to work on resurrecting mentors etc., please start fresh tickets.