I am. Based on the current status of change logs in many open source projects ((absence, poor quality, irregular updates), I believe these conventions can be im

I am. Based on the current status of change logs in many open source projects ((absence, poor quality, irregular updates), I believe these conventions can be improved upon and clarified. At the very least they can be explained better than a two line text file with not a single example. The GNU conventions for change logs and news files are not exactly self-explanatory (semantics matter), which probably explains how rarely they have been followed to the letter. I have no data to back this up, but I doubt people who use and depend on open source software would discard this claim. Now it's interesting to see this initiative mocked as a "not invented here syndrome" (Moru's comment). I did not define these guidelines, I merely gathered them from existing open source projects which were exceptionally good at communicating changes. The poor examples and the frustration that fueled this project came from projects that did the opposite: - inconsistent (file naming, change categories, etc.) - dumping git diffs which provides absolutely no value to end-users (OSS software users who need to regularly update their dependencies) - littered with references to irrelevant issue trackers (which did not provide clarifications regarding the changes) - poorly written with the wrong audience in mind (fellow project collaborators who have context vs. external users who don't) - not given any dates or given confusing regionally-flavored dates - and the crux of my frustration: not singling out and emphasizing API breaking changes and deprecations Anyway, please don't dismiss this project because a convention exist in one community. This convention is not being followed for now and I would really appreciate your help in improving the status quo: https://github.com/olivierlacan/keep-a-changelog/issues https://github.com/olivierlacan/keep-a-changelog/issues Thanks.