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