BMO/Onboarding

From MozillaWiki
< BMO
Jump to navigation Jump to search

Bugzilla Engineering Onboarding

  • Start recording using PIN provided by onboarding manager.
  • Introduce self
    • #bteam and #bmo
    • brief history of Bugzilla and how it is written, managed
    • File bugs for any issue or requests such as componennts, etc.
    • weekly releases
  • take a moment to lay out expectations at the beginning of the session as to how you'd like people to interact with you during the sessions
    • we've had some people start and stay facemuted, other doing other things, etc, and as a result one or two of the sessions were just the instructor talking at their own head for the whole thing, which they've commented has been kind of dispiriting. Connecting with your audience matters, so please take the time to think and talk about how to best do that.
  • Employee successfully sets up a bugzilla.mozilla.org account, and updates their phonebook entry accordingly.
    • Use [:nick] format in realname for easy look up
    • Prefer normal account or github auth. Persona going away soon. Future plans for Firefox Accounts
    • Recommend enabling two-factor authentication using OTP or Duo
    • Bugmail setting in Phonebook is useful for auditing purposes so we can keep up with who shouldn't have specific permissions.
  • Employee is granted canconfirm/editbugs access.
    • Normally receive as part of @mozilla.com. If non-mozilla.com, we can add it manually.
  • Employee is able to access mozilla-employee-confidential bugs.
  • Employee installs Firefox Nightly.
  • Employee has read the Mozilla bug filing and bug triage guides.
  • Employee is aware of bug triage SLAs with community (5 days)
    • Not sure about this one and would rather defer to emceeaih
    • more than likely a per-team policy and doesn't exist company-wide
  • Employee has reviewed the high level list of components at https://wiki.mozilla.org/Modules/Core
  • Employee has reviewed the list of people responsible for triage of inbound bugs in Bugzilla components, and is aware of the mismatch between Bugzilla and the Module system
  • Employee queries for newly filed bugs and triages a few of them into the correct component.
    • readable bug statuses (requires new UI)
    • A lot of new bugs go into Firefox :: Untriaged especially those filed using the guided form.
  • Employee queries open bugs in the area they will be working in.
    • Can type bug id directly into quicksearch field to go to the bug. Or create a bookmark keyword such as 'b' and you can just type 'b <id>' in the awesome bar.
  • Employee talks to members of their team about how bugs are triaged, organized and tracked in their component, including team-specific keywords and whiteboard usage conventions.
  • Employee finds or files a candidate really-simple bug to fix tomorrow.
    • set proper keywords, severity and provide descriptive summary.
    • concise reproduce steps
    • assigned developer will normally set priority and target milestone so do not touch those.
    • heightened severity doesn't necessarily mean bug will be fixed faster so pick something reasonable.
    • as much detail as possible
    • Always search for dupes if you can first (some forms make it easier to do) but just file it if not sure. Triager can sort it out.
    • If you find a dupe, add additional information to the bug as a comment and cc yourself.
  • Employee has set up bugzilla watching criteria/teammate-watching.
    • Component watching in user prefs
    • User watching mainly for taking over ones bugs while on PTO for example but not normally preferred.
  • Employee knows bugmail handling and filtering techniques.
    • Basic email filtering through built in core filter
    • Extended filtering using the Bugmail Filtering tab in user preferences
    • Core takes precedence so if core choices block then the extended filters will not be used.
  • Suggest enabling the new show bug UI