X-Git-Url: https://git.octo.it/?a=blobdiff_plain;f=CONTRIBUTING.md;h=e4d683c9e68cb2925901caac3c9c56b348097497;hb=ee771cb0c5df11fad393de41571effb9708f0873;hp=791446a0a7b38af4a1b7a897aed3e4dc184ca7ac;hpb=3fb6fe5776c14f41879249f4147c0b8924b39cc1;p=collectd.git diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 791446a0..e4d683c9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,9 +30,11 @@ the mailing list have a tendency to fall through the cracks. * *Focus:* Fix *one thing* in your PR. The smaller your change, the faster it will be reviewed and merged. -* *Coding style:* Please run `clang-format -style=file -i $FILE` on new files. - For existing files, please blend into surrounding code, i.e. mimic the - coding style of the code around your changes. +* *Coding style:* Please run `clang-format -style=file -i $FILE` after editing + `.c`, `.h` and `.proto` files. If you don't want to install *clang-format* + locally or your version produces a different result than the formatting + check on Github, use `contrib/format.sh` to format files using the same web + service used by our check. * *Documentation:* New config options need to be documented in two places: the manpage (`src/collectd.conf.pod`) and the example config (`src/collectd.conf.in`). New plugins need to be added to the `README` file. @@ -49,6 +51,26 @@ the mailing list have a tendency to fall through the cracks. entries to `src/types.db`, you should talk to us early in the design process. +### ChangeLog + +All PRs need to have a one-line description in the initial pull request body. +This information is used to automatically generate release notes. Follow this +style: + +``` +Foo plugin: A specific issue people had has been fixed. +``` + +Start with "Foo plugin" to give the reader context for the information. Other +common prefixes are "collectd" for the core daemon and "Build system". Use past +tense and passive voice the for remainder, e.g. "a bug has been fixed", "a +feature has been added". + +Some PRs should not be added to the release notes, e.g. changes to project +internal documentation (such as this file). Those changes are not interesting +for external users of the project and would reduce the value of the release +notes. Maintainers may use the `Unlisted Change` label to mark those PRs. + ## Other resources * [Mailing list](http://mailman.verplant.org/listinfo/collectd)