Consider adding Commitizen

[hassankhan]

Consider using Commitizen for commit messages. This allows predictable, well-formatted commit messages that can then be used to easily generate changelogs.

Commitizen can also be combined with semantic-release to allow automating most of the release process (including publishing to NPM).

By doing this, we can remove a lot of the friction in publishing to NPM/generating releases by making them part of the build process (using Travis)

[HyperBrain]

I don't really feel good, putting chains onto contributors already add the commit phase. Travis and Coveralls will already prohibit merging anything in there that does break.
I am sure that with a good PR review process the solutions that are submitted fit into the system and are compliant to commonly agreed standards.

Also automating the NPM release process is critical. A manual release just consists of setting a new version in master, adding the change log to the README and setting the tag. Normally the README only contains an abstracted changelog, because the users of the plugin do not care about implementation internals - they only want to know if an issue has been fixed. If you want to know how, you can check it on GitHub.

I'm hesitant to let anything that finds it's way to master be automatically released.

[arabold]

I agree with @HyperBrain here. There hasn't been an update to this project in half a year and first concern should be to get it back on track and some users actually submitting PRs again. Everything that poses a hurdle in doing so might actually hurt us more than being beneficial.

[HyperBrain]

I'll close this for now. It is not necessary at least while getting the project to speed again.