-
Notifications
You must be signed in to change notification settings - Fork 4
Contributing to RapidFTR
Mingle – Requirements repository
Non-core committers interested in contributing can assign themselves an available defect or story, and announce what they’re working on to the RapidFTR Google Group. Also, everyone is free to browse the full set of stories and defects for RapidFTR on our Mingle instance (Guest username/password: rapidftr/rapidftr)
Github Repo
They should fork the repo (RapidFTR Web App Repo, RapidFTR Android Repo, and push their work to their own Github repo. It would be best for them to put this work on a well-named feature branch so it’s easier for others to find their work.
Contributions should be covered by Cucumber features and/or Rspec examples, as appropriate. They should have the latest master of the main repo merged in. If contributors want to squash their local commits before pushing to Github and/or rebase on the latest from the main repo, that makes for a nice simple history, but it’s not necessary. We do ask that all commits have clear messages, ideally indicating what story or issues they’re related to. When a contribution is ready, contributors should issue a Pull Request on GitHub (and maybe send a message to the mailing list) to have it reviewed by core committers. They may suggest further changes or merge it into the main repo.
Obviously things can be done in person at a code jam or similar group event, but it would still be best to have the tracking tools (rapidftr.com/userstories and Mingle) reflect what’s in progress so as to avoid two people working on the same thing.
New functionality from a core contributor (someone with commit rights to the main repo) should be pushed to the main repo in a feature branch. To get the new functionality into the master branch a second core contributor should review the changes and then merge them into master. The author of the changes shouldn’t be the one merging them into trunk, this should be done by a code reviewer. This isn’t a hard-and-fast rule, and we can break it if we want. The intent is to encourage code review of changes before they land on master, or the explicit recognition that a change doesn’t warrant review. If the implementation was done by a pair, then getting an additional code review isn’t required, and either of the pair can merge from the feature branch to master.
Here’s a proposed set of “Rules of the Road” for contributing to RapidFTR:
- Contributions need to include good test coverage. If you need help with that reach out to a member of the rapidftr team. See https://github.com/rapidftr/RapidFTR/wiki/Testing-Strategy.
- Make your proposed change on a fork of the canonical rapidftr/RapidFTR repo, which can be found here: http://github.com/rapidftr/RapidFTR
- It’s easiest to make your change on a feature branch within your repo, and keep the master branch of your repo in sync with the upstream repo. Check out the “Pulling in upstream changes” section of the github help page about forking: http://help.github.com/forking/
- Use github’s pull request mechanism to submit the changes on your task branch for inclusion in the main project.
- Before submitting a pull request, make sure that your master branch is in sync with the upstream repo, and then rebase your task branch against your master branch. This makes it a lot easier to accept your patch into the main project (it will be a straight fast-forward merge, rather than a 2 way merge).
Essentially this is the same basic guidance which the rails project uses – https://rails.lighthouseapp.com/projects/8994/sending-patches – except for accepting github pull requests rather than direct patch submissions.