Contribute/Coding/Mentoring: Difference between revisions

← Older edit

Contribute/Coding/Mentoring (view source)

Revision as of 21:26, 22 September 2014

542 bytes added , 22 September 2014

no edit summary

Jennierose

canmove, Confirmed users

868

edits

@@ Line 1: / Line 1: @@
+[[Category: Contribute]] [[Category: Coding]] [[Category: Mentoring]]
 This page is intended to describe what makes up a a good first bug, a good Mentored Bug, and to clarify expectations around what constitutes a good bug-mentoring relationship.
@@ Line 6: / Line 8: @@
 = Good First Bugs =
+These are tagged as [good first bug] in a bug's Whiteboard field (examples of [https://bugzilla.mozilla.org/buglist.cgi?list_id=10298598&resolution=---&resolution=DUPLICATE&status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=%5Bgood%20first%20bug%5D good first bugs]).
 The challenge of a "good first bug" is only peripherally about the bug itself. The focus, for a new contributor, should be on getting your development environment set up and learning how to navigate Mozilla's contribution process. There are some [https://developer.mozilla.org/en-US/docs/Introduction excellent documents on MDN] to help you get started, and the #introduction IRC channel exists just to help people getting started as contributors.
@@ Line 11: / Line 15: @@
 A good, ahem, good first bug includes an extremely narrow scope, clear hardware and platform requirements, and prompt reviewer followup.
-Unfortunately, abandoned attempts at first bugs are a common occurrence, and they tie up opportunities for other contributors. Somebody who'd like to be assigned a good-first-bug should have their development environment spun up  and a first attempt at a patch submitted for review before they can be properly assigned the bug.
+Unfortunately abandoned attempts at first bugs are a common occurrence, and they tie up opportunities for other contributors. Somebody who'd like to be assigned a good-first-bug should have their development environment spun up  and a first attempt at a patch submitted for review before they can be properly assigned the bug.
+Advice for new developers: [[Firefox Developer Onboarding]].
 === Narrowly Scoped ===
-An ideal first bug is very narrow in scope, possibly as little as one line.
+An ideal first bug is very narrow in scope, possibly as little as one line, and has the following qualities:
 * The problem statement and successful outcome are unambiguous.
 * The bug should link to the code to be modified using a DXR link.
-* any relevant automated tests should also be identified, as well as instructions for adding any new tests
+* any relevant automated tests should also be identified, as well as instructions for adding any new tests, and
 * The bug is not time-critical, blocking on or being blocked by anything else
@@ Line 32: / Line 38: @@
 = Good Next Bugs =
-These are a the next level up, where the challenge of the bug is actually fixing the bug. There are three parts to a well-described Good Next Bug: a willing mentor, a clear initial description of the problem, clear expectations on the part of the both the mentor and contributor, and a cooperative working relationship as the bug is resolved.
+Marked as [good next bug] on the whiteboard, these are a the next level up, where the challenge of the bug is actually fixing the bug. There are four parts to a well-described Good Next Bug: a willing mentor, a clear initial description of the problem, clear expectations on the part of the both the mentor and contributor, and a cooperative working relationship as the bug is resolved.
 === Clear Requirements ===
@@ Line 44: / Line 50: @@
 = Diamond Bugs =
-Marked as [diamond] on the whiteboard, this label doesn't speak to a bug's difficulty, but certainly speaks to its importance. Diamond bugs are bugs that have been brought up as candidate bugs in engineering's priority-triage processes - for example, front-end engineering's Firefox Priority Backlog meetings - but aren't assigned to an engineer by the end of the triage process.
+Marked as [diamond] on the whiteboard, this label doesn't speak to a bug's difficulty, but rather speaks to its importance. Diamond bugs are bugs that have been brought up as important bugs in engineering's various priority-triage processes - for example, front-end engineering's Firefox Priority Backlog meetings - but aren't assigned to an engineer by the end of the triage process.
 A diamond bug should always have a mentor associated with it. These bugs are an organizational priority, and their successful completion is important; contributors taking on diamond bugs should do their best to communicate their progress frequently in the bug, and anyone mentoring a diamond bug should do their best to turn around a contributor's questions or feedback promptly.
@@ Line 50: / Line 56: @@
 = Experience Required =
-These bugs are very hard.
+These bugs are going to be very hard to fix.
-Bugs flagged as [experience required] are generally bugs that live on the ragged corner-cases between two different pieces of technology - JS and C++ on a specific architecture, or a philosophical disagreement between a particular compiler and a particular set of registers on a particular CPU - that require a deep and fine-grained understanding of the technologies involved. We expect these bugs to take a great deal of time, patience and expertise to address.
+Bugs flagged as [experience required] are generally corner-case bugs that live on the ragged edges between two different pieces of technology - JS and C++ on a specific architecture, or a philosophical disagreement between a particular compiler and a particular set of registers on a particular CPU - that require a deep and fine-grained understanding of the technologies involved. We expect these bugs to take a great deal of time, patience and expertise to address.
 These bugs must have a mentor associated with them, and while they are not typically going to be high-visibility bugs their completion is of very high value to Mozilla, and we're very interested in having a long-term relationship with contributors who can complete them.