On Sun, Aug 4, 2019 at 7:13 PM Sean Owen <sro...@apache.org> wrote: > On Sun, Aug 4, 2019 at 11:21 AM Myrle Krantz <my...@apache.org> wrote: > > Let me make a guess at what you are trying to accomplish with it. > Correct me please if I'm wrong: > > * You want to encourage contributions that aren't just code > contributions. You recognize for example that good documentation is > critical to bringing new contributors and committers to your project. You > recognize that other non-code contributions are also important to your > project's success. > > 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? > > > * You want to keep access to the code repositories "tight", ie minimized > to people who you view as likely to be actively using that access for the > goals of the project. In particular, someone who writes tutorials, may not > even want access to the spark code repositories. > > Yes, but in the narrow sense that someone with zero interaction with > the repo doesn't seem to need any repo access. That may actually be > uncontroversial? > > There are tougher question here which we've always grappled with: > - What about someone who's stopped contributing but did some good work > in the past? they probably won't use the commit bit or contribute. > Generally I think we've recognized 'past-only' merit with the commit > bit. > 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. 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. > - What about someone who's made a lot of code contributions but > doesn't review changes? have they demonstrated the skill that we need > people to deploy when they have the commit bit, which is knowing when > _others_ changes are OK to merge? Again I think we've only distantly > considered that, and there are committers who are almost entirely > contributors and not reviewers > This is really common in Apache projects. But even if they never merge anyone else's PR, giving them the commit bit reduces the load on those who do merge PR's for their *own* PRs. And increases the likelihood that they will eventually look at someone else's PR. If you're trying to recognize someone who reviews other people's PRs, maybe you're looking for an honor *in addition to* committer rather than instead of? > ... though I don't think we were questioning that here. (Maybe we should) > > > > Other arguments I've heard for this (which you may or may not share) > > * Fear of "diluting" the social value of committership in your project. > > I think the goal is to tease apart being a committer as having a > particular important power in the repo, and being a committer as > recognition and valuable social status. I don't think there's a worry > that too many committers dilute the 'brand'. On the contrary, I'd say > we _don't_ want mere recognition to be a factor in handing out this > access? Recognition ought to be more freely available, without > debating the effects of giving commit access. > 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. We've never teases these things apart at Apache because it simply hasn't been necessary. Just like in SVN there are (or were? I hope an SVN committer jumps in here) committers for certain areas of the code. Those areas of the code were only ever defined socially. And that never caused them problems for *years* of development. If n is the percent of code that an sub-module committer can touch, you can also imagine cases where n = 0%. And I think every project over a certain complexity *implicitly* has sub-module committers. People know about certain areas of the code and not about other areas of the code. They know to get their stuff reviewed when they're working with code they're less familiar with. > And here are some possible effects of creating a second category of > recognition for non-code contributions which does not include commit access: > > * things that aren't rewarded with committership are somehow viewed as > being of lesser value to the project. (It's already true in the industry > that documentation writers, marketers, and event-organizers are sometime > looked down on by programmers.) > > Agree, though, again, I don't think anyone is saying docs-only > contributors can't be committers here. > Really I just think it's unfortunate how much the commit bit is > considered a 'reward' - maybe that's the problem. > 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 hit on one of my concerns. In theory some "VIP" status is better > than nothing, but if it's viewed as second-class status more than > anything, it backfires. That is, does it become perceived as a badge > of "someone the PMC has definitely decided won't be a committer, > because they decided to hand out VIP status instead"? It could be > worse than having no status, which indicates nothing about a PMC > decision. > I hadn't even thought about the possibility of it being a case of "damned by faint praise". But you're right. That is a possible concern. > > > * People who want to work on spark may be more likely to chose to fork > your repository rather than work with it directly. > > * People who start off in other areas but have minor contributions to > make to your code may never make those contributions (for example someone > who does manual QA may never make that first step to automate manual work, > or improve existing automated tests. Documentation writers may never > bother to create that pull request on your grammar errors for your inline > documentation, so inline documentation may become a less-maintained second > class citizen.) > > Like, if not given the commit bit, they'll work only outside the repo? > I am not sure this is a risk? we're already talking about people who > contribute to Spark without being a committer. Would they stop if we > gave them VIP status but not the commit bit? (the risk there is as > above I think) > > Or is the idea that if one doesn't have the rights to merge one's own > changes rapidly, they'll stop? That's better solved by ensuring that > good patches get reviewed and merged quickly, which is a big, separate > problem. > 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. Best, Myrle (Sorry Sean, I accidentally sent this to just you first.)
