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 <gurwls...@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 <my...@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 <sro...@apache.org> wrote: >> >>> On Mon, Aug 5, 2019 at 3:50 AM Myrle Krantz <my...@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 >> >
