In a worst case scenario, set the module owner as the reviewer, asking them in the comments to pick someone more suitable Please select only one reviewer. The bug itself may contain a clear indication of the best person to ask for a review - Are there related bugs on similar topics? The reviewer in those bugs might be another good choice - We have an out of date `list of modules `_, which lists peers and owners for the module. Running ``hg log`` and looking for regular reviewers might be a solution too. It might be them! - Run ``hg blame`` on the file and look for the people who have touched the functions you're working on. Who is the right person to ask for a review? - If you have a mentored bug: ask your mentor.
#Mozilla bugzilla code#
Mozilla uses `Phabricator `_ for code review.
#Mozilla bugzilla Patch#
Here are some further resources to help: - Check out :ref: `Our Developer_Guide and its parent document ` - Our :ref: `reviewer checklist ` is very useful, if you have a patch near completion, and seek a favorable review - Utilize our build tool :ref: `mach`, its linting, static analysis, and other code checking features Getting your code reviewed - Once you fix the bug, you can advance to having your code reviewed. Browse this component on bugzilla for related bugs Fixing your bug - We leave this in your hands. See pages on `Bugzilla and Searching Bugzilla `_ for further help - Learn the `bugzilla component `_, with which your pet bug is implemented, using the components list. There are a number of ways to do this: - `Search bugzilla `_ for relevant keywords. Fix that one bug ~~~~~~~~~~~~~~~~ If there's one particular bug you'd like to fix about Firefox, Thunderbird, or your other favorite Mozilla application, this can be a great place to start. We maintain two lists: one for projects `based on the existing codebase `_.
#Mozilla bugzilla free#
Of course, if you are not a student, feel free to fix one of these bugs. `Student Projects `_ - are larger projects, such as might be suitable for a university student for credit. They're all about small changes, sometimes as little as a few lines, but they're a great way to learn about setting up your development environment, navigating Bugzilla, and making contributions to the Mozilla codebase. `Good First Bugs `_ - are the best way to take your first steps into the Mozilla ecosystem. Your mentor will help guide you with the bug fix and through the submission and landing process. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With more than a million bugs filed in Bugzilla, it can be hard to know where to start, so we've created these bug categories to make getting involved a little easier: - `Codetribute `_ - our site for finding bugs that are mentored, some are good first bugs, some are slightly harder. Find a bug we've identified as a good fit for new contributors. You might receive some extra information, perhaps also made the assignee. | Once you have found something to work on, go ahead and comment! Let the bug submitter, reviewer, and component owner know that you'd like to work on the bug.
Someone else is already working on it! | Even with no assignee, it is polite to check if someone has recently commented that they're looking at fixing the issue. Finding something to work on - | Bugs listed as 'Assigned' are not usually a good place to start, unless you're sure you have something worthy to contribute. Please see the :ref: `Firefox Contributors Quick Reference ` for simple check list. We make changes to Firefox by writing patches, testing them and pushing them into "the tree", the term we use for all the code in Mozilla-Central. If at any point you are stuck, please don't hesitate to ask at ` `_ in the `#introduction `_ channel.
#Mozilla bugzilla how to#
How To Contribute Code To Firefox = The whole process can be a bit long, and it might take time to get things right.