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. > > > > 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. > > > > 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. > > 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. > > > > 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. > > > > 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. > > 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. > > > > 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.
--------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
