Discuss workflow and rules

[jiri-janousek]

Branches

• Keep the master branch clean and functional, because it's the stable/production/release branch.
• Use feature/topic/devel branches when necessary. You can experiment and break things in these branches, but they must be stable and functional when they are about to be merged back to master.
• Create a Github pull request if you would like to have a code review.

  Merge

• Don't use Github to do a merge.
• Use git merge --ff-only to merge branches with a single commit (rebase on master if necessary).
• Use git merge --no-ff --no-commit to merge branches with more then one commit, then commit the merge with a very descriptive commit message (no bare commit messages like Merged branch foo).

  Release

• Create a Github issue "Make release X.Y" and assing it to @fenryxo when ready for a new release, but don't increase version fields in metadata.
• Don't hesitate to release often. Packages of service integration script are lightweight with a typical build time a few seconds thanks to fpm.
• Users will love you if you release a fix as soon as possible.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[jiri-janousek]

@jnv, I've drafted some rules for this repository. Do you have any feedback or objections to them?

[jnv]

Seems alright, maybe just the Don't use Github to do a merge. point could use some clarification; I assume the reason is an unnecessary noise generated by merge commits in the history.

I think these rules should go to the CONTRIBUTING.md file, possibly under a separate section for maintainers.