spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Shen <wills...@marinsoftware.com>
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
http://www.apache.org/foundation/how-it-works.html#roles clarifying and
well defined, though they seem to vary slightly from what is on
https://community.apache.org/contributors/. Not sure which one is more
authoritative.

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

On www.apache.org <http://www.apache.org/foundation/how-it-works.html#roles>
,

> 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 community.apache.org <https://community.apache.org/contributors/>,

> 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
www.apache.org <http://www.apache.org/foundation/how-it-works.html#roles>,
no; according to community.apache.org
<https://community.apache.org/contributors/>, yes. And that difference
seems to be a main point of discussion here.

By www.apache.org <http://www.apache.org/foundation/how-it-works.html#roles>,
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 <gurwls223@gmail.com> 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 <myrle@apache.org>님이 작성:
>
>>
>>
>> On Tue, Aug 6, 2019 at 7:57 PM Sean Owen <srowen@apache.org> wrote:
>>
>>> On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz <myrle@apache.org> 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: https://community.apache.org/contributors/  "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
>>
>

Mime
View raw message