On Thu, Nov 26, 2020 at 10:46 AM Gilles Sadowski <gillese...@gmail.com> wrote:
> Le jeu. 26 nov. 2020 à 16:04, Gary Gregory <garydgreg...@gmail.com> a > écrit : > > > > On Thu, Nov 26, 2020 at 10:00 AM Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > Gary, > > > > > > Le jeu. 26 nov. 2020 à 15:47, Gary Gregory <garydgreg...@gmail.com> a > > > écrit : > > > > > > > > On Thu, Nov 26, 2020 at 9:43 AM Gilles Sadowski < > gillese...@gmail.com> > > > > wrote: > > > > > > > > > Hello Gary. > > > > > > > > > > Le jeu. 26 nov. 2020 à 15:09, Gary Gregory <garydgreg...@gmail.com> > a > > > > > écrit : > > > > > > > > > > > > Please update changes.xml when you merge a PR. > > > > > > > > > > Since when do we require that for Javadoc clean-up? > > > > > > > > > > > > > It's more about providing *transparency* and *documenting* the fact > that > > > > this change came from a PR. If the change came from a Jira issue, > we'd > > > have > > > > an entry to show the Jira issue ID. > > > > > > > > This is an open-source project and to me that means being open *and* > > > > transparent. > > > > > > I agree, but that's beside my point: You require undue work from a > > > committer. People who want/need to engage in history tracking will > > > need to turn to the version control system anyways. The PR number > > > alone does not mean anything and is just noise in that report. > > > > > > > A one liner in a text file is "undue work"? Yikes. > > For such a change, yes. > Worse than that: IMO, "nit-pick" changes should *not* be > listed in "changes.xml", lest we end up with an illegible > report where important modifications are drowned within a > useless enumeration of spelling corrections. > It seems to me that you're losing sight of the openness and transparency aspect of an open source project: If someone is going to take the time and effort to fix small issues like typos or spelling mistakes, this should be documented and credited in the project files and site. I do not consider git history to provide this level of exposure. This type of polish should not be neglected; documentation and presentation of a project is important as it offers a glimpse as to the kind of attention to detail a project provides. This kind of change can also be a way for new contributors to get started participating in a project and documenting these changes is part of a community welcoming these contributions by actually showing, through our documenting them in changes.xml, that we value contributions. You, of course, are free to leave such contributions uncredited. Gary > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
