There are many ways you can improve the productivity of your fellow developers.
That could be by sharing what you know or helping out with documenting features
or writing a patch to improve the tools we all use.
## How can you help?
Aside from contributing to the source code for DevTools, all of the following
are different ways you could help contribute:
* **Documentation authoring**
* The [source](https://github.com/GoogleChrome/devtools-docs) for the DevTools documentation is on GitHub and contributions are always welcome. Both reference and tutorial guides benefit from your help.
* Get in touch with [@addyosmani](http://twitter.com/addyosmani) or [@paul_irish](http://twitter.com/paul_irish) for more information on how you can assist here.
* **Share what you've learned**
* Share what you've learned via GIFs, Vines or construction paper
* Cover new experimental features
* Design improved UX for all parts of DevTools
* Triage and manage issues
* Work on features or bugs
* **Coverage of new experimental features**
* Subscribe to [devtools-reviews@chromium.org mailing
<pclass="note"><strong>Note:</strong> You will need to sign and submit a completed <ahref="https://developers.google.com/open-source/cla/individual">CLA (Contributor License Agreement)</a> before we are able to consider any contributions you may wish to make.
</p>
### Step 1: Getting set up
There are a few things you need in order to contribute to DevTools.
**Get the code**<br/>
Download the [Blink](http://www.chromium.org/blink) source code by [cloning the
git repository](https://chromium.googlesource.com/chromium/blink). This process
can take anywhere between 30-60 minutes (depending on your connection).<br/>
Uses a custom front-end URL for remote debugging. The port in the URL should
match the port number used for the running the local web server and the path
should point to the correct location of the inspector.html file assuming that
your web server is running from the Source directory.
*`--no-first-run`<br/>
Skip First Run tasks, whether or not it's actually the First Run.
These flags cause Chrome to allow websocket connections into localhost:9222 and to serve the front-end UI from your local git repo. Here's a [full list of command line switches](http://peter.sh/experiments/chromium-command-line-switches/) and what they do.
Adjust the path to `chromeServerProfile` to be some writable directory in your system. This refers to the `--user-data-dir` flag value mentioned above, which specifies a directory where the browser profile will be stored. You may wish to adjust the actual location of this profile directory to be something other than the `blink` folder.
### Step 3: Inspector inception
Once Canary is open go to any web page (the page doesn't matter because you're
not going to use it for anything). Open up the DevTools for the page, and undock <imgsrc="contributing-files/image03.png"alt="undock DevTools"/> from the window so it is in a separate window.<br/>
Next, open a new tab or launch another instance of Chrome (either Chrome Stable
or Canary) and go to [http://localhost:9222](http://localhost:9222).
Here you will see a grid menu of every page that is currently open which you are
so you can discuss anything you are unsure of or may not know about regarding
the particular ticket you will be working on. You can never over communicate.
### Step 5: Pull, Develop, Branch, Commit
Pull the latest files from the repository and sync to be sure you are working
with the latest code.<br/>
git pull --rebase && gclient sync
Then create a new branch which you can make your changes on.<br/>
git checkout -b yourBugOrFeatureName
Open the DevTools on your DevTools, open your favorite code editor and start
digging through the files in your local repository directory
`/blink/Source/devtools/front_end`.
<pclass="note"><strong>Note:</strong> During development use the Refresh icon or <spanclass="kbd">Alt</a> + <spanclass="kbd">R</span> instead
of <spanclass="kbd">F5</span>, <spanclass="kbd">Ctrl</span> + <spanclass="kbd">R</span> or <spanclass="kbd">Cmd</span> + <spanclass="kbd">R</span> as they are bound to refresh the host page which you
are using to develop the DevTools instance.</p>
Run your change against the Closure Compiler with:
Below are a couple alternative perspectives from some of the contributors who
described their workflows and some tips you might find helpful along the way. If you run into any issues following the steps outlined in this
document above, we've documented these to help you troubleshoot things should
you run into any issues.
### Alternative workflow #1
You get to pick between two workflows: **merge** or **rebase**. Both are
"_mathematically equivalent_" but you use different commands. Unless you are a
git uber-guru, the workflows and thinking for each are different.<br/>
About half of the contributors to Chromium use this **rebase workflow**.
1. git checkout -b myAwesomeBranch
* make a bunch of changes in the branch
3. git commit -am "made some changes in branch"
4. git checkout master
5. gclient sync
6. git checkout my_branch
7. git rebase master
8. Resolve any conflicts
9. If you end up with lots of revisions in your branch, the rebase can be messy as it applies each change in order so you may need to resolve conflicts repeatedly. Git you **squash** a bunch of commits into one with `git rebase -i master`. It pops open an editor with a bunch of `pick XXXX` lines. Change all but the first _pick. _to _squash._ Use `s` to replace the word `pick`.
10. git diff master
* should be the exact patch you're expecting to upload
11. git cl upload
The _merge workflow_ is slightly less work but you end up with merge revisions
in your history. Also, it can be harder to think of it in such that the
code/patch which you are authoring will eventually be something you apply to
2. Create a branch in your local git checkout for that issue. Something like
`[verbose-name]-[issue-number]` (e.g. "drawer-status-bar-231904"). This makes
easier to find in which branch your issue lives and vice-versa. It'd be great
to assign issue to yourself and mark it as "started" so that nobody else
starts doing same job.
3. Code and test in that branch.
4. Commit changes in that branch. You can merge all commits into one. This makes
rebasing later easier if needed.
5.`git cl upload`. The first time you have to fill in the commit description and mention issue number, for example "`BUG=231904`". You will be asked for patch description later on and they all will be attached to the same codereview issue. See "Patch Set #1", "PatchSet #2"... at [https://chromiumcodereview.appspot.com/14329024/](https://chromiumcodereview.appspot.com/14329024/)
6. Add reviewers to the changelist and ask them to review. You should pick reviewers from the OWNERS files. `git cl upload` suggests reviewers.
7. Receive comments from reviewers, argue if needed.
8. If received LGTM from owners - press commit button.
9. Otherwise, fix comments in local checkout in that branch and proceed to step 3.
Sometimes you may need to rebase if the "commit" button fails on codereview
page. Some reviewers don't like rebasing during a codereview since it makes
reviewing harder for them.
While waiting for comments you can switch to another branch and work
on a fix for another issue while this one is "frozen", waiting for review.
### Running Layout tests
To setup a build that can run the layout tests read about [layout tests](http://www.chromium.org/developers/testing/webkit-layout-tests) over on Chromium.org. Depending on the type of patch you are submitting, there may be Chrome DevTools layout tests you will want to run before submission.
First, run `gclient` to use `git`. You can follow the steps located in the Chromium [Using Git guide](https://code.google.com/p/chromium/wiki/UsingGit) to walk you through this process. In summary make sure depot_tools is in your path. Run `fetch blink --nosvn=True` in a directory you wish to store the Chromium source (perhaps get a snack or one of those paddles with a ball on it, this will take some time).
When this has finished you can speed up the build process by building the content shell.
On a Mac or Linux machine you can simply run:
`ninja -C out/Debug content_shell`
If you have problems with this step you can look at [Clang](https://code.google.com/p/chromium/wiki/Clang) for Mac help and the [Linux build instructions](https://code.google.com/p/chromium/wiki/LinuxBuildInstructions) for Linux help.
This will also take some time. Once it has finished providing you with warmth from your laptop then you are
good to run the layout tests which can be run with from your src directory
`webkit/tools/layout_tests/run_webkit_tests.sh`. Replace the .sh with .bat if you
are on Windows. Some failures are expected! (unfortunatly). A good process here
is to run them before you make any changes, then run them after you make your
changes. It can also take an argument to a directory so you can just point it to
