Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2025-02-23 10:54:33 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Bug 1855935 - doc: move the doc from devtools to the main contrib doc r=marco,nchevobbe,devtools-reviewers DONTBUILD

Browse Source 
Differential Revision: https://phabricator.services.mozilla.com/D189645
This commit is contained in:
Sylvestre Ledru 2023-09-29 15:04:27 +00:00
parent 3615210b2a
commit 7aa259d1be
3 changed files with 29 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
devtools/docs/contributor/contributing.md
View File

@ -28,9 +28,9 @@ If you're more interested in user experience (think: wireframes, workflows, navi
## Help with BUGS! 🐛🐞 <!--TODO: we might want to split this out to another page with more detail, in addition to this introductory section-->
Not less importantly, we also love **when people file bugs**. They help us a lot and are very valuable (specially when they come with reproducible steps, e.g. in the case of crashes or malfunctions). Here is a short [guide on how to file good bugs](./contributing/filing-good-bugs.md) if you've never done it before (or if you need a reminder).
Not less importantly, we also love **when people file bugs**. They help us a lot and are very valuable (specially when they come with reproducible steps, e.g. in the case of crashes or malfunctions). Here is a short [guide on how to file good bugs](/contributing/filing-good-bugs.html) if you've never done it before (or if you need a reminder).
Another thing that is super valuable is **reproducing** bugs (to validate they're happening in more than one environment), and also **completing** bugs, i.e. ensuring the bug has steps to reproduce, a test case, etc, as [mentioned on the guide](./contributing/filing-good-bugs.md). This saves time for the person(s) who will work on the bug, as then they can jump straight to fixing or implementing whatever is needed, instead of doing research work. If you can do any of these for a given bug, add a comment with the additional data that you found out.
Another thing that is super valuable is **reproducing** bugs (to validate they're happening in more than one environment), and also **completing** bugs, i.e. ensuring the bug has steps to reproduce, a test case, etc, as [mentioned on the guide](/contributing/filing-good-bugs.html). This saves time for the person(s) who will work on the bug, as then they can jump straight to fixing or implementing whatever is needed, instead of doing research work. If you can do any of these for a given bug, add a comment with the additional data that you found out.
Likewise, if you think that a bug is solved, because you can't reproduce it and doesn't happen any more, this is also useful to know. We can always do with closing more bugs, so please leave a comment detailing as much information as you can provide 😀

11
devtools/docs/contributor/contributing/filing-good-bugs.md
View File

@ -1,11 +0,0 @@
# 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 resolve a 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.
* 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.
* If it's a bug that new contributors can work on, add the keyword `good-first-bug`.

27
docs/contributing/filing-good-bugs.rst Normal file
View File

@ -0,0 +1,27 @@
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 resolve a 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.
- 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.
- If it’s a bug that new contributors can work on, add the keyword
``good-first-bug``.