3 This document documents best practises and guidelines for *collectd*
8 As maintainer of an open-source project, you are one of the most knowledgable
9 people of the project's structure, best practices, goals, etc. You are most
10 helping the project by *facilitating change*, in other words "help contributors
11 make changes to the codebase."
13 The most common form of helping users is doing *code reviews* and (eventually)
14 using your commit rights to merge the pull request.
18 * Be friendly, especially with new contributors. Write "Hi" and thank them for their contribution before diving into review comments.
19 * Criticize code, not people. Ideally, tell the contributor a better way to do what they need.
20 * Clearly mark optional suggestions as such. Best practise, start your comment with *At your option: …*
21 * Wait for a successful run of our [continuous integration system](https://ci.collectd.org/) before merging.
25 You have write access to the *collectd/collectd* repository. Please use it
30 Open *pull requests* for your own changes, too:
32 * For simple changes it's okay to self-approve and merge after a
33 successful build on the CI systems.
34 * Trivial changes, cherry-picks from *master* and roll-up merges are
35 excempt and may be pushed to the version branches and *master* directly.
36 * "Simple" and "trivial" are not further defined; use your best judgement.
37 We'll revisit this if and when it becomes necessary.