Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [technology-pmc] Formalizing some practices

> ===Setting Policies and Practices===
> All new policies and practices, and changes to existing policies and 
> practices, are discussed and voted upon in the Technology PMC's 
> mailing list. A simple majority of all active PMC members is required 
> to implement new policies and practices.

Does this still allow a strong veto (-1)?

> ===Changing a Project Lead===
> Ultimately, the Technology PMC can, at its own discretion, change the 
> leadership of a Technology project. However, whenever possible, such 
> action will only be undertaken following a vote (simple majority) from 
> the project's committers. Any negative votes (-1) must be resolved to 
> the PMC's satisfaction.

I'm not a native English speaker. Thus, I might be wrong. But to me this
reads like the Tech PMC can change a project leader without such a change
being requested by the project. Should that be possible?

[kosta] It would be good to describe the rationale and some cases when the
PMC would take such a drastic action. We don't want to make projects nervous
over this.

> ===Electing Committers===
> The Eclipse Development process allows a project to set its own 
> criteria for electing new committers. The Technology PMC requires that 
> all committer nominations include specific rationalization of the 
> merit of the individual. At a minimum, we expect that all committer 
> nominations include a list of at least three bugs (including ids) that 
> the candidate has worked on.

If we quantify the number bugs we should define some more numbers. For
example, the bugs should be spread across a reasonable time frame and not
relate to the same single piece of code. Well, I guess you get the idea.
It's not ok to point to three bugs all filed the same day before the
nomination.

[kosta] I am ok with specifying a minimum number of contributed patches and
a minimum timeframe, but we have to be careful about restricting cases where
all contribution relate to the same functional area. Most committers will
focus on one particular functional area. We also don't want to put
obstancles in the way of someone wanting to contribute a new chunk of
functionality to the project and become a committer so that they can
maintain that functionality. That's a fairly typical way to draw in new
committers and we should let the projects be the judge of whether that
particular individual is going to be a good team player or stay in their
sandbox to detriment of everything else.



Back to the top