| [eclipse.org-planning-council] Standard Charter Revision for Eclipse Planning Council |
Bjorn, Planning Council,
Per Bjorn’s request, please see attached for the requested changes to the Eclipse standard charter which I assembled into a single proposed draft revision from the numerous email messages I sent previously (to Bjorn). While this document is html format, it is meant to be edited by MS Word to clearly see the proposed changes and explanations (Sri could facilitate this review is Word is not otherwise available).
Note, there are likely numerous other changes that we could make to clear up ambiguities (e.g., what happens to the voting rights of a Lead Committer when they take an extended leave – the project must continue, but their Component cannot proceed without them; lots of little dark corners like this still exists and we just do our best to interpret the intent). But, these included here are the most noticeable issues.
I forget now which of the older projects are still relying on customer charters, perhaps they have some specifics to add (although, I crafted the TPTP charter based on the best amalgamation of charters existing at the time – Eclipse, Tools, WTP, ? – so we should be pretty close). As well, some of the newer projects may have run into issues to clarify.
As stated previously, I expect that projects can independently decide whether they want to adopt standard charter revision v1.0 or v1.1, but it was my intent not to introduce any provisions which would hinder all projects to move forward to the cleaner v1.1 version. With these changes to the standard charter, we would adopt the standard charter for TPTP and do away with our original custom charter.
It would be nice to take a bulk approval request to the Board to approve a new standard charter revision and for the adoption thereof by all projects.
Sri, I’ve attached our proposed revised TPTP charter based on the proposed standard charter for reference (not changed since Jan’06 revision I previously sent for review).
<<TPTP Charter v1.1 - Draft.htm>>
<<Eclipse Standard Top-Level Charter v1_1 - DRAFT.htm>>
PS
Thanks,
Tyler Thessin | tyler.thessin@xxxxxxxxx
Director, Intel Performance Libraries Lab
Software & Solutions Group | Developer Products Division
Intel Corporation | www.intel.com/software/products
2111 NE 25th Ave, JF1-07, Hillsboro, OR 97124, (503) 712-8413
Title: Eclipse Standard Top-Level Charter v1.0
|
Eclipse Test &
Performance Tools Platform (TPTP) Project v1.1 Edit Legend:
·
Proposed additions
to either align with the standard charter where applicable or other
modifications to clean up areas not covered in the standard charter. ·
Changes needed to
align with the standard charter which are not
resolved.[TRT1] ·
Indicate sections
corresponding to highlighted section heading that will be removed from TPTP
charter and referenced in Standard Charter Example: “TPTP Summary of Changes: Following sections retained in TPTP charter: ·
Overview, ·
Requirements, Architecture, and Planning Groups: Changed
description of formation of *Gs from PMC Lead to PMC responsibility and removed
specific criteria for membership (leaving to PMC discretion and better
conforming to expectations for Committer groups). Following sections removed from TPTP charter and referenced
via Standard Charter: ·
Project Management Committee (this section to be replaced with
Standard Charter): Polish and some subtle tweaks to PMC responsibilities which
are consistent with the current operation of the TPTP PMC. Requested change of Standard Charter reference
from “companies” to “organizations” as the former generally implies for-profit
entities which too narrowly describe potential project contributors. Requested change of Standard Charter awkward
wording of Board approval requirement for Charter changes. Replaced “subsystem” with “component”
throughout based on guidance from EMO. ·
Roles (this section to be replaced with Standard
Charter): Polish ·
Users (this section to be replaced with Standard
Charter): Clarification of Users definition – consistent with TPTP practice. ·
Developers (this section to be replaced with Standard
Charter): Polish. ·
Committers (this section to be replaced with Standard
Charter): Replaced “subsystem” with “component” throughout based on guidance
from EMO. Polish. Requested change of Standard Charter to waive
minimum voting period for cases where all Committers have responded in a
shorter timeframe. Correction to our
earlier erroneous omission stating no negative votes for Committer approval – although
not consistent as stated in TPTP charter, consistent with TPTP practice. Also, restated minimum votes required for small
components, but consistent with TPTP practice.
Eliminated explicit FYI that Committers may be asked to participate in
AG – no issue as PMC can set expectation beyond, but compliant with, TPTP
charter. Added explicit expectation for
Committers to vote on relevant project/component discussions. Removed voting rules for committing changes –
moved to Development Process section.
Requested Standard Charter change references from “commit status” to “Committer
status” (“commit” is ambiguous, just CVS commit status or Committer status
which also include voting rights). ·
Projects (this section to be replaced with Standard
Charter): Changed requirement for discontinuing Projects to recommendation by
PMC approved by EMO (vs. “decision of the Board”). Removed list of TPTP Projects to remove need
for Board oversight of changes to Projects. ·
Project Organization (this section to be replaced with
Standard Charter): Added provision for splitting/merging Projects with EMO
confirmation of PMC recommendation. Replaced
“subsystem” with “component” throughout based on guidance from EMO. Added clarity of possible Committer rights
changing when Projects split/merge.
Requested Standard Charter change to indicate Committer, vs. Developer,
rights may change when Projects split/merged. ·
Infrastructure (this section to be replaced with Standard
Charter): Changed expectation for providing project infrastructure from PMC to
PMC working with EMO. Polish. ·
Development Process (this section to be replaced with Standard
Charter): Requested Standard Charter change to state PMC plus a majority of
Committers must approve plans vs. just the latter (which conflicts with TPTP
practice). PMC retains flexibility to
delegate its plan approval responsibility to PG or otherwise as
appropriate. Added requirement for
approval from majority of Committers is compliant with TPTP practice (although
not explicit currently). Added voting
rules for committing changes – moved from Committers section. Moved responsibility to Projects from PMC for
establishing test plans and appropriate levels of testing. Removed redundant statement indicating PMC
may define further development process guidelines. ·
Licensing (this section to be replaced with Standard
Charter): No changes. Following sections deleted from TPTP charter and not present
in Standard Charter: ·
Ports: Delete this section. Ports are generally just a
special case of typical Component creation and sufficiently covered as such. ·
Coordinated Release Cycles: Delete this section. PMC can otherwise set this expectation (no need for overly
restrictive language in the charter which may hinder currently unanticipated
future situations). Overview
Scope Project Management Committee The PMC is
The PMC has the following
responsibilities:
The PMC Lead is appointed
by the Board. The initial PMC In the unlikely event that
a member of the PMC becomes disruptive to the process or ceases to contribute
for an extended period, the member may be removed by unanimous vote of
remaining PMC members. PMC members may resign at any time by delivering notice
of their resignation to the PMC Lead. The PMC is responsible for
producing and maintaining the Project
Charter. Development activities must conform to
any rules or processes outlined in the Charter, so a change to The work of the PMC is
shared by the PMC members. All PMC members are expected to contribute actively.
In particular, PMC members are expected to take responsibility for overseeing
certain areas of work in the Project,
and reporting to the PMC on these areas. Because of the diversity amongst individual projects, PMC
members are not expected to maintain anything other than general currency with
projects outside their assigned technical areas. Active participation in the
user newsgroup Requirements Group
The Requirements Group will
accomplish its objectives by working closely with Architecture Group The PMC Lead will designate the The Architecture Group will
accomplish its objectives by working closely with the Project development teams, the PMC, and the Eclipse
Architecture Council. Planning Group The PMC Lead will designate
The Planning Group will
accomplish its objectives by working closely with Roles Users Developers Committers In order for a Developer to
become a Committer on a
particular Project overseen by the PMC, another Committer for the same
Project (or At times, Committers may Active participation in the
user newsgroup and the appropriate developer mailing lists is a responsibility
of all Committers, and is critical to the success of the Project. Committers are required
to monitor and contribute to the user newsgroup. Committers are required to
monitor the Committers are required to
track, participate in, and vote on, relevant discussions in their associated
Projects and components. There are three voting responses: +1 (yes), -1 (no, or
veto), and 0 (abstain).
Committers are responsible
for proactively reporting problems in the bug tracking system, and annotating
problem reports with status information, explanations, clarifications, or
requests for more information from the submitter. Committers are responsible
for updating problem reports when they have done work related to the problem. Projects When a new Project is
created, the PMC nominates a Project lead to act as the technical leader and
nominates the initial set of Committers for the Project, and these nominations
are approved by the EMO. Project leads are accountable to the PMC for the
success of their Project.
Project Organization
In cases where new Projects
are being created, either by splitting or by merging, the usual procedures as
set forth in this Charter are followed. In particular, developers [TRT11] will not necessarily have the same rights after an
organizational change that they enjoyed in the previous structure.
Infrastructure
The Development Process Each Project must identify,
and make available on its web site, the requirements and prioritizations it is
working against in the current release cycle. In addition, each Project must
post a release plan showing the date and content of the next major release,
including any major milestones, and must keep this plan up to date. The Committers of a Project or component decide which changes may be
committed to the master code base of a Project or component respectively. The
PMC defines the decision process, but that process must include the ability for
Committers to veto the change. The decision process employed may change with
the phase of development. Common decision processes include:
Vetoes must be followed by an explanation for the veto within 24 hours or
the veto becomes invalid. All votes are conducted via the developer mailing
list associated with the Project or component. Special rules may be established
by the PMC for Projects or components with fewer than three Committers. The master copy of the code
base must reside on the Project
web site where it is accessible to all users, developers and committers. Committers must check their
changes and new work into the master code base as promptly as possible (subject
to any check-in voting rules that may be in effect) in order to foster
collaboration among widely distributed groups and so that the latest work is
always available to everyone. The PMC is responsible for working with the Eclipse Foundation
to establish
All development technical
discussions are conducted using the development mailing lists. If discussions
are held offline, then a summary must be posted to the mailing list to keep the
other committers,
Licensing [TRT1]Comments [TRT2]“companies” may be viewed as too narrow a specification, i.e., “company” is usually associated with for-profit interests. We’ve previously used “organizations” in this context for broader applicability. Proposed Standard Charter adopt “organizations” [TRT3]“are” is ambiguous. “Changes are approved” implies already approved, whereas “must be approved” indicates a requirement to be completed. (proposed to change wording to “require approval” [TRT4]Eclipse Development Process uses the “subsystems” terminology. EMO previously guide to align with such. However, recent guidance is to align with “component” terminology. [TRT5]Proposed Standard Charter revision to state “that period shall be a minimum of one week or the actual time in which all applicable Committers submit their votes” [TRT6]No issue for TPTP to re-align with the minimum voting for cases where less than 3 committers. [TRT7]Likely ok to eliminate this provision to align with the Standard Charter – informational only- non-binding - as stated anyway. [TRT8]Ambiguous, should probably be changed in the Standard Charter – could be wrongly interpreted as removal of commit (or write) access, but not removal of voting rights. [TRT9]Ok to remove from Committer section – comparable provisions added to the Development Process section. [TRT10]Good to remove this from the charter so as not to unnecessarily restrict project creation/removal (i.e., if stated in charter, need Board approval for project changes, otherwise only EMO approval needed) [TRT11]Requested Standard Charter change to Committers, Developers don’t have rights impact by Project changes. [TRT12]Ok to delete this section – Ports are generally just a special case of typical new subsystem/component creation. [TRT13]Ok to delete this section – PMC can otherwise set this expectation (no need for overly restrictive language in the charter which may hinder currently unanticipated future situations). [TRT14]The plan approval requirement as stated in the Standard Charter directly contradicts our established practice whereby the PMC/PG are indicated as plan approvers. However, in reality, the plans put forth to the PMC/PG have Committer approval as the plans are build bottoms-up – Committers identify plan items to which they can commit, Project Leads consolidate and roll-up such in the plan proposal to the PMC/PG for ultimate approval. As such, removing the PMC/PG requirement to approve the plan would not cause an issue. However, removing the PMC ability to reject a plan eliminates the PMC’s authority to ensure the plan aligns with the charter, scope, etc. I have requested revision of the Standard Charter; if not accepted, we will need to override to state “must be approved by the PMC (which the PMC can delegate to the PG) and a majority of committers of the project.” [TRT15]This statement may not be needed – nothing else in the Charter precludes the stated expectation, and therefore is merely for explicit clarification. If deemed required, include in an override Development Process section that specifies, “in addition to the terms defined in the standard charter…” |
|
Eclipse Top Level Project Charter v1. This document defines standard terms for Eclipse Top Level Project Charters. It is intended that the Charters for Top Level Projects reference this document rather than inheriting by copy-and-paste[TRT2] . Overview
Scope Project Management Committee PMCs are expected to ensure that: · All Projects operate effectively by providing leadership to guide the Project's overall direction and by removing obstacles, solving problems, and resolving conflicts. · All Project plans, technical documents and reports are publicly available. · All Projects operate using open source rules of engagement: meritocracy, transparency, and open participation. These principles work together. In principle, anyone can participate in a Project. The PMC has the following responsibilities: · Providing the leadership and vision to guide the Project's overall direction in a manner consistent with the Eclipse Foundation Roadmap. · Providing assistance and support to the developers working on the Project by removing obstacles, solving problems, and resolving conflicts. · Ensuring that Project plans are produced, and presenting these plans to the EMO. · Working with the Eclipse Management Organization (the "EMO") to establish the processes and infrastructure needed for the project teams to be effective. · Recommending new Projects to the EMO. · Recommending the initial set of Project committers for each new Project overseen by the PMC, and establishing the procedures consistent with this Charter for voting in new committers. · Helping to ensure that the Projects overseen by the PMC have enough contributors, and working to fill vacancies in roles. · Producing "how to get involved" guidelines to help new potential contributors get started. · Coordinating relationships with other Eclipse Foundation Projects. ·
Facilitating code or other
donations by individuals or · Making recommendations to the Eclipse Foundation Board regarding contributions proposed under licenses other than the EPL. · Working with the EMO and Committers to ensure in-bound contributions are made in accordance with the Eclipse Foundation IP Policy. · Acting as a focal point for the community in representing the Projects it oversees. The PMC Lead is appointed by the Board. The initial PMC is selected by the PMC Lead. Thereafter, to become a member of the PMC, an individual must be nominated by another member of the PMC, and unanimously approved by all PMC members. In the unlikely event that a member of the PMC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by unanimous vote of remaining PMC members. PMC members may resign at any time by delivering notice of their resignation to the PMC Lead. The PMC is responsible for producing and maintaining the Project Charter.
Development activities must conform to any rules or processes outlined in the
Charter, so a change to these processes may necessitate a change to the
Charter. Changes to the Charter require approval [TRT4] The work of the PMC is shared by the PMC members. All PMC members are expected to contribute actively. In particular, PMC members are expected to take responsibility for overseeing certain areas of work in the Project, and reporting to the PMC on these areas. Because of the diversity amongst individual projects, PMC members are not expected to maintain anything other than general currency with projects outside their assigned technical areas. Active participation in the user newsgroups and the appropriate developer mailing lists is a responsibility of all PMC members, and is critical to the success of the Project. PMC members are required to monitor the main Project mailing list, and the developer mailing lists for all Projects and components they are overseeing. Roles Users Developers Committers In order for a Developer to become a Committer on a particular Project
overseen by the PMC, another Committer for the same Project (or component as
appropriate) can nominate that Developer or the Developer can ask to be
nominated. Once a Developer is nominated, the Committers for the Project (or
component) will vote for a PMC-designated voting period, and that period shall
be no less than one week or the actual time in which all applicable Committers submit
their votes[TRT5] . If there are at least 3 positive votes
and no negative votes within the voting period, the Developer is recommended to
the PMC for commit privileges. The PMC may waive the 3 vote minimum requirement
in exceptional cases (e.g., there are fewer than 3 active committers on the P At times, Committers may become inactive for a variety of reasons. The
decision making process of the Project relies on active committers who respond
to discussions and vote in a constructive and timely manner. The PMC is
responsible for ensuring the smooth operation of the Project. A Committer who
is disruptive, does not participate actively, or has been inactive for an
extended period may have his or her Committer [TRT8] Active participation in the user newsgroup and the appropriate developer mailing lists is a responsibility of all Committers, and is critical to the success of the Project. Committers are required to monitor and contribute to the user newsgroup. Committers are required to monitor the mailing lists associated with all Projects and components for which they have commit privileges. This is a condition of being granted commit rights to the Project or component. It is mandatory because committers must participate in votes (which in some cases require a certain minimum number of votes) and must respond to the mailing list in a timely fashion in order to facilitate the smooth operation of the Project. When a Committer is granted commit rights they will be added to the appropriate mailing lists. A Committer must not be unsubscribed from a developer mailing list unless their associated commit privileges are also revoked. Committers are required to track, participate in, and vote on, relevant discussions in their associated Projects and components. There are three voting responses: +1 (yes), -1 (no, or veto), and 0 (abstain). Committers are responsible for proactively reporting problems in the bug tracking system, and annotating problem reports with status information, explanations, clarifications, or requests for more information from the submitter. Committers are responsible for updating problem reports when they have done work related to the problem. Projects When a new Project is created, the PMC nominates a Project lead to act as the technical leader and nominates the initial set of Committers for the Project, and these nominations are approved by the EMO. Project leads are accountable to the PMC for the success of their Project. Project Organization If a Project wishes to divide into components, commit privileges are normally granted at the component level, and the committers for a given component vote on issues specific to that component. Components are established and discontinued by the PMC. When the PMC creates a component, it appoints a component lead to act as the technical leader and names the initial set of Committers for the component. The component lead is designated as a committer for the Project and represents the component in discussions and votes pertaining to the Project as a whole. Component committers do not participate in votes at the level of the Project as a whole, unless they are also the component lead. In cases where new Projects are being created, either by splitting or by
merging, the usual procedures as set forth in this Charter are followed. In
particular, Infrastructure · Bug Database - Bugzilla database for tracking bugs and feature requests. · Source Repository -- One or more CVS repositories containing all the software for the Projects. · Website - A website will contain information about the Project, including documentation, reports and papers, courseware, downloads of releases, and this Charter. · General Mailing List - Mailing list for discussions pertaining to the Project as a whole or that cross Projects. This mailing list is open to the public. · Project Mailing Lists - Mailing list for technical discussions related to the Project. This mailing list is open to the public. · Component Mailing Lists - Mailing list for technical discussions related to the component. This mailing list is open to the public. · Newsgroups - Newsgroups where users, developers, and committers can interact regarding general questions and issues about the project. The newsgroup is open to the public. The Development Process Each Project must identify, and make available on its web site, the requirements and prioritizations it is working against in the current release cycle. In addition, each Project must post a release plan showing the date and content of the next major release, including any major milestones, and must keep this plan up to date. The Committers of a Project or component decide which changes may be committed to the master code base of a Project or component respectively. The PMC defines the decision process, but that process must include the ability for Committers to veto the change. The decision process employed may change with the phase of development. Common decision processes include: · Retroactive - changes are proactively made by Committers but can be vetoed by a single Committer. · Proactive - for efficiency, some code changes from some contributors (e.g. feature additions, bug fixes) may be approved in advance, or approved in principle based on an outline of the work, in which case they may be committed first and changed as needed, with conflicts resolved by majority vote of the Committers of the Project or component, as applicable. · Three Positive - No code is committed with a vote; three +1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to approve a code change. Vetoes must be followed by an explanation for the veto within 24 hours or the veto becomes invalid. All votes are conducted via the developer mailing list associated with the Project or component. Special rules may be established by the PMC for Projects or components with fewer than three Committers. The master copy of the code base must reside on the Project web site where it is accessible to all users, developers and committers. Committers must check their changes and new work into the master code base as promptly as possible (subject to any check-in voting rules that may be in effect) in order to foster collaboration among widely distributed groups and so that the latest work is always available to everyone. The PMC is responsible for working with the Eclipse Foundation to establish a release engineering and build process to ensure that builds can be reliably produced on a regular and frequent basis from the master code base and made available for download from the Project web site. Builds in this context are intended to include not only code but also reports, documentation, and courseware. Each Project is responsible for establishing test plans and the level of testing appropriate for the Project. All development technical discussions are conducted using the development mailing lists. If discussions are held offline, then a summary must be posted to the mailing list to keep the other committers, and any other interested parties, informed. Licensing [TRT1]Proposed
draft for version 1.1 [TRT2]One other change the may be beneficial is for the
Standard Charter is to use provision/paragraph numbering scheme. While it
would be our intention to define a Standard Charter that is wholly acceptable
as-is to all Eclipse PMCs, we may encounter some
limited situations where PMCs desire to adopt the
Standard Charter, but delete, modify, override a particular provision and
providing paragraph/provision numbering scheme would ease this (e.g., in PMC
charter, “this section replaces Section 8(a) in the Standard Charter…”). [TRT3]“companies” may be viewed as too narrow a specification,
i.e., “company” is usually associated with for-profit interests. We’ve
previously used “organizations” in this context for broader applicability [TRT4]“are” is ambiguous. “are
approved” implies already approved, whereas “require approval” indicates a
requirement to be completed. [TRT5]Enable
streamlined approvals in cases where all applicable Committers vote quickly via
email, or perhaps while attending a conference call. [TRT6]“project”
should be changed to “project (or component)”. [TRT7]This was slightly
in conflict with the New Committer Process which states
requirements for completion of multiple forms/agreements (New Committer Request
by PMC, Member/Individual Committer Questionnaire, Individual Committer
Agreement, and/or Eclipse Committer Employer Consent Form). The
use of capitalized “New Committer agreements” implies a specifically named
agreement (named “New Committer” agreement, but Developers may need to execute
a questionnaire agreement and potentially a committer agreement document), and
their in an additional obligation on the PMC (“new committer request form”) and
potentially on the Developer’s employer (consent form). I
have two alternative proposed fixes: (1)
Expand the text to accurately state expectations, e.g.: “If the PMC also approves, and the PMC, Developer, and their
employer (if applicable) execute the appropriate new committer agreements
provided by the EMO….” (2)
Specifically reference the New Committer Process, e.g.: “If the PMC also approves, and the PMC, Developer, and their
employer (if applicable) execute the appropriate agreements specified in the Eclipse New Committer Process….” [TRT8]“commit” is ambiguous. Should probably be changed in
the Standard Charter – could be wrongly interpreted as removal of commit (or
write) access, but not removal of voting rights. (several
instances of “commit” throughout should also be changed) [TRT9]Removing a
Committer: The Eclipse
Development Process empowers the PMC to remove inactive Committers: 11. Committer Termination A Committer who is inactive or disruptive can have their
commit rights removed by the Project’s PMC in accordance with the Project’s
Charter. And
the Standard Charter definition of PMC responsibilities capitalizes on this: PMC Section: At times, Committers may become inactive
for a variety of reasons. The decision making process of the Project relies on active committers who respond to
discussions and votes in a constructive and timely manner. The PMC is
responsible for ensuring the smooth operation of the Project. A Committer who
is disruptive, does not participate actively, or has been inactive for an
extended period may have his or her Committer However,
these provisions may be in conflict with other processes and ambiguous on
important aspects of execution. (1)
There is concern that as stated, these provisions enable the PMC to effect
agreements that the Committer and potentially their employer have with the
EMO. A cleaner solution might call for
the PMC to recommend Committer termination to the EMO and the EMO to terminate
respective agreements and rights (essentially reversing the process of
establishing the Committer). (2)
Additionally, there is concern about expectations for notification and response
period for inactive Committers. My
simple view is that the respective Project/Component Lead and/or PMC makes
multiple attempts to contact an inactive Committer over the course of ~30 days
after which termination procedures may continue (unless the Committer previously
communicated special circumstances).
Also, Mike has concerns about the means of communication (e.g., using
private requests (requested) vs. using project public mailing list) and
response period (e.g., tying to The individual actually has no power over whether or not they
can continue to contribute, they are bound by their agreement with their
employer not to contribute as an individual and it's down to the company how
they are deployed. However, being a committer is a high-status activity, and to
avoid the company having problems with constructive dismissal it cannot
arbitrarily reduce an employee's status without reasonable consultation. This may not be the practice in the In other words, if the employee wishes to continue as a
committer they must be given a reasonable opportunity by the company to do so.
Until this consultation process is over neither the employee or the employer
are at liberty to respond to the PMC as to its outcome. (and
incidentally it is usual practice for this whole process to remain confidential
within line management, rather than being emailed to a public mailing list by a
non-related member of staff). So how long should the consultation period last? There are a couple of datapoints. In the I’m
not able to determine if there is any implicit relationship between removing
Committer rights and employer/employee relationships and labor laws. My inclination is no, but I’d like another
perspective. My
intention is to try and keep any solution to this issue as simple as
possible. And, Mike Norman, representing
a non-US company has specific perspectives and concerns related to PMC Section: …A Committer who is disruptive, does not participate
actively, or has been inactive for an extended period may have his or her Committer [TRT10]Reference to “Developers” should be
changed to “Committers”. Developers don’t have rights, Committers do, and
hence Project changes may impact Committers. [TRT11]For the case of approving plans,
this is not an issue, e.g., in TPTP, the PMC implicitly requires that plans put
forth be previously approved by the committers.
However, for the case of rejecting plans, this terms in the
Standard Charter conflicts with other requirements of the charter. E.g., the inability of the PMC to reject a
plan conflicts with the PMC responsibilities to ensure that the project(s) are
consistent with the Eclipse Roadmap, with the project charter, etc. E Existing
projects state the following terms for plan approvals: TPTP = PMC/PG Eclipse Platform, BIRT, Eclipse Tools = PMC plus a majority
of committers Technology = majority of committers WTP, DTP, DSDP = (via Standard Charter) majority of
committers |