Skip to content

Latest commit

 

History

History
45 lines (40 loc) · 4.92 KB

5. Steps To Solving a Bug.md

File metadata and controls

45 lines (40 loc) · 4.92 KB
Raw

Steps to Solving a Bug

(Author: Mike Hawes, WNE junior)

Identifying a Bug:

The available Debugger bugs are listed here:

https://github.com/devtools-html/debugger.html/issues?q=is%3Aissue+is%3Aopen

Bugs may be filtered by “Accessibility” or other tags.

  1. Select a bug to work on.
  2. Go to the comments section and put “/claim” in the comment
    • This will identify the bug as being assigned to you.
    • Make sure to “/unclaim” the bug if you are not able to fix the bug.

Solving a Bug:

Figure out what you have to do:

  1. Download the code:
    1. Fork this project: (https://github.com/devtools-html/debugger.html#fork-destination-box)
    • Make sure that all versions are correct. For instance, many projects using the node.js language use different versions.
    • It is important to always use the version specified. This is because many projects include a .lock file that will force certain dependencies to be downloaded. The project will fail to build if these versions are not implemented correctly.
  2. Create a branch to start your work git checkout -b your-feature-name
  3. Verify the bug - go through the steps described in the bug report and make sure that you get the same results.
    1. Go through the steps described in the bug report and make sure you can replicate it. You do this because if you cannot verify it is a bug, how do you know it exists? It may just be a user error. Is there a global dependency (such as a linter or test runner) that I need to install? Does it work on Mac, or only on Linux or Windows?
    2. If you try to fix a bug before establishing that the code works on your machine as-is, you can end up going down a rabbit hole before you even start.
  4. If the bug requires community input, identify one team member to be the community contact and request a contact to provide additional input.
  5. Describe the bug/enhancement - what should the expected behaviour be?
    1. This should be a one-page description
    2. Walk through the keyboard strokes/mouse clicks for the bug/enhancement
  6. If the project has a contributing.md file, search for “test”. Find directions for running the projects tests file to see any errors that might be happening or if the project runs perfectly. If you are unable to find this file, look for a package.json file (if your project requires javascript modules). This file will often describe dependencies and Scripts the project might depend on like the tests.
  7. After running the tests module, you might have found the bug from errors that may have come up. Once you have found the bug or replicated it, you are now ready to move on!
  • Notice, after you complete each one of these steps described above, you should screenshot the page for documentation purposes. This can help also proving in the future that you were able to fix the bug.

Find the code:

  1. Locate the code that is related to your bug. Identify all files and folders involved.
  2. Sketch out the design of the code. Here you’re outlining the existing state in order to identify required changes
  3. Design the change and identify impacted files.
  • Solve the bug! At this point, the errors you may have found by running the test scripts, or opening up the console and seeing some of the available errors might be the only guidance at what the bug is. For help, try to think of some instances of code that might make this bug appear. If you can think of a code set that may produce this bug, then go through the module your claimed bug is from and try and identify code sets like the one you produced.
  • Make sure you take lots of screenshots.
  • NOTE! Even if you are unable to solve the bug completely or fail to fix the bug, you are still able to contribute. Just the fact that you were able to replicate the bug and understand how the bug works, is plenty enough to throw in a documentation that would be a HUGE help to the community. This is because any help you can provide in understanding the bug, is making life that much easier for the next contributor to attempt at solving the issue.

Create a Pull Request:

  1. If solved the bug or replicated it and you have a great documentation or the code you wrote to fix the bug. It is now time for a PULL REQUEST.
    1. Information on how to do a pull request is located here: https://github.com/devtools-html/debugger.html/blob/master/docs/pull-requests.md
  2. If you are unable to reproduce the bug, or want to contribute even more information, try testing out the bug on all different browsers and devices such as, Chrome vs Firefox or an Ipad vs a PC. Writing documentation on the product's effectiveness to run properly on all operating systems and devices is important and having documentation on what works and what doesn't work is also a very important contribution to the community.
  • If all tests run, and you have completed a well written documentation, solved the bug, or both, pat yourself on the back because you just made a contribution to the open-source community. ​