On Sun, Aug 4, 2019 at 10:06 PM Sean Owen <sro...@apache.org> wrote: > Oops, I also failed to copy dev@ > > On Sun, Aug 4, 2019 at 3:06 PM Sean Owen <sro...@apache.org> wrote: > > > > On Sun, Aug 4, 2019 at 1:54 PM Myrle Krantz <my...@apache.org> wrote: > > >> No, I think the position here was docs-only contributors _could_ be > > >> committers. The "only coders can be committers" idea was I think a > > >> misreading and accidental strawman from the members@ thread. > > > > > > Can you be specific? This status us supposed to serve as a form of > recognition, right? For who or what contributions? > > > > This "VIP" status is purely theoretical, but if I were making it up? > > it would be for anyone, and any 'valuable' contribution to the > > community of any kind. > > Here I'm merely saying that nobody here suggested docs-only > > contributors could never be committers. That seemed to be what the > > members@ thread was taking on, as if the argument was that docs-only > > contributors are at best these "VIPs". I want to make sure this isn't > > predicated on a misunderstanding. >
So... events coordinators? I'd still make them committers. I guess I'm still struggling to understand what problem making people VIP's without giving them committership is trying to solve. It also just occurred to me this morning: There are actually other privileges which go along with the "commit-bit" other than the ability to commit at will to the project's repos: people who are committers get an Apache e-mail address, and they get discounted entry to ApacheCon. People who are committers also get added to our committers mailing list, and are thus a little easier to integrate into our foundation-wide efforts. To apply this to the example above, the Apache e-mail address can make it a tad easier for an event coordinator to conduct official business for a project. > > We have a saying at Apache: merit doesn't expire. This is especially > important for volunteer-based project work. People's availability varies. > If the barrier to re-entry is low, you're more likely to get contributions > from these people. Contributions that can have a particularly high value > because they are informed by a longer history of the project. > > > > I know, I'm also here at Apache :) I guess I'm just showing we have > > already taken a broad view of merit, consistent with Apache, when > > there are even reasonable arguments about defining committer merit > > more narrowly. This responds to the general notion I hear, that the > > PMC here is somehow out of line and needs reeducation. > I don't think the PMC is "out of line". I advocate for ease of access to other projects too. (For example: https://twitter.com/myrleKrantz/status/1110475989941932038). I do it because I think it will be helpful to the projects. But it absolutely is true that every project decides for themselves what obstacles to access they want to put in to place. As long as they are being equitable while doing that, the projects are within their rights. > > > But the real question which I feel needs an answer here is: what's the > harm you fear? With modern source control, surely any harm is reversible? > If you're worried about people doing things outside their "abilities", then > maybe the real question you need to ask when choosing committers is just: > do they know to ask for help first in fragile parts of the code? You may > find that someone who is doesn't see themselves as a coder is *less* likely > to break code than other committers. > > > > This is a vital point. The argument is, what are you afraid of? how > > much harm can a committer do? The logical extreme is to give everyone > > commit access, which nobody appears to advocate. But where's the line? > > What 'merit' are we talking about when we say people earn merit and > > that's rewarded with committership? You said it: good judgment above > > all. We have a committer that only run builds and config and doesn't > > deal with code at all, and we agree that's good. > There are some people who will advocate that everyone should receive commit access. SVN is an example of this, and they had great success with that approach. But that's not what I'm arguing. I'm arguing that you can safely give commit access to anyone for whom you're reasonably certain they will do no harm. And your certainty of that can actually be much higher with non-coding committers. So if someone suggests a non-coding contributor for committer, it should be fairly easy to say "yes". Especially if you're on a project like Spark where PMC ⊂ committers. > > That is I'm not sure we (speaking broadly for Spark) disagree > > substantively. Again the premise here was: somebody who hasn't and > > doesn't want to touch anything about the project or ASF. I'm surprised > > if there's an argument for making said person a committer; I thought > > this was the easiest of cases. Still, I am quite sure ASF projects > > have done this (and I disagreed). It's not crazy. But it's at least as > > un-crazy to decide said person should not be a committer. Hence > > surprise that this is prompting calls for reeducation. > Some of the rhetoric on members@ was overly harsh. You're certainly not crazy. : o) > > > If the only question is "commitment" to the project, then you > shouldn't need to worry about people breaking things who have a commit > bit. People who are committed to the project won't break things on > purpose, and they'll quickly learn to not break things on access too. > That's part of the definition of commitment. > > > > I still find this wordplay more than anything. Being a committer and > > earning merit doesn't reduce to merely being 'committed'. If you > > define 'committed' as 'won't break things on purpose, etc' then it's > > circular. OK, how do we decide what constitutes evidence of committed, > > etc. But at the least I'd suggest that both are a valid POV within > > "The Apache Way" which we can discuss. > Some of that circularity is necessary. When you give people added karma for a project, you are guessing what they are going to do with it. You can't know claim that someone you give committership is actually going to merge PRs until they do it. You have to try and see. So the circularity is there for all of your potential committers. > > > We really shouldn't treat committer status like a reward. It's just a > permission: permission to participate more fully in the project. That > permission includes, but is not limited to the commit bit. We should be > thanking people who accept those permissions because it means they intend > to continue contributing to the project. > > > > You say it shouldn't be a reward, and I agree, although that ship has > > sailed. But you say it's more than getting commit access, it's being > > publicly honored and thanked and shown trust, which sounds like a > > reward? I honestly think we agree in most cases, as I often say that > > we should make X a committer to enfranchise and further encourage a > > pattern of contribution backed by good judgment. I accept it > > inevitably functions like recognition and that's useful, so, roll with > > it. > There is a misunderstanding here, based on a clumsy choice of words on my part. Let me try to rephrase. Committership is not a reward that the PMC gives to the individual contributor. Committership is a reward that the individual contributor gives to the PMC. > > The answer may be that "VIP" is a bad idea, and I'm not pushing for > > it. I tabled it as something that might further this very same end: > > early and easy official recognition, to show trust and encourage > > contribution. We're really debating how high/low the committer bar > > should be, and if it's 'low', this idea does very little. > For solving the early and easy recognition problem, I've heard about people just saying "thank you" or making a "contributor of the month" honor. That kind of recognition doesn't necessarily have to be in the form of a status. But again, committership is more than a commit bit. As an example, if you can make it easier for someone to attend ApacheCon who is doing good things for your project and is certain not to harm it, why wouldn't you do that? > > > I've seen this happen. Especially when merges start slowing down, > people either stop contributing altogether or just work from their own > fork. If you have enough "non-meriging" committers in your volunteer > "pipeline" you have a better chance of people stepping up and becoming > "merging" committers. And at very least you remove a roadblock to > participation when you make someone a committer. Otherwise, you could > accidentally doom your project to a lifespan equal to the volunteer burnout > cycle of your one most dedicated volunteer. Or accidentally couple it too > tightly to the economic interests of that person's employer. Either way, > you'll shorten your project's lifespan unnecessarily. And that would be a > shame, because Spark is a really awesome project. > > > > On this I entirely agree. It's a different debate, but one we've had a > > lot over time: while there are possibly risks in adding someone as a > > committer, there are risks in not doing so too. You might find others > > on the PMC diverge more from your position, and I don't think it's a > > secret that I think the PMC has been a little overly conservative. The > > debate is reasonable (and visible on private@), and in-bounds w.r.t. > > The Apache Way. It needs to evolve, but, is not broken. I actually > > think members@ would do well to hear more in-bounds but diverging > > opinions, from good-faith and smart people from a different project. > > There are real, subtle questions here. A few people have gotten pretty > > dismissive of the learned experience of some large, successful ASF > > projects. > I agree here. And I'm open to suggestions on how to help this conversation move. Best Regards, Myrle
