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? 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: dev-unsubscr...@spark.apache.org
