On Wed, Oct 21, 2015 at 3:54 AM, jan i <[email protected]> wrote: > On 21 October 2015 at 10:36, Justin Mclean <[email protected]> > wrote: > >...
> We can of course vote any committer who make contributions into the PMC at >> a later date (assuming they accept). A few projects have no difference >> between committers and PMC members. On one project I asked to be on the >> initial committer list, was declined (as there were too many on the list >> already), but my contributions quickly made me a committer and a PPMC >> member. >> > >> I learned a hard lesson, that having PPMC == Committers can break a > community if not being careful (which we weren´t). Some people do a > wonderful job as committers, but act quite differently when they become > PPMC. > I can't speak to jan's position, but can offer my own: Committers are community members who can directly contribute, at will, without supervision (which I read as "lack of trust"). They get to make changes that they believe will contribute positively. (this trust issue is also why I push for CTR rather than RTC) (P)PMC members are those who define the overall direction and vision of the community and code/products. These two groups are different. More specifically, it takes a long time to discover whether a potential (P)PMC candidate *agrees* with the direction of the community. (if they disagree, that isn't a problem; they are free to fork and go their own way) ... but during that evaluation period, *denying* them committer status prevents forward progress of the codebase and the possibility of evaluating their alignment with the larger desires of the (P)PMC and community. Separating committer from (P)PMC provides a lower bar for accepting new contributors into the community, without danger of derailing the larger goals. I can talk for hours on this :-P ... ask/probe for further details as you wish. In short: separate committers from PPMC, and go with CTR (and definitely NOT Jira-based changeset/patches). Cheers, -g
