> > > > > [...] > > > > > 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.
YMMV: It does provide exposure if the PR was merged (cf. some GH chart, at least last time I checked...). > 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. False attribution: It is not neglected (change was performed). [Alex is particularly careful about "aesthetics". And so am I.] > 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. False attribution: We value contributions (Alex posted an explicit appreciation on GH). Contributing to an free project is not a popularity contest: If looking for "visibility" is the primary goal, that's not a good start (IMO). > You, of course, are free to leave such contributions uncredited. Could you please not propagate this kind of falsity? If you are not happy with the contents of "changes.xml", you are of course welcome to fix it. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
