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 <cutt...@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 <bus...@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
