Confirmed users, Bureaucrats and Sysops emeriti
421
edits
Contribute/Coding/Mentoring: Difference between revisions
Jump to navigation
Jump to search
→Good First Bugs
| Line 6: | Line 6: | ||
= Good First Bugs = | = Good First Bugs = | ||
These are tagged as [good first bug] in the whiteboard. | |||
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. | 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 13: | ||
A good, ahem, good first bug includes an extremely narrow scope, clear hardware and platform requirements, and prompt reviewer followup. | A good, ahem, good first bug includes an extremely narrow scope, clear hardware and platform requirements, and prompt reviewer followup. | ||
Unfortunately | 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. | ||
=== Narrowly Scoped === | === Narrowly Scoped === | ||