Taken from "The github.com product development documentation" (source: Ryan Tomayko)

The processes and basic rules for communication on github.com projects are roughly the same as those of an open source project. Mainly, that development and operations follows these constraints where sensible:

Electronic: Discussion, planning, and operations process should use a high fidelity form of electronic communication like email, github.com, or chat with transcripts wherever possible. Avoid meatspace discussion and meetings.

Available: Work should be visible and expose process. Work should have a URL. It should be possible to move backward from a piece of product or a system failure and understand how it came to be that way. Prefer git, issues, pull requests, mailing lists, and chat with transcripts over URL-less mediums.
	[pull request: a developer has cloned a repository, committed changes to the clone, and is making a request that those changes be pulled to the source repository.  The pull request will have a summary of the changes you made, explaining what it is intended to do and how it is implemented.  Generally the project's maintainers will decide whether or not the pull request will be applied, merging the changes into the source repository.]

Asynchronous: Almost no part of the product development process requires that one person interrupt another's immediate attention or that people be in the same place at the same time, or even that people be in different places at the same time. Even small meetings or short phone calls can wreck flow so consider laying it out in (a thought out) email or sending a pull request instead.

Lock free: Avoid synchronization / lock points when designing process. This is DVCS writ large. We don't have a development manager that grants commit bit to repositories before you can do work, or a release manager that approves deploys, or a product manager that approves work on experimental product ideas. Work toward a goal should never be blocked on approval. Push approval/rejection to the review stage or automate it, but surface work early to get feedback.