Re: Giving credit for contributions through Github Pull Requests
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 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
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 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 > 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
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 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 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 > > 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
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 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 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 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 > > > 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
On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting 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
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 wrote: > On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting 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
+1 for both, especially for removing CHANGES.txt. On Thu, May 3, 2018 at 11:18 PM, Doug Cutting 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 wrote: > > > On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting 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
+1 for both On Fri, May 4, 2018 at 9:54 AM, Nandor Kollar wrote: > +1 for both, especially for removing CHANGES.txt. > > On Thu, May 3, 2018 at 11:18 PM, Doug Cutting 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 > wrote: > > > > > On Thu, Apr 26, 2018 at 1:43 PM, Doug Cutting > 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
On Thu, May 3, 2018 at 4:18 PM, Doug Cutting 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