spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Shen <>
Subject Re: Recognizing non-code contributions
Date Thu, 08 Aug 2019 22:21:50 GMT
Not sure where this thread is heading toward, but I find the role
definition listed on clarifying and
well defined, though they seem to vary slightly from what is on Not sure which one is more

In the context of this thread, here is the difference as I see it:

On <>

> A *committer* is a *developer* that was given write access to the code
> repository and has a signed Contributor License Agreement (CLA) on file.
> A *developer* is a *user* who contributes to a project in the form of *code
> or documentation*.

Hence, a committer is a user, who contributes code or documentation, that
was given write access to the repository.

On <>,

> Committer is a term used at the ASF to signify someone who is committed to
> a particular project. It brings with it the privilege of write access to
> the project repository and resources.
> The foundations of an Apache project and how the community contributes to
> it is sometimes referred to by the acronym CoPDoC: (Co)mmunity - one must
> interact with others, and share vision and knowledge (P)roject - a clear
> vision and consensus are needed (Do)cumentation - without it, the stuff
> remains only in the minds of the authors (C)ode - discussion goes nowhere
> without code
> once someone has contributed sufficiently to any area of CoPDoC they can
> be voted in as a committer.

Hence, a committer is someone, who has contributed sufficiently to *any*
area of Community, Project, Documentation, and Code, that has been given
write access to the project repository and resources.

The key difference between the two definitions is: Can someone, who
contribute significantly in the area of Community or Project without
contribution to Documentation nor Code, be a committer? According to <>,
no; according to
<>, yes. And that difference
seems to be a main point of discussion here.

By <>,
a committer seems to be a role designed to create a subset of users to
"making short-term decisions for the project," and I think that reference
to the ability to commit a patch for Code or Documentation in the project's
repository or resources. And I think that is sensible, and may be in
support of limiting committership to those, who contribute sufficiently
code or documentation to a project's repository or resources, that the
project invites to make future commit decisions for the project.

On Wed, Aug 7, 2019 at 6:07 AM Hyukjin Kwon <> wrote:

> > Currently, I have heard some ideas or attitudes that I consider to be
> overly motivated by fear of unlikely occurrences.
> > And I've heard some statements disregard widely accepted principles of
> inclusiveness at the Apache Software Foundation.
> > But I suspect that there's more to the attitude of not including
> non-coding committers at Spark.
> I missed some contexts you mentioned. Yes, SVN and commons look good
> examples.
> Also, for clarification, I did not mean to absolutely do not add
> non-codding committers.
> Spark already has build/config committer and I am happy with that.
> I was replaying to "the risk is very small". Given my experience in Spark
> dev, people (and I) make mistakes
> which, for instance, blocks the release months. Sometimes it requires to
> rewrite whole PRs with courtesy
> (rather than, for instance, reverting). This is already happening and it
> brings some overhead to the dev.
> Yes, maybe the volume matters to handle those issues.
> The point I was trying to make was commit bit could be a too strong sword
> and might have to be
> given and used with familiarity and caution.
> For clarification, I have no issue except one concern above for the fact
> that someone becomes a non-code committer since Spark already has it.
> 2019년 8월 7일 (수) 오후 6:04, Myrle Krantz <>님이 작성:
>> On Tue, Aug 6, 2019 at 7:57 PM Sean Owen <> wrote:
>>> On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz <> wrote:
>>> > I had understood your position to be that you would be willing to make
>>> at least some non-coding contributors to committers but that your "line" is
>>> somewhat different than my own.   My response to you assumed that position
>>> on your part.  I do not think it's good for a project to accept absolutely
>>> no non-code committers.  If nothing else, it violates my sense of fairness,
>>> both towards those contributors, and also towards the ASF which relies on a
>>> pipeline of non-code contributors who come to us through the projects.
>>> Oh OK, I thought this argument was made repeatedly: someone who has
>>> not and evidently will not ever commit anything to a project doesn't
>>> seem to need the commit bit. Agree to disagree. That was the
>>> 'non-code' definition?
>> That argument was made and acknowledged.  And then answered with:
>> a.) the commit bit is only part of what makes a committer, and not the
>> most important part.
>> b.) including the commit bit in the package is harmless.  The risk
>> associated with giving someone the commit bit who is not going to use it is
>> lower than the risk associated with the average pull request.
>> c.) creating a new package without the commit-bit creates significant
>> effort and bears significant risks.
>>> Someone who contributes docs to the project? Sure. We actually have
>>> done this, albeit for a build and config contributions. Agree.
>>> Pardon a complicated analogy to explain my thinking, but: let's say
>>> the space of acceptable decisions on adding committers at the ASF
>>> ranges from 1 (Super Aggressive) to 10 (Very Conservative). Most
>>> project decisions probably fall in, say, 3 to 7. Here we're debating
>>> whether a project should theoretically at times go all the way to 1,
>>> or at most 2, and I think that's just not that important. We're pretty
>>> much agreeing 2 is not out of the question, 1 we agree to disagree.
>>> Spark decisions here are probably 5-7 on average. I'd like it be like
>>> 4-6 personally. I suspect the real inbound argument is: all projects
>>> should be making all decisions in 1-3 or else it isn't The Apache Way.
>>> I accept anecdotes that projects function well in that range, but,
>>> Spark and Hadoop don't seem to (nor evidently Cassandra). I have a
>>> hard time rationalizing this. These are, after all, some of the
>>> biggest and most successful projects at Apache. At times it sounds
>>> like concern trolling, to 'help' these projects not fall apart.
>>> If so, you read correctly that there is a significant difference of
>>> opinion here, but that's what it is. Not the theoretical debate above.
>> I think this misrepresents where the "middle" is in Apache projects.  I
>> think the middle is probably closer to where OfBiz is: occasionally
>> offering non-coding contributors committership, but probably not with the
>> frequency I would like.  But even that occasional committership for
>> non-coding committers has been extraordinarily important for the ASF as an
>> organization.  Sharan Foga started as a non-coding contributor for OfBiz,
>> and is now VP of Community Development at the ASF, and organized the Apache
>> Roadshow in Berlin last year (where Spark talks were well-received and
>> probably helped your community). The OfBiz project did us all a huge favor
>> by providing Sharan with the first step into our organization.
>> What you are perceiving as an extreme is the SVN project in which all you
>> have to do to receive committership is to ask.  Or the commons project in
>> which in which every ASF member is automatically a committer.  Those
>> projects can't be claimed to be insensitive to bugs.  SVN is a data
>> repository: bugs can cause you to lose your code. For commons, programming
>> mistakes can cause security flaws, compile errors and worse in a massive
>> number of dependent project.  And yes, I know you've seen all of that
>> conversation, Sean, but most of it was on members@, so I'm summarizing
>> here for those who can't see members@.
>> If Spark and Hadoop and Cassandra don't include non-coding contributors
>> in their committer candidate pool, that puts them on the outer extreme of
>> ASF projects.  These projects are undeniably successful despite this fact.
>> But I still wouldn't recommend the approach to other ASF projects.  I do
>> not believe most projects can get away with this and still survive long
>> term.
>>> Spark should shift, but equally, so should this viewpoint from some at
>>> the ASF, as I find my caricature of it equally suboptimal.
>>> Shred that analogy as you like, but it explains what's in my head.
>> I disagree, but if you want to change that position at the ASF, a good
>> place to start the conversation is on dev@community.
>> > For more documentation on the definition of a committer at Apache, read
>>> here:  "Being a committer
>>> does not necessarily mean you commit code, it means you are committed to
>>> the project and are productively contributing to its success."
>>> Per above, I just don't think this statement should be in the canon,
>>> and would prefer to clarify it, but hey it is there and I accept it.
>>> Still: what's committed? I'd define committed to the project, as,
>>> well, working on the project's output. It just punts the question.
>> That content is owned by the community project.  The appropriate place to
>> request a change is on dev@community.
>> No project can be successful without QA, design, project management, user
>> care, documentation, marketing, infrastructure, community building and
>> more.  Working together to create artifacts is important.  It represents
>> the community's common goal, and provides a point around which to organize
>> efforts.  Without non-coding contributions, projects won't be able to
>> produce those artifacts, or they'll be dependent on corporate patronage, or
>> they just won't be as good as they could be.
>>> > I also don't yet see a "serious offense" here.  My e-mail to board@
>>> is simply a heads up, which I do owe the rest of the board when I'm
>>> interacting with one of our projects.  Here are my exact words: "Most of
>>> that discussion is fairly harmless.  Some of it, I have found concerning."
>>> Right now, I'm still trying to approach Spark's position with a
>>> learning-and-teaching mindset.
>>> I'm nitpicking your words, which are by themselves reasonable. I think
>>> learning-and-teaching is just the right attitude.
>>> But have you heard different ideas here that are valid or merely "not
>>> harmful"? are the ideas you don't share just not your choice or
>>> "concerning"?
>> Currently, I have heard some ideas or attitudes that I consider to be
>> overly motivated by fear of unlikely occurrences.  And I've heard some
>> statements disregard widely accepted principles of inclusiveness at the
>> Apache Software Foundation.
>> But I suspect that there's more to the attitude of not including
>> non-coding committers at Spark.  You have a community that is larger than
>> the average at the ASF.  Dunbar's number is 150 ("humans can comfortably
>> maintain 150 stable relationships" - check it on wikipedia).  With PMC and
>> committers, Spark is already well over 100. You may feel like you're losing
>> the ability to integrate new people into your community at that size.  And
>> that may be the real reason you are trying to find a more selective
>> criteria to base community membership decisions on.
>> Here's the thing: communities at the ASF decide themselves who to offer
>> committership to.  This is an important principle, and one we only overrule
>> in the most extreme of circumstances.  And I don't currently see an
>> "extreme circumstance" here.  If I dislike the way you are making those
>> decisions, my best recourse is to try to change prevailing attitudes.  And
>> in order to do that, I have to try to understand where those attitudes are
>> coming from.  Calling people names or shouting "first principles" or "The
>> Apache Way" is not going to be very convincing, amiright?  I'm not inclined
>> to that sort of behavior anyways.  I have to explain the benefits of the
>> approach I'm advocating for, and explain why the fears are unfounded.
>> But if the real problem is that the community is too large for comfort,
>> then my arguments don't address that.
>> I'm afraid it primes people to drive by to feel good delivering the
>>> safe, conventional mom-and-apple-pie ideals: what are you afraid of?
>>> what is your problem with openness? why do you hate freedom and The
>>> Apache Way? We'll have another round of throw-the-bums-out,
>>> shut-it-all-down threads. These aren't wrong ideals. It just generates
>>> no useful discussion, and is patronizing. I find it hard to dissent
>>> reasonably.
>> No drive-by's yet.  I can see your concern though, especially since I've
>> seen that sort of thing happen in other contexts.  It was not my intention
>> to provoke drive-by's; I tried to phrase my message accordingly.  I simply
>> wanted to adhere to the principles of openness that are so important at the
>> ASF.
>> We've had complaints on members@ about people learning about important
>> conversations "too late", and requests to notify board@ about such
>> conversations.
>> Best,
>> Myrle

View raw message