spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <>
Subject Re: Recognizing non-code contributions
Date Mon, 05 Aug 2019 13:55:00 GMT
On Mon, Aug 5, 2019 at 3:50 AM Myrle Krantz <> 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.

> 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.

> 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.)
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.

> 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.

To unsubscribe e-mail:

View raw message