(see also [wiki:PatchReviewProcess How To Review Patches])

Please create a new ticket to track the issue unless your patch addresses an issue that is already ticketed. If you're not sure whether there is a ticket for your issue, just make a new one. Someone will point you in the right direction if your ticket is a duplicate.

We use git as our version control system and the tahoe source code is hosted on [https://github.com/tahoe-lafs/tahoe-lafs Github]. Github requires that you have a Github account in order to submit patches, so you will have to create one if you don't already have one. If you are unfamiliar with Github or git we recommend the following resources: 
* [https://help.github.com/articles/set-up-git Github - Set up git]
* [https://help.github.com/articles/fork-a-repo Github - Fork a repo]
* [http://git-scm.com/book git-scm.com/book - A great overall git resource]

Once you have finished installing git and creating your Github account, fork the offical Tahoe-LAFS repo [https://github.com/tahoe-lafs/tahoe-lafs here]. You can also star or watch the official repo to make us feel fuzzy inside.

Download the source code from your new fork. This can be done by typing `git clone https://github.com/<YOUR USERNAME>/tahoe-lafs.git` into terminal.

Navigate to the `tahoe-lafs` folder and type `git branch` to make sure `master` is selected. Then create a new branch with `git checkout -b <your branch name>`. Your branch name should have the ticket number and a small description of what the ticket is addressing. For example, the branch name for [https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3003 ticket #3003 - Set up a GitHub contributor guide] was `3003.contributor-guide`.

Now, hack at Tahoe-LAFS!

We encourage you to use test-driven development [https://tahoe-lafs.org/trac/tahoe-lafs/wiki/HowToWriteTests and write your own tests] when hacking on Tahoe-LAFS.  This method can help you create better factored, better tested, less buggy code.

Once you think you have solved the issue run the test suite with `tox`. This ensures that you didn't accidentally break something while working on your patch and will run your new tests, too.

You can also use `tox -e codechecks` and `tox -e typechecks` to check for other kinds of errors.

Finally, push your branch to Github and [https://help.github.com/articles/creating-a-pull-request open a pull request]. Use the [https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review GitHub "request review"] feature to let the team know your PR is ready for a code review.  You should usually request a review from "tahoe-committers" but you can request a review from a specific developer instead if you have good reason to want their review specifically.  If you had trouble with any part of your patch -- don't worry!  Submit the pull request for review anyway and leave a comment describing the area you'd like help with.

= Design reviews =

To request a design review, just explain your design (with or without a patch) and ask for feedback. Completion of a design review will normally not directly result in a patch being committed. The main goal of a design review is to give the person working on the ticket confidence that there are no show-stopping issues with the approach they are taking, and to get feedback on smaller issues that are useful to take into account before doing further work on a patch.