WTP PMC Policies
This page is to document some of the agreements, policies, and clarifications that come up from time to time in the WTP PMC, that are related to our PMC or project governance.
Eclipse has by-laws, and a development processes document that cover many aspects of governance in Eclipse. In addition, of course, we have Project Charter, which references the Eclipse Standard Charter, with some projects better described in a refactoring document.
This document is not to replace or contradict any of those documents. Those documents have authority if contradictions found.
But all those rules and regulations do not cover everything. In fact, in many cases, they say, in effect, "... it is up to the PMC to decide ...". So, in this document, we try and capture some of those decisions that effect our PMC policies and governance in the form of a FAQ.
How does one become a member of the PMC?
They are nominated by and voted in by the other PMC members. They are typically Project Leads, but do not have to be. One thing that sets them apart is they all have committed to (and usually have a vested interest in) seeing all of WTP succeed, not just their specific project. One manifestation of this is they agree to take on a role that spans all WTP project, such as planning, education, architecture, requirements, etc.
Can a PMC member vote on his own CQ or bug (when PMC review needed)
Yes. In WTP we have adopted that policy because we choose PMC members that have an overall view of WTP, and interest and commitment to seeing it succeed. Additionally, we choose members that are experienced and mature enough to be trusted that if something should be discussed, they would know that and bring it forward for discussion or clarification, before just blindly approving their own stuff. In some cases, PMC members do recuse themselves, and ask for votes from other members. But, its felt there are so many fairly trivial, obvious cases, that is speeds things up not to strictly always require forced review from all PMC members.