From 2aa4a82499d4becd2284cdb482213d541b8804dd Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 28 Apr 2024 16:29:10 +0200 Subject: Adding upstream version 86.0.1. Signed-off-by: Daniel Baumann --- devtools/docs/contributing/filing-good-bugs.md | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 devtools/docs/contributing/filing-good-bugs.md (limited to 'devtools/docs/contributing/filing-good-bugs.md') diff --git a/devtools/docs/contributing/filing-good-bugs.md b/devtools/docs/contributing/filing-good-bugs.md new file mode 100644 index 0000000000..c57979dff7 --- /dev/null +++ b/devtools/docs/contributing/filing-good-bugs.md @@ -0,0 +1,11 @@ +# 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`. -- cgit v1.2.3