• Launchpad Entry: lucid-qa-mentoring-program

• Created: UDS Karmic - Reviewed on Lucid

• Contributors: Pedro, Hggdh

Summary

We will encourage specialization and mentoring in the bug-control team this cycle.

Rationale

Specialization within the bug control team will help build up the level of expertise in that team which will in turn help boost the bugsquad through the mentoring program.

User stories

• Ken is trying to help the Ubuntu project. He joins the BugSquad team on launchpad and starts doing some triage, after a while he finds the documentation on HowToTriage bugs and discovers the Ubuntu Bug Control team. He starts to need help in some reports but doesn't know who to contact. In the end he stops doing triage or doing one of not so good quality.

Design

Mentor

Every person on the Ubuntu Bug Control team could be a mentor, they need to know how the community operates and the resources available, more than be knowledgeable in the subject. Their basic responsibilities are:

• Teach the basics regarding Bug Triage

  • Review the HowToTriage guide with the mentee in case there's any doubt of the process.

• Introduce the mentee to the general triage WorkFlow and life-cycle of a bug.

• Encourage the mentee to join the official channels of communication

  • BugSquad and QA Mailing list

  • IRC Channel: #ubuntu-bugs

• Introduce them to the related Ubuntu activities, Ubuntu Bug Days, Ubuntu QA and BugSquad Meetings, OpenWeek, etc.

• Encourage Package or Area of specialization (ie: Server, Python, Kernel, Desktop, KDE, etc).

  • See: https://wiki.ubuntu.com/BugSquad/AdoptPackage

• Send monthly updates of their work with the student.

Mentee

The requirements for being a mentee are:

• Sign the Code of Conduct.

As a recommendation but not required they also could:

• Read the HowToTriage guide before requesting the mentorship.

• Provide an Area of Interest (ie: Kernel, Sound, Network, Desktop, etc) with the application form.

Please note that often newcomers might not know what they're interested in yet.

Implementation

Requesting a Mentor

• The person with the interest of being a mentee should request membership on the Bugsquad Mentorship team on Launchpad.

• The Mentor receiving group will ask the available mentors if any of them could be the mentor of the new person, after agreement the contact is made, but there are some requirements before assigning the mentor:
  • The mentor and mentee can't both speak the same mother tongue, this prevents the pair from working too much in isolation from the wider community and helps newcomers who aren't necessarily familiar with English to practice it.
  • They should share a set timezone frame or being in the same one to increase the communication between them.
  • It's recommended that mentors can't generally take more than two mentees, however special cases can be decided by the receiving group.

Action plan

• Start the setup of mentors
• Decide who will be part of the mentor receiving group
• Ask the ML for mentors, and then announce it at the meeting on the 7th July.
• Document the specialist roles (forwarders, package hook writers, unprivaters,
  • etc). and generate interest for these
• Create wikipage for specialist interests like the current specialization in
  • pakages page.

Other todo items

• Create a team for forwarding bugs upstream.
• Make the announcement public instead of on the ML only
  • Ask people who haven't yet signed up to sign up to the ML.
• Make bugcontrol a real team by asking the lurkers to either become active or cancel their membership.
• Send a more personalized message to those who haven't touch a bug in a while.
• Update the documentation on how to upload a fixed package.

Unresolved questions

Several questions are not resolved directly in this spec but will be addressed in bug community discussions over the next few weeks and months. The spec is informational and can be approved with these questions outstanding:

• Decide if the BugSquad team on Launchpad is going to become closed and which are going to be the requirements for join the team is not going to be cover on thids spec, needs to be discussed on the appropiate mailing list. Options:

  1. bugsquad should remain open so that someone doesn't necessarily have to go
     • through mentorship
  2. bugsquad team should have requirements: sign the CoC, triage a few bugs
     • before hand, agree to follow the procedures to the best of your ability, apply/ask.

• HowTo become a mentor.

  • Is the wiki page enough? should it be announced somewhere?
• Maximum duration of the program?
  • Mentoring ends when the student join the ubuntu bug control team, but should there also be a time-out (90 days) where the mentorship ends if there is no forward progress?
  • Should there also be a 90 day probational period, for the mentor to see if the mentee will actively participate in bug-control?
• Should the mentoring program be a requirement for people who wants to join the Ubuntu Bug Control team?
• Should we encourage package specialisation, or specialisation in just bug-control, or should we encourage specialisation in bug-control and another part of Ubuntu?
  • {Server,python,desktop,kde,etc} package specialisation? A team to convert private bug reports to public? A team to write package hooks? Broad categories so we don't end up with 50 teams.

Discussion

During Lucid UDS we reviewed the program, discussion notes as follow:

UTC+6 UTC+12 mentors are missed

In a meeting have a status update as to how proteges are doing

ask the mentors to install the launchpad extensions (firefox-lp-improvements) to follow the students

ACTION: identify and document expectations of mentors ACTION: send an email to the bugcontrol team to decide the time the mentoring is going to last. ACTION: ask to the mentor receiving group if they're still having time to work.

TODO: document how to request a mentor

• add IRC name.
• add Timezone.
• make the instructions a bit more clear.
• [DONE] replace the 72 hours for ASAP.

TODO: mentor requirements updates.

• send monthly updates just before the meeting so we can include them on the bugsquad meeting.
• make a requirement to join IRC and mailing lists.
• encourage the students to join the bugdays at least once.

ACTION: Ask to the launchpad team about rights (bug supervisor) on packages rather than in all launchpad.

TODO: rewrite packages w/o bug subscribers in launchpadlib and distribute in ubuntu-qa-tools so it can be used for directing proteges to a package (Brian Murray)

ACTION: make the bugsquad team on launchpad a closed one, requirements:

• Sign the CoC.
• Subscribe to the bugsquad mailing list.
• Investigate converting the bugsquad mailing list from a mailman one to a launchpad one (easier to verify subscription and for people to be autosubscribed when joined)
• Expire all existing memberships for the team

---

CategorySpec