👍🎉 First off, thanks for taking the time to contribute! 🎉👍
We respect your time and want to help you make the most of it as you learn more about this project.
- Reporting Bugs
- Suggesting Enhancements
- Writing Documentation
- Share what you know
- Writing Code
- Issues and Pull Request labels
- Project Overview
The developer tools in most major browsers are just web applications. They are HTML & JS rendered by the browser and talk to the browser itself through an API that gives access to the page internals. This project is a brand new web application interface for JavaScript debugging designed for browsers and JS environments.
We strive for collaboration with mutual respect for each other. Mozilla also has a set of participation guidelines which goes into greater detail specific to Mozilla employees and contributors.
Here is a great GitHub guide on contributing to Open Source to help you get started.
If you find an issue with the code please do file an issue and tag it with the label bug. We'll do our best to review the issue in a timely manner and respond.
We are actively investigating ways of support enhancement requests in the project so these instructions are subject to change. For now please create an issue, tag it with the enhancement label and we will attempt to respond.
Documentation is as important as code and we need your help to maintain clear and usable documentation. If you find an error in here or other project documentation please file an issue and tag it with the label docs.
Give a talk or write a blog post and help others get started. Very few developers know that the debugger is a web app. It's a lot of fun to hear the amazing tools others want to build once they learn that they can!
We'd be happy to link to it here. It could go a long way towards helping a newcomer get started!
We have a number of tools to help you with your code contributions, the following describes them all and how you can make use of them.
If you've contributed to an open source project before and would like to help this one please take a look through the up for grabs issues:
- up for grabs - issues should have clear requirements and a difficulty level set as a label
If you find an up for grabs issue without a difficulty level set as a label or unclear requirements please comment in the issue so we can get that fixed.
If you're looking for a good issue, you can look through the up-for-grabs issues. These issues should be actionable and well documented.
There are several difficulty levels, easy, medium, hard. We recommend grabbing an easy issue, but it's up to you.
- up-for-grabs - issues that are not assigned to anyone and are available to be worked on.
- difficulty:easy - clear expectations and a mentor to help you through.
- difficulty:medium - more complex and may not have as clear expectations.
- difficulty:hard - complex and has some open technical questions.
To begin your work make sure you follow these steps:
- Fork this project
- Create a branch to start your work
git checkout -b your-feature-name - Commit your work
- Create a pull request
Be consistent with the rest of the code in the file
Here are pointers to the DevTools general coding style and formatting guidelines.
We use issues and milestones for planning purposes as well as tracking bugs.
Keep Issues Relevant
We try to keep the number of open issues to a minimum. If work isn't going to be done in a timely manner we would rather close the issue than let them go stale. Closed issues can always be reopened again when we are ready to start the work. This process helps keep the focus of the project more understandable to others.
Intent to implement
When a person is assigned to an issue this indicates an intent to implement. Please ask within the issue if you would like to work on a fix so multiple people don't create pull requests for it.
- Include screenshots and animated GIFs in your pull request whenever possible.
- List any steps necessary to trigger the feature you've created or bug you are fixing
- Always run the unit tests locally before creating your PR
- The integration tests will be run automatically by the CI or you can try running them locally as well
- Once the tests have passed in the PR you must receive a review using the GitHub review system
- To learn more about GitHub reviews take a look at their documentation and video tutorial
- Request review from @jasonLaster or @jlongster by mentioning their names in the PR
Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub
Go to local Development to learn about:
These are the labels we use to help organize and communicate the state of issues and pull requests in the project. If you find a label being used that isn't described here please file an issue to get it listed.
| Label name | query:mag_right: | Description |
|---|---|---|
up-for-grabs |
search | Good for contributors to work on |
difficulty:easy |
search | Work that is small changes, updating tests, updating docs, expect very little review |
difficulty:medium |
search | Work that adapts existing code, adapts existing tests, expect quick review |
difficulty:hard |
search | Work that requires new tests, new code, and a good understanding of project; expect lots of review |
docs |
search | Issues with our documentation |
design |
search | Issues that require design work |
enhancement |
search | Requests for features |
bug |
search | Reported Bugs with the current code |
chrome |
search | Chrome only issues |
firefox |
search | Firefox only issues |
infrastructure |
search | Issues with testing / build infrastructure |
not actionable |
search | Issues need clearer requirements before work can be started |
The debugger.html project is a JavaScript debugger built from the ground up using modern web application technologies. It is designed first for debugging Firefox but also for working with projects like Chrome and Node. The name debugger.html was chosen because this debugger interface is being written using modern web technologies where as the previous Firefox debugger was written in XUL.
devtools.html is the larger umbrella initiative that encompasses the debugger.html and several other devtools projects. The devtools.html project claims its origin from a demo for a Mozilla (Dec 2015) work week in Orlando, FL USA where the team worked under a tight deadline to provide a proof of concept of the Firefox developer tools running in pure HTML; even outside of Firefox. The code for that demo can be found on GitHub under @joewalker/devtools.html.
From that original demo the devtools.html project has progressed quite a bit. To learn more about it please read the devtools.html proposal document and take a look at the devtools.html meta bug for tracking progress.
The debugger.html project is targeted to land in Firefox for Firefox 52. However if you're looking to work directly on the DevTools project which ships developer tools for Firefox and Firefox Developer Edition right now you can find more information on the Mozilla wiki DevTools / Get Involved.