Hey Sean, On 2019/08/02 13:20:56, Sean Owen <sro...@apache.org> wrote: > Yes, there's an interesting idea that came up on members@: should > there be a status in Spark that doesn't include the commit bit or > additional 'rights', but is formally recognized by the PMC? An MVP, > VIP, Knight of the Apache Foo project. I don't think any other project > does this, but don't think it's _prohibited_. This could recognize > long-time contributors of any kind (code, docs, external) for whom > it's not yet right to make a committer. The point would be > recognition, because there's really nothing short of that the project > can formally do. I personally am not sure it adds enough to justify > the process, and may wade too deeply into controversies about whether > this is just extra gatekeeping vs something helpful.
Before adding an MVP status or the like, we should consider what kinds of effects you are trying to accomplish with it, and what other kinds of effects it might have. 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. * 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. If I missed something important, please let me know. 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. 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.) * 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.) * 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.) Many of these effects are just variants of "Conway's law". For those who haven't heard of it: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." — M. Conway, 1967 https://en.wikipedia.org/wiki/Conway%27s_law Best Regards, Myrle --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
