spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyukjin Kwon <gurwls...@gmail.com>
Subject Re: Recognizing non-code contributions
Date Tue, 06 Aug 2019 08:11:27 GMT
So, here's my thought:

1. Back to the original point, for recognition of such people, I think we
can simply list up such people in Spark Website somewhere. For instance,

  Person A: Spark Book
  Person B: Meetup leader

I don't know if ASF allows this. Someone needs to check it.


2. If we need the in-between status officially (e.g. Apache email or
something), it should be asked and discussed in ASF, not in a single
project here.


2019년 8월 6일 (화) 오후 4:55, Hyukjin Kwon <gurwls223@gmail.com>님이 작성:

> Myrle,
>
> > We need to balance two sets of risks here.  But in the case of access to
> our software artifacts, the risk is very small, and already has *multiple*
> mitigating factors, from the fact that all changes are tracked to an
> individual, to the fact that there are notifications sent when changes are
> made, (and I'm going to stop listing the benefits of a modern source
> control system here, because I know you are aware of them), on through the
> fact that you have automated tests, and continuing through the fact that
> there is a release process during which artifacts get checked again.
> > If someone makes a commit who you are not expecting to make a commit, or
> in an area you weren't expecting changes in, you'll notice that, right?
> > What you're talking about here is your security model for your source
> repository.  But restricting access isn't really the right security model
> for an open source project.
>
> I don't quite get the argument about commit bit. I _strongly_ disagree
> about "the risk is very small,".
> Not all of committers track all the changes. There are so many changes in
> the upstream and it's already overhead to check all.
> Do you know how many bugs Spark faces due to such lack of reviews that
> entirely blocks the release sometimes, and how much it takes time to fix up
> such commits?
> We need expertise and familiarity to Spark.
>
> It virtually means we will add some more overhead to audit each commit,
> even for committers'. Why should we bother add such overhead to harm the
> project?
> To me, this is the most important fact. I don't think we should just count
> the number of positive and negative ones.
>
> For other reasons, we can just add or discuss about the "this kind of
> in-between status Apache-wide", which is a bigger scope than here. You can
> ask it to ASF and discuss further.
>
>
> 2019년 8월 6일 (화) 오후 3:14, Myrle Krantz <myrle@apache.org>님이 작성:
>
>> Hey Sean,
>>
>> Even though we are discussing our differences, on the whole I don't think
>> we're that far apart in our positions.  Still the differences are where the
>> conversation is actually interesting, so here goes:
>>
>> On Mon, Aug 5, 2019 at 3:55 PM Sean Owen <srowen@apache.org> wrote:
>>
>>> On Mon, Aug 5, 2019 at 3:50 AM Myrle Krantz <myrle@apache.org> wrote:
>>> > So... events coordinators?  I'd still make them committers.  I guess
>>> I'm still struggling to understand what problem making people VIP's without
>>> giving them committership is trying to solve.
>>>
>>> We may just agree to disagree, which is fine, but I think the argument
>>> is clear enough: such a person has zero need for the commit bit.
>>> Turning it around, what are we trying to accomplish by giving said
>>> person a commit bit? I know people say there's no harm, but I think
>>> there is at least _some_ downside. We're widening access to change
>>> software artifacts, the main thing that we put ASF process and checks
>>> around for liability reasons. I know the point is trust, and said
>>> person is likely to understand to never use the commit bit, but it
>>> brings us back to the same place. I don't wish to convince anyone else
>>> of my stance, though I do find it more logical, just that it's
>>> reasonable within The Apache Way.
>>>
>>
>> We need to balance two sets of risks here.  But in the case of access to
>> our software artifacts, the risk is very small, and already has *multiple*
>> mitigating factors, from the fact that all changes are tracked to an
>> individual, to the fact that there are notifications sent when changes are
>> made, (and I'm going to stop listing the benefits of a modern source
>> control system here, because I know you are aware of them), on through the
>> fact that you have automated tests, and continuing through the fact that
>> there is a release process during which artifacts get checked again.
>>
>> If someone makes a commit who you are not expecting to make a commit, or
>> in an area you weren't expecting changes in, you'll notice that, right?
>>
>> What you're talking about here is your security model for your source
>> repository.  But restricting access isn't really the right security model
>> for an open source project.
>>
>>
>>> > It also just occurred to me this morning: There are actually other
>>> privileges which go along with the "commit-bit" other than the ability to
>>> commit at will to the project's repos: people who are committers get an
>>> Apache e-mail address, and they get discounted entry to ApacheCon.  People
>>> who are committers also get added to our committers mailing list, and are
>>> thus a little easier to integrate into our foundation-wide efforts.
>>> >
>>> > To apply this to the example above, the Apache e-mail address can make
>>> it a tad easier for an event coordinator to conduct official business for a
>>> project.
>>>
>>> Great points. Again if I'm making it up? a "VIP" should get an Apache
>>> email address and discounts. Sure, why not put them on a committers@
>>> list too for visibility.
>>>
>>
>> In order to do that, you'd need to create this kind of in-between status
>> Apache-wide.  I would be very much opposed to doing that for a couple of
>> reasons:
>> * It adds complexity for infra and events with no clear benefits to the
>> projects.
>> * The risk of creating a second-class status at the ASF is just too high
>> for my comfort.
>>
>>
>>> > But that's not what I'm arguing.  I'm arguing that you can safely give
>>> commit access to anyone for whom you're reasonably certain they will do no
>>> harm.  And your certainty of that can actually be much higher with
>>> non-coding committers.  So if someone suggests a non-coding contributor for
>>> committer, it should be fairly easy to say "yes".  Especially if you're on
>>> a project like Spark where PMC ⊂ committers.
>>>
>>> (Just to again be clear, we aren't talking only about 'non-coding'
>>> committers. If it's shorthand for 'not contributing to docs/code in
>>> the repo', we're on the same page.)
>>>
>>
>> Ack.  I actually think of documentation which goes into the repo as code,
>> so I do think we're on the same page here.
>>
>>
>>> The case that started this is a corner case. The more interesting case
>>> is, in fact, a docs-only contributor. That hasn't quite come up -- we
>>> had a case of build- and config-only committer though. It's worth
>>> keeping these arguments in mind for this more ambiguous hypothetical.
>>> No objections in theory to making said person a committer, but in
>>> practice it may be a harder case, possibly unnecessarily hard.
>>>
>>
>> Documents are IP.  You're better off if you have an ICLA for that stuff,
>> regardless of where it lands in your project content.  And the most natural
>> point in time to request an ICLA is at committer invitation.
>>
>>
>>> > For solving the early and easy recognition problem, I've heard about
>>> people just saying "thank you" or making a "contributor of the month"
>>> honor.  That kind of recognition doesn't necessarily have to be in the form
>>> of a status.
>>>
>>> Sure, we do some of that on PRs, but probably need to do more. There
>>> are some regular contributors doing good work, and I hope they feel
>>> recognized by the fact they get more attention because of their track
>>> record, but being explicit goes a long way.
>>>
>>
>> As they say: positive feedback to negative feedback ratio should be 7:1.
>> There are other parts of the foundation where we need to place more
>> emphasis on positive feedback too.
>>
>> Best,
>> Myrle
>>
>

Mime
View raw message