summaryrefslogtreecommitdiffstats
path: root/docs/contributing/filing-good-bugs.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/contributing/filing-good-bugs.rst')
-rw-r--r--docs/contributing/filing-good-bugs.rst56
1 files changed, 56 insertions, 0 deletions
diff --git a/docs/contributing/filing-good-bugs.rst b/docs/contributing/filing-good-bugs.rst
new file mode 100644
index 0000000000..d95e1ac5ea
--- /dev/null
+++ b/docs/contributing/filing-good-bugs.rst
@@ -0,0 +1,56 @@
+Filing good bugs
+================
+
+Getting started working on a bug can be hard, specially if you lack
+context.
+
+This guide is meant to provide a list of steps to provide the necessary
+information to open an actionable bug.
+
+- **Use a descriptive title**. Avoid jargon and abbreviations where
+ possible, they make it hard for other people to find existing bugs,
+ and to understand them.
+- **Explain the problem in depth** and provide the steps to reproduce. Be
+ as specific as possible, and include things such as operating system
+ and version if reporting a bug.
+- If you can, **list files and lines of code** that may need to be
+ modified. Ideally provide a patch for getting started.
+ Do not hesitate to add permalinks to `Searchfox <https://searchfox.org/mozilla-central/source/>`_
+ pointing to the file and lines.
+- If applicable, **provide a test case** or document that can be used to
+ test the bug is solved. For example, if the bug title was “HTML
+ inspector fails when inspecting a page with one million of nodes”,
+ you would provide an HTML document with one million of nodes, and we
+ could use it to test the implementation, and make sure you’re looking
+ at the same thing we’re looking at. You could use services like
+ jsfiddle, codepen or jsbin to share your test cases. Other people use
+ GitHub, or their own web server.
+
+Good first bugs
+---------------
+
+If you're looking to open a bug as a "good first bug" for new contributors, please adhere to the following guidelines:
+
+1. **Complexity**
+ Ensure the bug is not overly complex. New contributors are already navigating the learning curve of Firefox's codebase and workflows. An overly complicated bug can be overwhelming.
+
+2. **Tagging**
+ Use the Bugzilla keyword ``good-first-bug`` to mark it appropriately.
+
+3. **Language Specification**
+ In the whiteboard section, specify the primary language of the bug using the ``[lang=XX]`` format. For instance, ``[lang=C++]`` for C++ or ``[lang=py]`` for Python.
+
+4. **Mentorship**
+ Commit to guiding the new contributor by adding yourself as a mentor for the bug. Please keep the mentor field up to date, if you no longer have time set it to empty or find another available mentor.
+
+
+5. **Documentation**
+ Provide links to essential documentation that can assist the contributor. For example, you might include:
+
+ - :ref:`How To Contribute Code To Firefox`
+ - :ref:`Firefox Contributors' Quick Reference`
+ - :ref:`Working with stack of patches Quick Reference`
+
+By following these guidelines, you'll be setting up new contributors for success and fostering a welcoming environment for them.
+
+These good first bugs can be browsed on https://codetribute.mozilla.org/