Giving credit for contributions through Github Pull Requests

["Thiruvalluvan M. G" <th...@apache.org>]

Hi all,

Officially, we say that we track issues using Jira: https://avro.apache.org/
issue_tracking.html and suggest contributors to manage issues on Jira. But
we receive several pull requests on github with or without corresponding
Jira tickets. What is the best way to handle them? How do other Apache
projects handle these?

I see two levels of problems:

1. When we have a Jira ticket for an issue, we sometimes see contribution
come from someone who does not have an account on Jira. Whom do we assign
the Jira ticket to? We have a few options, none of them pretty:

a. Insist that the contributor creates and account in our Jira and assign
the ticket to themselves. This could leave the fixes unnecessarily blocked
for long time.
b. Leave the ticket unassigned. This is sloppy book-keeping.
c. Assign to the person who created the ticket. This is wrong attribution.
Will cause trouble in evaluating contributors for committership.
d. Assign to the person who merges the pull request. This is also wrong
attribution, but will encourage existing committers to consider and merge
fixes expediously.

My personal preference is the combination of (a) and (d). We should
encourage the contributor to assign the Jira to themselves. If they don't
do it in reasonable time (1 week?) let's assign to the person committing
it. But if the contributor comes back later with their Jira id, we should
reassign the ticket to them.

2. Pull requests are raised without a corresponding Jira ticket. Here one
of us can create a new Jira ticket. When we do this, the situation is the
same as the previous one.

A related question: When we merge the pull request it typically does not
update CHANGES.txt. How and when do we update this file?

Any suggestions?

Thank you,

Thiru

Re: Giving credit for contributions through Github Pull Requests

[Sean Busbey <bu...@cloudera.com>]

On Thu, May 3, 2018 at 4:18 PM, Doug Cutting <cu...@gmail.com> wrote:

> Maybe we should loosen the permissions on Avro's Jira so that any user can
> assign an issue?  That would make things a bit simpler.  I doubt we'd see
> much if any abuse.
>

locking down issue assigning happened ASF jira wide due to spammer abuse.
we could probably due with better documenting how folks gain the ability to
assign themselves issues.

I presume it's "email dev@avro and ask for the ability". At the very least
I've been granting it to anyone who asks.



>
> Also, it's probably time to remove CHANGES.txt and just use Jira to
> generate release notes.  Agreed?
>
>
Yeah that'd be great.  The Apache Yetus project makes a tool called Release
Doc Maker that will generate markdown for us.

http://yetus.apache.org/documentation/0.7.0/releasedocmaker/

It's  been working for the Hadoop project for ages. HBase has started
moving to it and it's gone well.

-- 
busbey

Re: Giving credit for contributions through Github Pull Requests

[Gabor Szadovszky <ga...@apache.org>]

+1 for both

On Fri, May 4, 2018 at 9:54 AM, Nandor Kollar <nk...@cloudera.com> wrote:

> +1 for both, especially for removing CHANGES.txt.
>
> On Thu, May 3, 2018 at 11:18 PM, Doug Cutting <cu...@gmail.com> wrote:
>
> > Maybe we should loosen the permissions on Avro's Jira so that any user
> can
> > assign an issue?  That would make things a bit simpler.  I doubt we'd see
> > much if any abuse.
> >
> > Also, it's probably time to remove CHANGES.txt and just use Jira to
> > generate release notes.  Agreed?
> >
> > Doug
> >
> > On Thu, Apr 26, 2018 at 11:51 AM Sean Busbey <bu...@cloudera.com>
> wrote:
> >
> > > On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting <cu...@gmail.com>
> wrote:
> > >
> > > > So I guess this would be easier if we also said that contributions
> > would
> > > > only now be accepted via pull request.  Is that too onerous?  Instead
> > of
> > > > requiring everyone to have an Apache Jira account we require them to
> > > have a
> > > > GitHub account.
> > > >
> > > >
> > > I take it the github contributor summary doesn't work for emails that
> > > aren't associated with a github id?
> > >
> > > What about jumping on the Apache Kibble train? They're trying to make
> > > similar "project observability" widgets as what github provides.
> > >
> > >
> > >
> > > > Moving issue tracking to GitHub seems unlikely, as it's lacking a lot
> > of
> > > > features we depend on from Jira.
> > > >
> > > >
> > > I don't like the idea of moving from JIRA to GitHub issues, but I think
> > GHI
> > > has all the features we'd need to do so, FYI. Or atleast, I can't think
> > of
> > > any we use that don't have a mapping to something.
> > >
> > >
> > > --
> > > busbey
> > >
> >
>

Re: Giving credit for contributions through Github Pull Requests

[Nandor Kollar <nk...@cloudera.com>]

+1 for both, especially for removing CHANGES.txt.

On Thu, May 3, 2018 at 11:18 PM, Doug Cutting <cu...@gmail.com> wrote:

> Maybe we should loosen the permissions on Avro's Jira so that any user can
> assign an issue?  That would make things a bit simpler.  I doubt we'd see
> much if any abuse.
>
> Also, it's probably time to remove CHANGES.txt and just use Jira to
> generate release notes.  Agreed?
>
> Doug
>
> On Thu, Apr 26, 2018 at 11:51 AM Sean Busbey <bu...@cloudera.com> wrote:
>
> > On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting <cu...@gmail.com> wrote:
> >
> > > So I guess this would be easier if we also said that contributions
> would
> > > only now be accepted via pull request.  Is that too onerous?  Instead
> of
> > > requiring everyone to have an Apache Jira account we require them to
> > have a
> > > GitHub account.
> > >
> > >
> > I take it the github contributor summary doesn't work for emails that
> > aren't associated with a github id?
> >
> > What about jumping on the Apache Kibble train? They're trying to make
> > similar "project observability" widgets as what github provides.
> >
> >
> >
> > > Moving issue tracking to GitHub seems unlikely, as it's lacking a lot
> of
> > > features we depend on from Jira.
> > >
> > >
> > I don't like the idea of moving from JIRA to GitHub issues, but I think
> GHI
> > has all the features we'd need to do so, FYI. Or atleast, I can't think
> of
> > any we use that don't have a mapping to something.
> >
> >
> > --
> > busbey
> >
>

Re: Giving credit for contributions through Github Pull Requests

[Doug Cutting <cu...@gmail.com>]

Maybe we should loosen the permissions on Avro's Jira so that any user can
assign an issue?  That would make things a bit simpler.  I doubt we'd see
much if any abuse.

Also, it's probably time to remove CHANGES.txt and just use Jira to
generate release notes.  Agreed?

Doug

On Thu, Apr 26, 2018 at 11:51 AM Sean Busbey <bu...@cloudera.com> wrote:

> On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting <cu...@gmail.com> wrote:
>
> > So I guess this would be easier if we also said that contributions would
> > only now be accepted via pull request.  Is that too onerous?  Instead of
> > requiring everyone to have an Apache Jira account we require them to
> have a
> > GitHub account.
> >
> >
> I take it the github contributor summary doesn't work for emails that
> aren't associated with a github id?
>
> What about jumping on the Apache Kibble train? They're trying to make
> similar "project observability" widgets as what github provides.
>
>
>
> > Moving issue tracking to GitHub seems unlikely, as it's lacking a lot of
> > features we depend on from Jira.
> >
> >
> I don't like the idea of moving from JIRA to GitHub issues, but I think GHI
> has all the features we'd need to do so, FYI. Or atleast, I can't think of
> any we use that don't have a mapping to something.
>
>
> --
> busbey
>

Re: Giving credit for contributions through Github Pull Requests

[Sean Busbey <bu...@cloudera.com>]

On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting <cu...@gmail.com> wrote:

> So I guess this would be easier if we also said that contributions would
> only now be accepted via pull request.  Is that too onerous?  Instead of
> requiring everyone to have an Apache Jira account we require them to have a
> GitHub account.
>
>
I take it the github contributor summary doesn't work for emails that
aren't associated with a github id?

What about jumping on the Apache Kibble train? They're trying to make
similar "project observability" widgets as what github provides.



> Moving issue tracking to GitHub seems unlikely, as it's lacking a lot of
> features we depend on from Jira.
>
>
I don't like the idea of moving from JIRA to GitHub issues, but I think GHI
has all the features we'd need to do so, FYI. Or atleast, I can't think of
any we use that don't have a mapping to something.


-- 
busbey

Re: Giving credit for contributions through Github Pull Requests

[Doug Cutting <cu...@gmail.com>]

So I guess this would be easier if we also said that contributions would
only now be accepted via pull request.  Is that too onerous?  Instead of
requiring everyone to have an Apache Jira account we require them to have a
GitHub account.

Moving issue tracking to GitHub seems unlikely, as it's lacking a lot of
features we depend on from Jira.

Doug

On Thu, Apr 26, 2018 at 10:31 AM Sean Busbey <bu...@cloudera.com> wrote:

> so we'd still do issue tracking in JIRA, but specifically for looking at
> who's contributed we'd use the github tooling?
>
> we could do a clean cut over for that. We'd have to get more rigorous at
> making sure the author on commits is the contributor. the current
> discrepency is a combination of svn days where it wasn't possible to
> attribute authorship in the metadata and folks not setting it when using
> git to commit a patch that comes in without metadata.
>
> On Thu, Apr 26, 2018 at 12:25 PM, Doug Cutting <cu...@gmail.com> wrote:
>
> > Might we instead switch from Jira to GitHub for contribution tracking?
> > Then we might not need to worry so much about who the Jira issue is
> > assigned to.
> >
> > GitHub has contribution history:
> >
> > https://github.com/apache/avro/graphs/contributors
> >
> > Is this sufficient?  It seems like it's missing a lot of older
> > contributors, as compared with Jira:
> >
> > https://s.apache.org/mgf9
> >
> > Thoughts?
> >
> > Doug
> >
> >
> > On Thu, Apr 26, 2018 at 4:53 AM Sean Busbey <bu...@cloudera.com> wrote:
> >
> > > how about we create a PMC-controlled jira account to represent "pull
> > > request from someone without a jira ID"? then we can follow your
> > suggestion
> > > of "encourage the contributor to create a jira id and assign to them"
> and
> > > we have a clear way to mark "you need to look at git or github to find
> > the
> > > author" when we go to look later.
> > >
> > > for CHANGES.txt we can either a) start asking contributors to update it
> > as
> > > a part of their PR, b) have the merging maintainer add a commit to the
> PR
> > > that does the CHANGES.txt update, c) switch to generating CHANGES.txt
> at
> > > release time rather than incrementally.
> > >
> > > for (c) we could use something like Apache Yetus Release Doc Maker[1],
> > > which currently would require us to ensure everything is represented in
> > > JIRA. Personally, I favor this last option.
> > >
> > >
> > > [1]: http://yetus.apache.org/documentation/0.7.0/releasedocmaker/
> > >
> > > On Mon, Apr 23, 2018 at 8:08 PM, Thiruvalluvan M. G <th...@apache.org>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > Officially, we say that we track issues using Jira:
> > > > https://avro.apache.org/
> > > > issue_tracking.html and suggest contributors to manage issues on
> Jira.
> > > But
> > > > we receive several pull requests on github with or without
> > corresponding
> > > > Jira tickets. What is the best way to handle them? How do other
> Apache
> > > > projects handle these?
> > > >
> > > > I see two levels of problems:
> > > >
> > > > 1. When we have a Jira ticket for an issue, we sometimes see
> > contribution
> > > > come from someone who does not have an account on Jira. Whom do we
> > assign
> > > > the Jira ticket to? We have a few options, none of them pretty:
> > > >
> > > > a. Insist that the contributor creates and account in our Jira and
> > assign
> > > > the ticket to themselves. This could leave the fixes unnecessarily
> > > blocked
> > > > for long time.
> > > > b. Leave the ticket unassigned. This is sloppy book-keeping.
> > > > c. Assign to the person who created the ticket. This is wrong
> > > attribution.
> > > > Will cause trouble in evaluating contributors for committership.
> > > > d. Assign to the person who merges the pull request. This is also
> wrong
> > > > attribution, but will encourage existing committers to consider and
> > merge
> > > > fixes expediously.
> > > >
> > > > My personal preference is the combination of (a) and (d). We should
> > > > encourage the contributor to assign the Jira to themselves. If they
> > don't
> > > > do it in reasonable time (1 week?) let's assign to the person
> > committing
> > > > it. But if the contributor comes back later with their Jira id, we
> > should
> > > > reassign the ticket to them.
> > > >
> > > > 2. Pull requests are raised without a corresponding Jira ticket. Here
> > one
> > > > of us can create a new Jira ticket. When we do this, the situation is
> > the
> > > > same as the previous one.
> > > >
> > > > A related question: When we merge the pull request it typically does
> > not
> > > > update CHANGES.txt. How and when do we update this file?
> > > >
> > > > Any suggestions?
> > > >
> > > > Thank you,
> > > >
> > > > Thiru
> > > >
> > >
> > >
> > >
> > > --
> > > busbey
> > >
> >
>
>
>
> --
> busbey
>

Re: Giving credit for contributions through Github Pull Requests

[Sean Busbey <bu...@cloudera.com>]

so we'd still do issue tracking in JIRA, but specifically for looking at
who's contributed we'd use the github tooling?

we could do a clean cut over for that. We'd have to get more rigorous at
making sure the author on commits is the contributor. the current
discrepency is a combination of svn days where it wasn't possible to
attribute authorship in the metadata and folks not setting it when using
git to commit a patch that comes in without metadata.

On Thu, Apr 26, 2018 at 12:25 PM, Doug Cutting <cu...@gmail.com> wrote:

> Might we instead switch from Jira to GitHub for contribution tracking?
> Then we might not need to worry so much about who the Jira issue is
> assigned to.
>
> GitHub has contribution history:
>
> https://github.com/apache/avro/graphs/contributors
>
> Is this sufficient?  It seems like it's missing a lot of older
> contributors, as compared with Jira:
>
> https://s.apache.org/mgf9
>
> Thoughts?
>
> Doug
>
>
> On Thu, Apr 26, 2018 at 4:53 AM Sean Busbey <bu...@cloudera.com> wrote:
>
> > how about we create a PMC-controlled jira account to represent "pull
> > request from someone without a jira ID"? then we can follow your
> suggestion
> > of "encourage the contributor to create a jira id and assign to them" and
> > we have a clear way to mark "you need to look at git or github to find
> the
> > author" when we go to look later.
> >
> > for CHANGES.txt we can either a) start asking contributors to update it
> as
> > a part of their PR, b) have the merging maintainer add a commit to the PR
> > that does the CHANGES.txt update, c) switch to generating CHANGES.txt at
> > release time rather than incrementally.
> >
> > for (c) we could use something like Apache Yetus Release Doc Maker[1],
> > which currently would require us to ensure everything is represented in
> > JIRA. Personally, I favor this last option.
> >
> >
> > [1]: http://yetus.apache.org/documentation/0.7.0/releasedocmaker/
> >
> > On Mon, Apr 23, 2018 at 8:08 PM, Thiruvalluvan M. G <th...@apache.org>
> > wrote:
> >
> > > Hi all,
> > >
> > > Officially, we say that we track issues using Jira:
> > > https://avro.apache.org/
> > > issue_tracking.html and suggest contributors to manage issues on Jira.
> > But
> > > we receive several pull requests on github with or without
> corresponding
> > > Jira tickets. What is the best way to handle them? How do other Apache
> > > projects handle these?
> > >
> > > I see two levels of problems:
> > >
> > > 1. When we have a Jira ticket for an issue, we sometimes see
> contribution
> > > come from someone who does not have an account on Jira. Whom do we
> assign
> > > the Jira ticket to? We have a few options, none of them pretty:
> > >
> > > a. Insist that the contributor creates and account in our Jira and
> assign
> > > the ticket to themselves. This could leave the fixes unnecessarily
> > blocked
> > > for long time.
> > > b. Leave the ticket unassigned. This is sloppy book-keeping.
> > > c. Assign to the person who created the ticket. This is wrong
> > attribution.
> > > Will cause trouble in evaluating contributors for committership.
> > > d. Assign to the person who merges the pull request. This is also wrong
> > > attribution, but will encourage existing committers to consider and
> merge
> > > fixes expediously.
> > >
> > > My personal preference is the combination of (a) and (d). We should
> > > encourage the contributor to assign the Jira to themselves. If they
> don't
> > > do it in reasonable time (1 week?) let's assign to the person
> committing
> > > it. But if the contributor comes back later with their Jira id, we
> should
> > > reassign the ticket to them.
> > >
> > > 2. Pull requests are raised without a corresponding Jira ticket. Here
> one
> > > of us can create a new Jira ticket. When we do this, the situation is
> the
> > > same as the previous one.
> > >
> > > A related question: When we merge the pull request it typically does
> not
> > > update CHANGES.txt. How and when do we update this file?
> > >
> > > Any suggestions?
> > >
> > > Thank you,
> > >
> > > Thiru
> > >
> >
> >
> >
> > --
> > busbey
> >
>



-- 
busbey

Re: Giving credit for contributions through Github Pull Requests

[Doug Cutting <cu...@gmail.com>]

Might we instead switch from Jira to GitHub for contribution tracking?
Then we might not need to worry so much about who the Jira issue is
assigned to.

GitHub has contribution history:

https://github.com/apache/avro/graphs/contributors

Is this sufficient?  It seems like it's missing a lot of older
contributors, as compared with Jira:

https://s.apache.org/mgf9

Thoughts?

Doug


On Thu, Apr 26, 2018 at 4:53 AM Sean Busbey <bu...@cloudera.com> wrote:

> how about we create a PMC-controlled jira account to represent "pull
> request from someone without a jira ID"? then we can follow your suggestion
> of "encourage the contributor to create a jira id and assign to them" and
> we have a clear way to mark "you need to look at git or github to find the
> author" when we go to look later.
>
> for CHANGES.txt we can either a) start asking contributors to update it as
> a part of their PR, b) have the merging maintainer add a commit to the PR
> that does the CHANGES.txt update, c) switch to generating CHANGES.txt at
> release time rather than incrementally.
>
> for (c) we could use something like Apache Yetus Release Doc Maker[1],
> which currently would require us to ensure everything is represented in
> JIRA. Personally, I favor this last option.
>
>
> [1]: http://yetus.apache.org/documentation/0.7.0/releasedocmaker/
>
> On Mon, Apr 23, 2018 at 8:08 PM, Thiruvalluvan M. G <th...@apache.org>
> wrote:
>
> > Hi all,
> >
> > Officially, we say that we track issues using Jira:
> > https://avro.apache.org/
> > issue_tracking.html and suggest contributors to manage issues on Jira.
> But
> > we receive several pull requests on github with or without corresponding
> > Jira tickets. What is the best way to handle them? How do other Apache
> > projects handle these?
> >
> > I see two levels of problems:
> >
> > 1. When we have a Jira ticket for an issue, we sometimes see contribution
> > come from someone who does not have an account on Jira. Whom do we assign
> > the Jira ticket to? We have a few options, none of them pretty:
> >
> > a. Insist that the contributor creates and account in our Jira and assign
> > the ticket to themselves. This could leave the fixes unnecessarily
> blocked
> > for long time.
> > b. Leave the ticket unassigned. This is sloppy book-keeping.
> > c. Assign to the person who created the ticket. This is wrong
> attribution.
> > Will cause trouble in evaluating contributors for committership.
> > d. Assign to the person who merges the pull request. This is also wrong
> > attribution, but will encourage existing committers to consider and merge
> > fixes expediously.
> >
> > My personal preference is the combination of (a) and (d). We should
> > encourage the contributor to assign the Jira to themselves. If they don't
> > do it in reasonable time (1 week?) let's assign to the person committing
> > it. But if the contributor comes back later with their Jira id, we should
> > reassign the ticket to them.
> >
> > 2. Pull requests are raised without a corresponding Jira ticket. Here one
> > of us can create a new Jira ticket. When we do this, the situation is the
> > same as the previous one.
> >
> > A related question: When we merge the pull request it typically does not
> > update CHANGES.txt. How and when do we update this file?
> >
> > Any suggestions?
> >
> > Thank you,
> >
> > Thiru
> >
>
>
>
> --
> busbey
>

Re: Giving credit for contributions through Github Pull Requests

[Sean Busbey <bu...@cloudera.com>]

how about we create a PMC-controlled jira account to represent "pull
request from someone without a jira ID"? then we can follow your suggestion
of "encourage the contributor to create a jira id and assign to them" and
we have a clear way to mark "you need to look at git or github to find the
author" when we go to look later.

for CHANGES.txt we can either a) start asking contributors to update it as
a part of their PR, b) have the merging maintainer add a commit to the PR
that does the CHANGES.txt update, c) switch to generating CHANGES.txt at
release time rather than incrementally.

for (c) we could use something like Apache Yetus Release Doc Maker[1],
which currently would require us to ensure everything is represented in
JIRA. Personally, I favor this last option.


[1]: http://yetus.apache.org/documentation/0.7.0/releasedocmaker/

On Mon, Apr 23, 2018 at 8:08 PM, Thiruvalluvan M. G <th...@apache.org>
wrote:

> Hi all,
>
> Officially, we say that we track issues using Jira:
> https://avro.apache.org/
> issue_tracking.html and suggest contributors to manage issues on Jira. But
> we receive several pull requests on github with or without corresponding
> Jira tickets. What is the best way to handle them? How do other Apache
> projects handle these?
>
> I see two levels of problems:
>
> 1. When we have a Jira ticket for an issue, we sometimes see contribution
> come from someone who does not have an account on Jira. Whom do we assign
> the Jira ticket to? We have a few options, none of them pretty:
>
> a. Insist that the contributor creates and account in our Jira and assign
> the ticket to themselves. This could leave the fixes unnecessarily blocked
> for long time.
> b. Leave the ticket unassigned. This is sloppy book-keeping.
> c. Assign to the person who created the ticket. This is wrong attribution.
> Will cause trouble in evaluating contributors for committership.
> d. Assign to the person who merges the pull request. This is also wrong
> attribution, but will encourage existing committers to consider and merge
> fixes expediously.
>
> My personal preference is the combination of (a) and (d). We should
> encourage the contributor to assign the Jira to themselves. If they don't
> do it in reasonable time (1 week?) let's assign to the person committing
> it. But if the contributor comes back later with their Jira id, we should
> reassign the ticket to them.
>
> 2. Pull requests are raised without a corresponding Jira ticket. Here one
> of us can create a new Jira ticket. When we do this, the situation is the
> same as the previous one.
>
> A related question: When we merge the pull request it typically does not
> update CHANGES.txt. How and when do we update this file?
>
> Any suggestions?
>
> Thank you,
>
> Thiru
>



-- 
busbey