Any suggestion ? I am leaning towards creating a single list of "Contributors" and a list of "Reporters"
I have to close the VOTE, I will wait to reach consensus on this release notes stuff before closing the vote. Enrico Il giorno sab 31 ago 2019 alle ore 17:18 Tibor Digana < tibordig...@apache.org> ha scritto: > We have contributors listed directly in the POM > https://github.com/apache/maven/blob/master/pom.xml#L120 > If we started with this great idea to list contributors in POM, we should > continue with it and this is the same privilege for future contributurs as > well. They will be listed on the Maven sites which is a big Thx from us > ASF/Maven for them. > Enrico, you have hard time because you are doing it only by your hands. Why > not to ask the contributor to add himself to the POM while the pull-request > is open? This would simplify your work with the release and then the > release notes is more simple to do. > > For instance in the JUnit4 group the author and contributor is writing the > release notes on Wiki. It is part of the normal work, otherwise it is > incomplete. > I was also asked by the comitter to describe the fix/feature on Wiki in > JUnit4. But there must be writtent rules and culture in the team to remind > the contributor to write the release notes. > You as committer cannot compete with a large number of contributors! > The contributors must understand that the work is not only about Java code, > it is also documentation of whatever manner. > > Also we should ask a contributor whether he wants to be in the list, but we > cannot ignore the contributor in the list. > And what is the next fact, the list of contributors exists for some time. > We should continue in this tradition and we should pickup a new commiter > from this list. It is simple because we can see that some contributors are > more active than the others and we can see it based on the the number of > issues MNG-xxxxx. We will very hardly "decompile" the release notes and > find such statistics. We can do it only in JIRA. > But still "reporter" is important because without him the idea would not > exist and this is important for users, I mean the idea, but contributor > will be always in the development team or in the users which is the matter > of time when somebody writes the code. Contributors are important for > development and us in ASF but the reporter is relevant for users because he > is the architect of "business idea" - of course it is not the same as in > the enterprise. In the enterprise, the customer does not care who is > contributor ala developer, he cares about the work done for him. > > On Sat, Aug 31, 2019 at 1:05 PM Enrico Olivelli <eolive...@gmail.com> > wrote: > > > In my opinion release notes should tell: > > - new features/news and noteworthy > > - user visible changes > > - breaking changes > > > > I would add a list of contributors. > > The list of 'reporters' is not useful. > > > > I see we are doing those lists in order to have a better engagement with > > the community, but I am not sure at 100% it is something that should stay > > forever on the website, maybe it can be in the announcement email. > > > > I have used the release notes of 3.6.1 as template, to me it is not a > > problem to shrink the list making some sort of select > > 'distict(reportername)', distinct(contributor name). > > > > Enrico > > > > Il sab 31 ago 2019, 11:17 Tibor Digana <tibordig...@apache.org> ha > > scritto: > > > > > 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 > > > > > > > > > > > > > >
