diff --git a/devtools/docs/contributor/contributing.md b/devtools/docs/contributor/contributing.md index 51c5ec374425..78ba6c71a701 100644 --- a/devtools/docs/contributor/contributing.md +++ b/devtools/docs/contributor/contributing.md @@ -28,9 +28,9 @@ If you're more interested in user experience (think: wireframes, workflows, navi ## Help with BUGS! 🐛🐞 -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 😀 diff --git a/devtools/docs/contributor/contributing/filing-good-bugs.md b/devtools/docs/contributor/contributing/filing-good-bugs.md deleted file mode 100644 index 9046b3fc10a0..000000000000 --- a/devtools/docs/contributor/contributing/filing-good-bugs.md +++ /dev/null @@ -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`. diff --git a/docs/contributing/filing-good-bugs.rst b/docs/contributing/filing-good-bugs.rst new file mode 100644 index 000000000000..50d69e1c4e83 --- /dev/null +++ b/docs/contributing/filing-good-bugs.rst @@ -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``.