Re: Recognizing non-code contributions

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Sean Owen-3
On Tue, Aug 6, 2019 at 10:46 AM Myrle Krantz <[hidden email]> wrote:

>> You can tell there's a range of opinions here. I'm probably less
>> 'conservative' about adding committers than most on the PMC, right or
>> wrong, but more conservative than some at the ASF. I think there's
>> room to inch towards the middle ground here and this is good
>> discussion informing the thinking.
>
>
> That's not actually my current reading of the Spark community.  My current reading based on the responses of Hyukjin, and Jungtaek, is that your community wouldn't take a non-coding committer no matter how clear their contributions are to the community, and that by extension such a person could never become a PMC member.
>
> If my reading is correct (and the sample size *is* still quite small, and only includes one PMC member), I see that as a serious problem.

Again if "non-code" means "no interaction with the project repo", no I
do not hear support for making said person a committer for all the
reasons you've heard here. I don't support it.

Wait, didn't we just get done agreeing that's a reasonable position if
not one you hold? I'm quite confused.
It's fine to invite the board, members to come participate here as you
have just done separately, but you're now portraying this as a serious
offense, despite your comments here?

---------------------------------------------------------------------
To unsubscribe e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Myrle Krantz


On Tue, Aug 6, 2019 at 6:11 PM Sean Owen <[hidden email]> wrote:
On Tue, Aug 6, 2019 at 10:46 AM Myrle Krantz <[hidden email]> wrote:
>> You can tell there's a range of opinions here. I'm probably less
>> 'conservative' about adding committers than most on the PMC, right or
>> wrong, but more conservative than some at the ASF. I think there's
>> room to inch towards the middle ground here and this is good
>> discussion informing the thinking.
>
>
> That's not actually my current reading of the Spark community.  My current reading based on the responses of Hyukjin, and Jungtaek, is that your community wouldn't take a non-coding committer no matter how clear their contributions are to the community, and that by extension such a person could never become a PMC member.
>
> If my reading is correct (and the sample size *is* still quite small, and only includes one PMC member), I see that as a serious problem.

Again if "non-code" means "no interaction with the project repo", no I
do not hear support for making said person a committer for all the
reasons you've heard here. I don't support it.

Wait, didn't we just get done agreeing that's a reasonable position if
not one you hold? I'm quite confused.
It's fine to invite the board, members to come participate here as you
have just done separately, but you're now portraying this as a serious
offense, despite your comments here?

I think both representations of my position are inaccurate.

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.

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

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.

Does that make it clearer?

Best Regards,
Myrle
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Sean Owen-3
On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz <[hidden email]> 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?

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.

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.


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


> 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"?

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.

---------------------------------------------------------------------
To unsubscribe e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Myrle Krantz


On Tue, Aug 6, 2019 at 7:57 PM Sean Owen <[hidden email]> wrote:
On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Hyukjin Kwon
> 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 <[hidden email]>님이 작성:


On Tue, Aug 6, 2019 at 7:57 PM Sean Owen <[hidden email]> wrote:
On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

William Shen
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:

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.

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, no; according to community.apache.org, yes. And that difference seems to be a main point of discussion here. 

By www.apache.org, 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 <[hidden email]> 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 <[hidden email]>님이 작성:


On Tue, Aug 6, 2019 at 7:57 PM Sean Owen <[hidden email]> wrote:
On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing non-code contributions

Myrle Krantz
Hey William,

Thanks for pointing this inconsistency out out.

Best Regards,
Myrle

On Fri, Aug 9, 2019 at 12:22 AM William Shen <[hidden email]> wrote:
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:

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.

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, no; according to community.apache.org, yes. And that difference seems to be a main point of discussion here. 

By www.apache.org, 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 <[hidden email]> 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 <[hidden email]>님이 작성:


On Tue, Aug 6, 2019 at 7:57 PM Sean Owen <[hidden email]> wrote:
On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz <[hidden email]> 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
12