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