Hey William, Thanks for pointing this inconsistency out out.
Best Regards, Myrle On Fri, Aug 9, 2019 at 12:22 AM William Shen <wills...@marinsoftware.com> 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: > > 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 <gurwls...@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 <my...@apache.org>님이 작성: >> >>> >>> >>> On Tue, Aug 6, 2019 at 7:57 PM Sean Owen <sro...@apache.org> wrote: >>> >>>> On Tue, Aug 6, 2019 at 11:45 AM Myrle Krantz <my...@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 >>> >>
