Thanks everyone for the valuable feedback!
I think we have consensus to drop contributor and reviewers name from the
commit message. As of now we can start applying the new style. I can also
try to find a place on the website to mention the new style.
Just to avoid any confusion, I am not suggesting to remove reviewers name
from the commit log because I don't find them important. I guess I am
repeating myself but doing reviews is crucial for the project and a must
have element for inviting someone to become a commmitter. Even though we're
removing the names from the log the PMC will actively monitor review
activity directly by looking into GitHub PRs and JIRA tickets.
Posting a thankful note to contributors and reviewers is a nice gesture and
appreciation for their time. Indeed doing it through JIRA is tricky
sometimes so I really like the proposal to leave the comment directly under
the PR.
Best,
Stamatis
On Fri, Apr 11, 2025, 3:24 AM Butao Zhang <zhangbu...@apache.org> wrote:
> IMO, It is enough to mention&thank the contributor & reviewers in the
> Github page.
> For the Jira page, it's sufficient to express gratitude to the author
> only. There is no need to mention the reviewer. Because it can be rather
> troublesome to look up the Jira account of the reviewer sometimes & and we
> have already mention reviewers in the Github page.
>
> -Butao
>
> On 2025/04/10 11:00:29 Okumin wrote:
> > +1
> >
> > I also confirmed that we have followed the practice since at least
> > 2015 before we moved to GitHub, so it is likely to have purposes other
> > than incentives. Also, no one, including me, has proven it could be a
> > strong incentive. I second the idea of improving the current real
> > process.
> >
> > Regarding Butao's question, I think we don't need it simply because
> > resolving a JIRA account and the reviewer's name is a difficult or
> > sometimes impossible step in this problem. If we accept the proposal,
> > I feel we also need to remove the step. We may thank them in GitHub,
> > or it is up to the committer who merged it. I don't have a preference
> > for it.
> >
> > Regards,
> > Okumin
> >
> > On Wed, Apr 9, 2025 at 6:59 PM Butao Zhang <zhangbu...@apache.org>
> wrote:
> > >
> > > +1
> > > BTW, Should we also ignore mentioning the contributors and reviewers
> in the corresponding JIRA? And then directly just closed the JIRA?
> > >
> > > -Butao
> > >
> > > On 2025/04/08 16:22:33 Ayush Saxena wrote:
> > > > I feel that for some folks—especially those new to the project—seeing
> > > > their name in the commit message might serve as a small motivation to
> > > > review more. The practice of including the author name I believe has
> > > > been around since the SVN days or the patch days, or even earlier,
> > > > when committers used to apply patches manually. Back then, unless the
> > > > committer explicitly added the author, the commit would default to
> the
> > > > committer’s name, and figuring out the actual author email from JIRA
> > > > wasn’t always straightforward.
> > > >
> > > > If the consensus is to not include reviewer names in commit messages,
> > > > that’s totally fine with me—it’s one less thing to worry about.
> > > > Personally, I don’t have a strong opinion here. Even if my name
> > > > doesn’t appear as the author or reviewer for a change I was involved
> > > > in, it doesn't really matter to me anymore. I think many folks who’ve
> > > > been in the ecosystem for a while probably feel the same.
> > > >
> > > > That said, I can’t really recall if seeing my name early on gave me a
> > > > sense of validation—but maybe it did. And if it helps newer
> > > > contributors, especially those who aren’t yet recognized committers,
> > > > feel a bit more involved or valued, then I’m okay putting in that
> > > > extra bit of effort if it makes someone’s day.
> > > >
> > > > That said, tracking down real names from GitHub handles can sometimes
> > > > be a bit of a pain and a time sink for committers. So, if the group
> > > > prefers to skip reviewer names, I’m perfectly fine with that too.
> Most
> > > > of the projects I know don't do that or ever did it. Just to
> > > > reiterate—it doesn’t matter much to me personally, but I’m happy to
> go
> > > > with whatever the group finds more useful, especially the non
> > > > committers.
> > > >
> > > > As for the author field—GitHub already shows the author name, so it
> > > > does feel a bit redundant to include it explicitly, so dropping that
> > > > is totally f9
> > > >
> > > > +1
> > > >
> > > > -Ayush
> > > >
> > > > On Tue, 8 Apr 2025 at 21:15, Shohei Okumiya <oku...@apache.org>
> wrote:
> > > > >
> > > > > +1 for the author part.
> > > > >
> > > > > Regarding the reviewers' names, I have one thouht from a bit
> diffrent angle. The number of reviewers is always the biggest bottleneck.
> If the small praize motivates people and they try one more review, it is
> meaningful. But I don't have any evidence about how many people feel so.
> So, I'm not stick with it. By the way, I am fairly happy to see my name in
> the commit history.
> > > > >
> > > > > In short, I agree to remove the author's name. I can still add
> reviewers' GitHub user names(identifying real names is often tough) if we
> believe it could motivate a meaningful number of people.
> > > > >
> > > > > Thanks,
> > > > > Okumin
> > > > >
> > > > > On Tue, Apr 8, 2025 at 23:35 Zsolt Miskolczi <
> zsolt.miskol...@gmail.com> wrote:
> > > > >>
> > > > >> +1.
> > > > >>
> > > > >> I don't see the value in that.
> > > > >>
> > > > >> Attila Turoczy <aturo...@cloudera.com.invalid> ezt írta
> (időpont: 2025. ápr. 8., K, 16:32):
> > > > >>>
> > > > >>> +1.It's a thoughtful gesture for reviewers, but if it creates
> headaches for the dev's and adds unnecessary steps, I think we can live
> without it.
> > > > >>>
> > > > >>> -Attila
> > > > >>>
> > > > >>> On Tue, Apr 8, 2025 at 4:27 PM Stamatis Zampetakis <
> zabe...@gmail.com> wrote:
> > > > >>>>
> > > > >>>> Hi all,
> > > > >>>>
> > > > >>>> How do you feel about dropping the contributor and reviewer
> names from
> > > > >>>> the commit summary?
> > > > >>>>
> > > > >>>> Before:
> > > > >>>> HIVE-28884: Decouple source.q test from SRC dataset (Stamatis
> > > > >>>> Zampetakis reviewed by Soumyakanti Das, Zsolt Miskolczi, Shohei
> > > > >>>> Okumiya, Simhadri Govindappa)
> > > > >>>>
> > > > >>>> After:
> > > > >>>> HIVE-28884: Decouple source.q test from SRC dataset
> > > > >>>>
> > > > >>>> The main goal is to increase developers productivity and reduce
> > > > >>>> boilerplate information.
> > > > >>>>
> > > > >>>> In many cases the extra information is longer than the commit
> summary
> > > > >>>> itself. Every time I merge a PR I have to spend 2-3 minutes
> editing
> > > > >>>> the commit message and figuring out the names of every person
> that is
> > > > >>>> involved in the PR.
> > > > >>>>
> > > > >>>> Moreover, the "Author" information is already present in the
> commit
> > > > >>>> metadata and the reviewers are clearly shown and tracked under
> the
> > > > >>>> respective PR in GitHub so removing them from the commit
> summary does
> > > > >>>> not result in loss of information.
> > > > >>>>
> > > > >>>> The PR id is always present in the commit message (either in the
> > > > >>>> summary or in the body) so we can easily fetch all the necessary
> > > > >>>> information (even more and more structured) about contributors
> and
> > > > >>>> reviewers of certain PR via the GitHub UI or programmatically
> via REST
> > > > >>>> or GraphQL.
> > > > >>>>
> > > > >>>> For instance the following GitHub GraphQL query can be used to
> obtain
> > > > >>>> the name of the author of the PR and the names of the reviewers
> that
> > > > >>>> approved the PR.
> > > > >>>>
> > > > >>>> {
> > > > >>>> repository(owner: "apache", name: "hive") {
> > > > >>>> pullRequest(number: 5750) {
> > > > >>>> title
> > > > >>>> author {
> > > > >>>> ... on User {
> > > > >>>> name
> > > > >>>> }
> > > > >>>> }
> > > > >>>> reviews(first: 100, states: APPROVED) {
> > > > >>>> nodes {
> > > > >>>> author {
> > > > >>>> ... on User {
> > > > >>>> name
> > > > >>>> }
> > > > >>>> }
> > > > >>>> }
> > > > >>>> }
> > > > >>>> }
> > > > >>>> }
> > > > >>>> }
> > > > >>>>
> > > > >>>> Best,
> > > > >>>> Stamatis
> > > >
> >
>
