For me and many users the Release Note like this are very hard to read and hard to find what is needed. Many times they go to google because it's easier to search than walking through all versions of release notes.
We do not have a cumulative documentation with a list of features and we often point to release notes whenever any uaser is asking about feature or for a problem that he has in his build. If it was only up to me, I would have the cumulative documentation(s) which is in one folder, and another documents would be Jira Report generated by "reporting" and this would include the author in the table - easy and automated. IMO it should be just like in the plugins - every feature fully documented in src/site/../*.apt and pushed with the code and tests to master in one commit. Then the Release Notes would be a matter of command line "mvn site ...". On Sat, Aug 31, 2019 at 10:45 AM Robert Scholte <rfscho...@apache.org> wrote: > The goal of release notes is that they are being read. > There should be a good balance of the amount of information, preventing > people to say TLDR; > > A long list of 'MNG-NNNN John Doe' doesn't provide me useful information. > The list of 'MNG-NNNN A good JIRA title' is useful and visiting the > related Jira page will provide you the extra information, including the > actual reporter and contributors. > > Summing up a list of names that helped on the release is a good way to > appreciate their help on this release. > > Robert > > > On Sat, 31 Aug 2019 08:33:15 +0200, Tibor Digana <tibordig...@apache.org> > > wrote: > > > We should use authors of the issue/PR/idea. > > After the release we can ask WHY (practical goals) he wanted the feature > > more than how. The question for "HOW" has to be placed very early during > > the review, but too late after the PR has been merged. > > I expect that the reviewer developer has checked all the code, so there > > would not be questions about *how* it is done. If the reviewer does not > > understand the code and he admits the change, then it is question for him > > whenever a new trouble happens. > > So this is my opinion - listing the author(s) of the idea in every > > issue/PR. > > > > On Fri, Aug 30, 2019 at 10:40 PM Robert Scholte <rfscho...@apache.org> > > wrote: > > > >> Not sure if the reader of the release notes is helped with a long list > >> of > >> reporters and contributers per issue. > >> I would expect that only a list of (unique) names is good enough. > >> > >> If there is someone that deserves extra credits, I'd say it is Stefan > >> Oehme for diving into the code, looking for memory leaks AND providing > >> patches to solve it. > >> > >> thanks for pushing this release! > >> Robert > >> > >> On Fri, 30 Aug 2019 22:02:31 +0200, Enrico Olivelli > >> <eolive...@gmail.com> > >> > >> wrote: > >> > >> > Hi all, > >> > I have sent a draft of the release notes for 3.6.2 > >> > > >> > this is the PR > >> > https://github.com/apache/maven-site/pull/99/files > >> > > >> > Feel free to add comments or push fixes directly to the branch. > >> > > >> > It still lacks a bit of formatting, but the content is ready > >> > > >> > Cheers > >> > Enrico > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
