Contributing to debugger.html
We respect your time and want to help you make the most of it as you learn more about this project.
- How Can I Contribute?
- Getting Started
- Project Overview
- About Us
How Can I Contribute?
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. We'll do our best to review the issue in a timely manner and respond.
We will also tag it with the label bug.
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, and we will attempt to respond.
We will also tag it with the label enhancement.
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.
We will tag it with the label docs.
Give a Talk
The best thing about giving a talk on the debugger is that you can demo debugging the debugger and watch a roomful of minds explode.
The best talks can be as simple as walking through how the debugger works and adding a small feature. For the audience in the room, this will likely be the first time they've seen the internals of a developer tool.
Write a Blog Post
Our primary goal is to help developers understand they have the skills to improve their environment. Writing about DevTools is the best way to dispell the myth that what we do is magic.
Writing is a great way to share what you learn and articulate your passion. Blog posts can either be technical "how x works" or narrative "how we built x". The most important piece is that it helps people feel welcome.
If you would like to write a post and have questions ask one of us in slack. Also, ofcourse share what you've written in slack! Here are some examples search boxes, getting into the flow, better source maps, stepping debugger.
Organize a meetup
Open source workshops are a great way to bring people together and contribute. The best thing about workshops is that it's the best way for new comers to make their first PR. It's also a lot of fun!
There's been four workshops so far. Two in New York, one in Tel Aviv, and one in Vancouver. The workshops have helped close to 100 people get started. In all of the cases, the workshop was organized in collaboration with a local meetup group that was interested in promoting open source.
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!
Getting started on an open source project is like starting a new job. Expect to spend the first day learning the codebase and meeting the team.
The best thing to do first is to answer specific questions like: "how are sources shown on the left?". Here is a guided activity to help you get started.
It's also helpful to think about who is working on the Debugger and people you might want to ask for help early on. We are lucky to have lots of nice people here.
Your First Code Contribution
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.
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.
Go to local Development to learn about:
- Issue Titles
- Issue Descriptions
- Claiming Issues
- Up For Grab Issues
- Issue Organization
- Community Friendly
Go to Pull Requests to learn about:
Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub
Here are some tips from fellow contributors.
- Time management is really important. Try your best to balance obligations.
- Communicate Communicate early and often. Share your work often and try to land the smallest possible pieces.
- Goals It's helpful to set realistic goals.
- Work Consider talking with your manager about OSS time at work. There are several reasons why this makes sense for your employer:
- expertise teams benefit from having a resident expert on debugging or other tools
- marketing your manager can market his team as OSS friendly to candidates and other employees.
- career development the skills you learn in OSS translate to your own growth.
- sponsoring your team benefits from having quality OSS tools. Sponsoring your OSS time is a great way to give back.
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.
Firefox Developer Tools
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.
debugger.html community team members help shephard the community. They are here to help mentor new comers, review pull requests, and facilitate issue discussions. They are a fantastic resource and genuinely friendly human beings.
Mozilla has and continues to hire many people from within the Open Source Software community, bringing contributors directly into the team; however contribution is not necessarily a path to employment. Our internal hiring criteria is about more than contributions, we are also looking at a number of other factors that create a diverse and healthy team.
Ask. Take a look at the current openings in https://careers.mozilla.org/ to see if there is a good fit for you. If you’re interested in a job with Mozilla feel free to ask employees what it’s like to work here. However employees can’t help you get hired outside of being a referral for you.
Referrals. If you’ve been making reasonable and regular contributions to the project we’d be happy to be a reference for you. We can make internal referrals to Mozilla or act as your reference to other companies. Please be considerate when making this request, we are happy to help you and want to see you find a job you want but can’t do this for everyone who contributes.