On Sep 27, 2016 10:44 AM, "Gregory Chase" <gch...@pivotal.io> wrote: > > Having been through this with Apache Geode, I like the idea of paying > homage to emeritus committers in the proposal and history of the > technology. If you start with a rule of providing committer privileges to > those who have directly committed to the project in the last two or three > years, and a liberal policy of granting new committer privileges as needed, > I think you should be ok. Does an emeritus committer need commit > privileges today? Only if they start committing again. > > And for those that want prestige - the prestige rests in being an active > evangelist of the project. One does not ever need to be a committer to > achieve prestige. >
I agree with Gregory's POV on this. It is open and easy to do. His email could be the reference for how it should work IMO. I will add my POV The list is a tribute and a starting point for where the project "is" when it comes to Apache. If it is already OSS, then why new merit? It came with merit and that should continue; it isn't a vacuum. Otherwise it is exclusive of merit. If not previously OSS, then the donators best know who did what or who will initially carry on unless the intent is to no longer be heavily involved in the project. Obviously the project now has to operate for the ASF community, but a project needs those who know it one way or another. If new people want in, let them show a little effort for code, and in, as long as they can write good bug free code with tests. If they want status, without coding, then evangelism and users both are always needed. Stating the obvious, but we need coders, users, and evangelism to have a successful project and community, and that seems common in OSS and commercial alike. For OSS, we should be as open and inclusive as possible; it's voluntary after all. The bar for merit should match. Obviously if someone is doing anything malicious, ever, they are gone. I think the issue this thread is trying to address is a lack of protocol. A protocol can be simple and open as long as it states the rules and intent, and is the thing which everyone defers. Perhaps that needs clarified in the incubator process documents or better followed if there. There should not be varying opinions when it comes time to onboard a new project. If ever in need of change and review, then OK, processes can handle that. Lacking a protocol, or if folks don't want one, then it should be completely up to the mentors and sponsor to spell out what to do for their podling. Otherwise you have various opportunity for contention with no framework or fact, but subjective opinions of everyone involved even if informed by experience. But, even that is managed to a degree by some protocol in the mentor process. Thanks Wade
