Confirmed users, Bureaucrats and Sysops emeriti
421
edits
Contribute/Coding/Mentoring: Difference between revisions
no edit summary
(Added link to bugzilla search of good first bugs) |
No edit summary |
||
| Line 19: | Line 19: | ||
=== Narrowly Scoped === | === 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 problem statement and successful outcome are unambiguous. | ||
* The bug should link to the code to be modified using a DXR link. | * 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 | * The bug is not time-critical, blocking on or being blocked by anything else | ||
| Line 36: | Line 36: | ||
= Good Next Bugs = | = Good Next Bugs = | ||
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 | 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 === | === Clear Requirements === | ||
| Line 48: | Line 48: | ||
= Diamond Bugs = | = Diamond Bugs = | ||
Marked as [diamond] on the whiteboard, this label doesn't speak to a bug's difficulty, but | 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. | 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 54: | Line 54: | ||
= Experience Required = | = 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 | 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. | 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. | ||