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. > * 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. - 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 ... 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. > 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. 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. > * People doing these kinds of work may view the default location to do that > work as being somewhere other than the spark code repositories, even if the > code repository would be a better choice. (For example, if a tutorial is > kept in the code repository, coding examples will automatically show compile > errors when there are breaking changes in an API. But if documentation > writers are told, implicitly, not to work in code repositories, the > possibility of keeping code examples in the repository may never be > considered.) Spark should have docs, quickstarts, examples. It already does in the repo and people can and do contribute to them. So, I would agree this is a risk if the project wasn't welcoming examples, docs, etc. But that's not the position here nor reality -- I merge doc changes all the time. Therefore I don't perceive this as related to whether or not there's a VIP status. It would be a problem with not caring about docs, full stop. > * 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. --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
