nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Percivall <joeperciv...@yahoo.com.INVALID>
Subject Re: A few questions on tracking project participation
Date Wed, 21 Oct 2015 16:39:04 GMT
You can get some of the information about the contributors from the Apache NiFi Github contributor
page: https://github.com/apache/nifi/graphs/contributors
>From a cursory look it has each person that has authored a commit and then who ever committed
it on behave of them. It purely ranks based on number of commits though. 
Joe- - - - - - Joseph Percivalllinkedin.com/in/Percivalle: joepercivall@yahoo.com
 


     On Wednesday, October 21, 2015 9:32 AM, Joe Witt <joe.witt@gmail.com> wrote:
   

 Sean

Your suggested questions were all good.  This whole concept of being
able to assess and understand activity/contribution/growth would be
very cool.  How do we avoid over-weighting such a thing based on code
commits?  We really need to value other forms of contribution quite
highly as well.

Today when a contributor without commit privileges provides a patch or
PR the JIRA is typically assigned to whoever ends up doing the
review/merge.  That is at least how I have been doing it.  I can't
honestly say I've paid much attention to what others have done.  For
code/JIRA it is pretty easy to see how we can assess
contribution/engagement for a given release for example.  I like very
much how other communities are able to actually recognize these folks
contributions.  We need to do that as well.  I'd also like to find a
way to highly people who are active on the mailing list.  There though
it is much harder to quantify as some of that activity is consumption
and some of it is contribution.  I guess we should just not
distinguish and simply recognize folks somehow for adding their voice
to the community in any regard.

Can you help me understand a bit more about where you're heading or
would like to see us heading as a community here?

Thanks
Joe

On Wed, Oct 21, 2015 at 9:19 AM, Tony Kurc <trkurc@gmail.com> wrote:
>> That would be wonderful. Would you be fine if I rolled the info up into
>> a PMC guide?
>
> Yes, I'll pull together some examples tonight
>
> On Tue, Oct 20, 2015 at 4:54 PM, Sean Busbey <busbey@cloudera.com> wrote:
>
>> well that's frustrating.
>>
>> It was approximately:
>>
>> [1]: The use of ammending-author started as a way of handling
>> gnarly cherry-picks back to earlier release lines in HBase, but
>> I've seen it show up on a couple of multiple-author patches
>> generally.
>>
>> The HBase reference guide is 404 at the moment, so the best
>> link I can find is the mailing list thread the explanation references:
>>
>> http://search-hadoop.com/m/DHED4wHGYS
>>
>>
>>
>> On Tue, Oct 20, 2015 at 3:46 PM, Tony Kurc <trkurc@gmail.com> wrote:
>> > Sean,
>> > I think your footnote link got chopped.
>> >
>> > Tony
>> >
>> > On Tue, Oct 20, 2015 at 4:39 PM, Sean Busbey <busbey@cloudera.com>
>> wrote:
>> >
>> >> Well, I admit that my questions were as much to get more questions as
>> >> to advance an idea of answers. :)
>> >>
>> >>
>> >> On Tue, Oct 20, 2015 at 3:16 PM, Tony Kurc <trkurc@gmail.com> wrote:
>> >> > Sean,
>> >> > Can you better define "completed by a non-committer"?
>> >> >
>> >>
>> >> Where the majority of the work is done by a non-commiter. I'd even err
>> >> this on the side of "any substantial", but that's largely because I try
>> to
>> >> err
>> >> on the side of encouraging new people with visible credit.
>> >>
>> >>
>> >> > Some cases to consider
>> >> > Is "a jira" complete when a patch is submitted or when it is merged
>> into
>> >> > the code repository?
>> >>
>> >> definitely when all work is complete, and for things that involve
>> patches
>> >> to the code base, that would mean merged (either into a release line
>> >> or into a feature branch if the jira is a part of a mutli-jira effort
>> with
>> >> such
>> >> a feature branch).
>> >>
>> >>
>> >> > If a patch requires a bit of work to integrate (and test), where does
>> >> that
>> >> > fall?
>> >>
>> >> In other projects I usually cover this with the commit's
>> "signed-off-by".
>> >> if
>> >> there's a substantial amount of changes involved then an additional
>> >> "ammending-author" tag per extra contributor (e.g. hbase does this
>> >> as policy[1]). Figuring out when the tag is needed is largely a
>> judgement
>> >> call AFAICT.
>> >>
>> >> In both of those cases, I'd personally prefer the jira go to whomever
>> did
>> >> the bulk of the work. 'did the bulk of the work' could be the original
>> >> author or the
>> >> integrator depending on jira phrasing, e.g. 'incorporate this external
>> >> work' is different from a patch that is 80% done by an initial
>> contributor
>> >> but finished by another.
>> >>
>> >> I've definitely seen projects take the other substantially less
>> ambiguous
>> >> approach. Apache Curator, for example, assigns jiras to whatever
>> >> committer handled the merge.
>> >>
>> >> > What if a patch provider doesn't have a jira account?
>> >>
>> >> How would we track provenance of the contribution / grant to the ASF?
>> >> I guess by git information? At the risk of derailing this thread, is git
>> >> how we're doing this now?
>> >>
>> >> > What if integrating a patch a substantial rewrite of the patch?
>> >>
>> >> I'd usually push back on the contributor to do the rewrite in most cases
>> >> and use "amending-author" in git as described above for either the
>> >> original or amending author.
>> >>
>> >>
>> >> >
>> >> > I can certainly tell you what I did based on my ability to
>> "introspect"
>> >> our
>> >> > team conventions from jira, commit log and mailing list in lieu of
a
>> >> > documented committer guide.
>> >> >
>> >>
>> >> That would be wonderful. Would you be fine if I rolled the info up into
>> >> a PMC guide?
>> >>
>> >> --
>> >> Sean
>> >>
>>
>>
>>
>> --
>> Sean
>>


  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message