This document is now obsolete, with the refactoring of the WTP Top Level Project into finer grained projects. See bug 199112 WTP Refactoring Review
See also WTP Projects
"Component" is used in many ways, so for the purposes here, "Component Team", means those committers responsible for one or more components of code (and the corresponding components of bugzilla, cvs, etc).
Component Teams have the responsibility for coming up with the specific plans for their components (within the themes established by the PMC, and the scope of our charter). This includes all the "normal" duties of being a committer, providing JUnit tests, participating in test phases, monitoring bugzilla, and participating on newsgroups and mailing lists. The component team also has the right and responsibility to vote in new committers for their component. Note: When new committers are nominated, be sure to rememember to be explicit about which team they are being nominated for.
The component team lead (listed first in the lists below) has responsibility to not only lead the team, but also to represent them in documenting formal votes for release, changes to schedules, etc. where a WTP-wide vote is needed.
There are two "components" that have automatic membership for any committer in WTP: the website component and the releng component. When a committer first joins WTP by being voted in a committer to one component team, there's a certain amount of "formal" things that have to happen, papers signed, IDs given, etc. If that person is then later voted into another component, it's a much easier process, since the "WTP membership" has already been established, so its just a question of the component team member ship. Eventually, component team membership could translate into CVS access, but, since that can get to be hard to administer, we are in no rush to do that (since cvs is fully traceable, we know who changed what when, so there is no risk of someone changing something they shouldn't).
Note that in the tables below, where a feature is listed it means to stand for all the plugins in that feature, unless one of those plugins is listed elsewhere, in another table, individually.
Component Team that works on WST and JST Common component features
People | Code |
---|---|
|
|
Component Team that works on current WST and JST Server component features
People | Code |
---|---|
|
|
Component Team that works on WST datastools component features
People | Code |
---|---|
|
|
Component Team that works on Javascript Development Tools
People | Code |
---|---|
|
|
Component Team that works on WST and JST editors and related features
People | Code |
---|---|
|
|
Component Team that works on WST and JST Web Services
People | Code |
---|---|
|
|
Component Team that works on current WST and JST Project models, refactoring, etc.
People | Code |
---|---|
|
|
Component Team that works on JSF Tools and Web Page Designer
People | Code |
---|---|
|
|
Component Team that works on JST JEE and EJB
People | Code |
---|---|
|
|
Component Team that works on AJAX Tools
People | Code |
---|---|
|
|
Component Team that works on JPA Tools
People | Code |
---|---|
|
|
Everyone in an above Component Teams, will automatically be given read/write access to the CVS parts of the releng projects. But, there is sort of a core team that's expected to keep releng running, and also, if ever needed, will have the primary "vote" on decisions about the direction of releng, etc.
People | Code |
---|---|
|
|
Everyone in an above Component Teams, will automatically be given read/write access to the CVS parts of the website project. But, there are additional people that have write/read access to only the website project, since they've made enough contributions to be voted in for that specific area of work.
People | Code |
---|---|
|
|
Our WTP Project charter (as part of the Eclipse Standard Charter v1.0) allows the PMC to remove inactive committers.
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 commit status revoked by the PMC.
The purpose of this section is to be a bit more explicit and open about what "inactive" means as interpreted by our project. It will be considered to be effective retroactively when this policy is approved by the WTP PMC (circa May, 2007).
The measure of activity will operationally be CVS commits. Anyone who has not committed any code for 9 months or more will be considered inactive and subject to removal from the committer lists. There can be exceptions to this automatic removal, at the discretion of the PMC. There may be valid reasons why someone has not made CVS commits, but are still quite active in the project, perhaps through design or planning documents, bug triage, newsgroup activity, etc. But for these activities to happen without also some CVS commit is thought to be the exception to the rule, so the CVS commit rule is expected to be accurate enough to operationally spot people who are not active. And, just to cover the "fine print", this CVS rule is not blind or absolute; for example, if someone is observed to be checking in only formatting changes or something every few months solely to avoid hitting the 9 month limit, then they will still be considered inactive.
Anyone who thinks they have mistakenly been removed can write to the PMC and if the PMC agrees it was a mistake they can be re-instated without a new committer vote.
This policy is not meant to substitute or override any other policies or procedures. For example, if a committer changes jobs, or whatever, and know they will no longer be able to particpate in WTP, then it's still preferred that they proactively notify WTP and the EMO that they will no longer be a committer, rather than to passively wait for the 9 month rule to take effect.