You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2020/11/26 14:09:24 UTC
Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc
comments (#66)
Please update changes.xml when you merge a PR.
Gary
On Thu, Nov 26, 2020 at 9:08 AM Alex Herbert <no...@github.com>
wrote:
> Merged #66 <https://github.com/apache/commons-codec/pull/66> into master.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/commons-codec/pull/66#event-4042698893>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAJB6N5JRAPLAWQW3MJNWMLSRZOM3ANCNFSM4UC5LMUQ>
> .
>
Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc
comments (#66)
Posted by Gilles Sadowski <gi...@gmail.com>.
> > > > > [...]
> > > > > 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc
comments (#66)
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Nov 26, 2020 at 10:46 AM Gilles Sadowski <gi...@gmail.com>
wrote:
> Le jeu. 26 nov. 2020 à 16:04, Gary Gregory <ga...@gmail.com> a
> écrit :
> >
> > On Thu, Nov 26, 2020 at 10:00 AM Gilles Sadowski <gi...@gmail.com>
> > wrote:
> >
> > > Gary,
> > >
> > > Le jeu. 26 nov. 2020 à 15:47, Gary Gregory <ga...@gmail.com> a
> > > écrit :
> > > >
> > > > On Thu, Nov 26, 2020 at 9:43 AM Gilles Sadowski <
> gilleseran@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello Gary.
> > > > >
> > > > > Le jeu. 26 nov. 2020 à 15:09, Gary Gregory <ga...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc
comments (#66)
Posted by Gilles Sadowski <gi...@gmail.com>.
Le jeu. 26 nov. 2020 à 16:04, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Thu, Nov 26, 2020 at 10:00 AM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > Gary,
> >
> > Le jeu. 26 nov. 2020 à 15:47, Gary Gregory <ga...@gmail.com> a
> > écrit :
> > >
> > > On Thu, Nov 26, 2020 at 9:43 AM Gilles Sadowski <gi...@gmail.com>
> > > wrote:
> > >
> > > > Hello Gary.
> > > >
> > > > Le jeu. 26 nov. 2020 à 15:09, Gary Gregory <ga...@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.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc
comments (#66)
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Nov 26, 2020 at 10:00 AM Gilles Sadowski <gi...@gmail.com>
wrote:
> Gary,
>
> Le jeu. 26 nov. 2020 à 15:47, Gary Gregory <ga...@gmail.com> a
> écrit :
> >
> > On Thu, Nov 26, 2020 at 9:43 AM Gilles Sadowski <gi...@gmail.com>
> > wrote:
> >
> > > Hello Gary.
> > >
> > > Le jeu. 26 nov. 2020 à 15:09, Gary Gregory <ga...@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.
Gary
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc
comments (#66)
Posted by Gilles Sadowski <gi...@gmail.com>.
Gary,
Le jeu. 26 nov. 2020 à 15:47, Gary Gregory <ga...@gmail.com> a écrit :
>
> On Thu, Nov 26, 2020 at 9:43 AM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
> > Hello Gary.
> >
> > Le jeu. 26 nov. 2020 à 15:09, Gary Gregory <ga...@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.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc
comments (#66)
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Nov 26, 2020 at 9:43 AM Gilles Sadowski <gi...@gmail.com>
wrote:
> Hello Gary.
>
> Le jeu. 26 nov. 2020 à 15:09, Gary Gregory <ga...@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.
Gary
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [apache/commons-codec] (doc) Remove duplicate "from"s in javadoc
comments (#66)
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello Gary.
Le jeu. 26 nov. 2020 à 15:09, Gary Gregory <ga...@gmail.com> a écrit :
>
> Please update changes.xml when you merge a PR.
Since when do we require that for Javadoc clean-up?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org