These should be avoided because they undermine the process of
peer review and merging in github, we should strive to have
zero open pull requests, as opposed to treating it as a stage
for work in progress. Intermediary code review can happen in github forks instead.
Also remove some checklist items which were based on the Trac bugtracker,
e.g. its not longer possible to assign yourself to issues because
of github's limited permission abilities.
The current guides have a few areas where they recommend an approach that is more complex than what most people take.
- Rebase straight onto upsteam/msaster
- Force push a rebased branch
I also fixed the conflict resolution help to be relevant to rebase commands, and kept the push instruction out of the rebase instruction.
I don't know what that release candidate branch stuff is, but:
* I've never seen any of the core team do it
* I think it's overkill for most patches
* I think it's being too prescriptive: if contributors want to do that, that's cool, but it doesn't affect the core team.
* It makes our contributing guidelines more complex than they need to be.
The guidelines for contributing code were scattered across a section of contributing.md and collaboration-on-git.md. I've updated this to have separate contributing/code.md page with all the content in a single cohesive page. We also have contributing/documentation.md, contributing/issues.md and contributing/translation.md.
