Proposal: Issue Milestones, Labels, Styleguide, Contributing, Changelog

[dnsmichi]

Your module is becoming quite popular, and since I've started to add my PRs too, I just wanted to suggest certain organizational things:

Milestones

• use milestones as target versions for resolved issues and PRs (https://github.com/Mikesch-mp/icingaweb2-module-grafana/milestones)
• use these milestones to tag/create releases

Labels

• Assign enhancement/bug labels to newly created issues (you as the owner can do it, but no-one else)
• Add more labels and coloring (e.g. Grafana, Graphite, InfluxDB, Configuration, Documentation) to selectively view and organize issues.

Styleguide

I'd suggest to apply the same code style guide as known from Icinga Web 2. Such a thing could be implemented into travis-ci tests which are checked on each PR too.

Contributing

Add a CONTRIBUTING.md file which explains contributions and PRs. We've recently started to apply this to Icinga 2, might be worthwhile to do the same (this also involves uses milestones for the roadmap).
https://github.com/Icinga/icinga2/blob/master/CONTRIBUTING.md

Changelog

Once you've settled issues with milestones, you can automatically generate a CHANGELOG.md file from that. Follow these instructions: https://github.com/Icinga/puppet-icinga2/blob/master/RELEASE.md#2-changelog

[Mikesch-mp]

Your right i should do that all. Think i will take a GIT training at Netways.

[dnsmichi]

I can also help you with that, but I don't want to push it too much :)

Start with a simple step - add versions for the past releases and assign closed issues to them. Then add a new milestone for the recent merges, and cut of a release once all issues are closed :) That will help others to see what exactly you've changed, instead of reading git commits :)

[dnsmichi]

#72 #73 #74 are single commits based off the master branch. There's no order required for merging.

This leaves the TODOs to

• Labels
• Styleguide & Tests
• Changelog