TODO: Write this thing into an actual document

Thanks for taking the time to contribute :)

The project currently enforces these rules:

• Commit rule:

  • The commit message is as important as the content of the commit. It should be written in the following format:

  <component>(<subcomponent>): <summary>
  
  <detailed description of the change>
  

  For <component>, use the Nim import path syntax, eg. sys/exec, sys/pipes or sys/[exec, pipes] for changes to both at the same time. Changes affecting the entire project should use sys(treewide).
  <subcomponent> usually denotes the specific implementation of a module, for example: sys/exec(posix) for changes to the POSIX implementation, sys/pipes(windows) for changes to the Windows implementation. Changes affecting all implementations don't require this part.
  <summary> should provide a short description of what is changed and/or what is the effect of the commit.
  The first line should not exceed 72 characters, and must not exceed 80 characters.

  The detailed description should explain at least the rationale behind the change, and the change itself in details. The rationale is always required unless covered by the summary, but the details can be omitted if it's trivial or is covered by documentation within the implementation (ie. changing one line due to a typo). Detailed descriptions should be hard wrapped to 72 characters.

  All commits staged for merging must follow this rule. No exceptions.

  Some examples: 827afaf, a51a859, 6649f5c, 77a199d

  • Keep commit small if possible, and they need not to compile/pass tests perfectly, though it is preferred that they do.

  • Feel free to adjust the commit history within your own branch as needed (eg. you used temporary commits and now you want to squash them into one commit, or if you want to rebase your work on top of the current master). However, never change the history if collaboration is being done in the branch.

• PR rules:

  • Any feature addition/fixes to be merged to master must be accompanied by tests in the same PR.
  • Any introduced API, private or public, must be documented.
  • Focus on one thing at a time. If the PR bring in changes unrelated to the title, it will be discarded.
  • PRs are reviewed on a per-commit basis.

• Merge rules for maintainers:

  • Use merge commits, and the merge commit should describe the work being merged. It is fine to just use a PR title then refer to them.
  • Never alter the history of an another user unless explicit permission was given.
  • All commits must be signed.

I'm a bit stingy regarding commits, but these strict requirements will help collaboration and people who read the code a lot, trust me :)