project/charter.html - www.eclipse.org/birt - Git at Google

 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 <html>
 <head>
 <title>BIRT Project Charter</title>
 <link rel="stylesheet" href="../style/compose.css"/>
 </head>
 <body>
 <p class="head">The Business Intelligence &amp; Reporting Tools Project Charter</p>

 <h1>Overview</h1>

 The Eclipse Business Intelligence &amp; Reporting Tools Top-Level Project
 is an open source collaborative software development project dedicated
 to providing an extensible, standards-based platform to address a broad
 range of needs in the business intelligence and reporting space using
 the Eclipse platform.
 <p>
 This document describes the composition and organization of the project,
 roles and responsibilities of the participants, and development process
 for the project.

 <h1>Mission</h1>


 The mission of The Business Intelligence and Reporting Tools Project is
 to create a wide variety of capabilities that allow developers to easily
 extract data from data sources, process that data using flexible and powerful
 data manipulation, sorting and aggregation, and present the processed
 information in a formatted layout to the end users.
 <p>
 The capabilities can range from application- and production-level reporting,
 through ad hoc user-driven query tools, to highly interactive multi-dimensional
 online analytical processing (OLAP) and data mining tools.
 <p>
 Some level of reporting is a common requirement in the majority of applications
 developed today - this project provides a focal point for the creation
 of best-of-breed business intelligence and reporting capabilities for
 integration into these applications, or as dedicated applications in their
 own right.

 <h1>Scope</h1>

 The Business Intelligence and Reporting Tools Project encompasses capabilities
 for designing and deploying business intelligence and reporting solutions
 that will be used within an application. The can broadly be divided into
 two categories: design tools for authoring, for example, reports; and
 deployment capabilities for utilizing these designs within an application.
 <p>
 Initially, the Project will focus on leveraging the Eclipse platform to
 provide infrastructure and tools for the designing, deploying, generating
 and viewing of reports in an organization, including ad hoc query and
 reporting tools. While not an initial focus, the BIRT project scope includes
 complementing these reporting capabilities with Online Analytical Processing
 (OLAP) and Business Intelligence dashboard functionality. Over time, but
 not in the initial scope, the creation of additional projects is anticipated
 and encouraged to address additional aspects of business intelligence,
 such as Executive Information Systems (EIS), statistical analysis, modeling
 capabilities (what-if analysis), Data Mining Tools, Data Warehouse Modeling
 Tools, Extract Transform and Load (ETL) tools and Data Quality Tools.
 <p>
 It is recognized that BIRT cannot meet all the requirements of all applications
 and tools that use BIRT. It is therefore a core design principle for all
 projects within BIRT to support a broad range of extension points within
 the tools and frameworks that allow developers to address additional needs,
 and to provide exemplary implementations for these extension points.
 <p>
 The list of the Projects under the Business Intelligence and Tools PMC
 will be maintained as part of <a href="index.php" target="_top">Business
 Intelligence and Reporting Tools Project</a>.
 </p>

 <h1>Project Management Committee</h1>

 The Projects under this Charter are managed by a group known as the Project
 Management Committee (the &quot;PMC&quot;).
 <p>
 PMCs are expected to ensure that:

 <ul>
 <li>All Projects operate effectively by providing leadership to guide
   the Project's overall direction and by removing obstacles, solving problems,
   and resolving conflicts. </li>

 <li>All Project plans, technical documents and reports are publicly available.
 </li>

 <li>All Projects operate using open source rules of engagement: meritocracy,
   transparency, and open participation. These principles work together.
   Anyone can participate in a Project. This open interaction, from answering
   questions to reporting bugs to making code contributions to creating
   designs, enables everyone to recognize and utilize the contributions.
 </li>

   </ul>

   <p>The PMC has the following responsibilities: </p>

   <ul>
 <li>Providing the leadership and vision to guide the Project's overall
   direction in a manner consistent with the Eclipse Foundation Architectural
   Roadmap. </li>

 <li>Providing assistance and support to the developers and researchers
   working on the Project by removing obstacles, solving problems, and
   resolving conflicts. </li>

 <li>Ensuring that Project plans are produced. </li>

 <li>Working with the Eclipse Management Organization (the &quot;EMO&quot;)
   to establish the development processes and infrastructure needed for
   the development team to be effective. </li>

 <li>Recommending new Projects to the EMO. </li>

 <li>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. </li>

 <li>Helping to ensure that the Projects overseen by the PMC have enough
   contributors, and working to fill vacancies in roles. </li>

 <li>Producing &quot;how to get involved&quot; guidelines to help new potential
   contributors get started. </li>

 <li>Coordinating relationships with other Eclipse Foundation Projects.
 </li>

 <li>Facilitating code or other donations by individuals or companies.
 </li>

 <li>Making recommendations to the Eclipse Foundation Board regarding contributions
   proposed under licenses other than the EPL. </li>

 <li>Working with the EMO and Committers to ensure in-bound contributions
   are made in accordance with the Eclipse Foundation IP Policy. </li>

 <li>Acting as a focal point for the community in representing the Projects
   it oversees. </li>

 </ul>

 <p>
 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.
 <p>
 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.
 <p>
 The PMC is responsible for producing and maintaining the Project Charter.
 Development must conform to any rules or processes outlined in the Charter,
 so a change to the development process may necessitate a change to the
 Charter. Changes to the Charter are approved by the Board.
 <p>
 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.
 <p>
 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.
 </p>

 <h1>Project Requirements Group</h1>

 The Requirements Group is formed at the discretion of the PMC. The Requirements
 Group gathers requirements for the project and communicates them to all
 members of the Project, including the PMC. The Requirements Group will
 accomplish its objectives by working closely with the development teams
 and the PMC.
 </p>

 <h1>Project Architecture Group</h1>

 The Architecture Group is formed at the discretion of the PMC. The Architecture
 Group is responsible for development, articulation and maintenance of
 the Project Architecture, as well as for providing an explicit description
 of the architecture and communicating this description to all members
 of the Project, and for releasing it as part of the project deliverables.
 The Architecture Group will accomplish its objectives by working closely
 with the development teams and the PMC.
 </p>

 <h1>Project Planning Group</h1>

 The Planning Group is formed at the discretion of the PMC. The Planning
 Group assists the PMC in establishing the Project plan in conjunction
 with available Project resources, coordinating relationships between Project
 participants and with other Eclipse projects. The Planning Group helps
 to ensure that projects have enough contributors, filling vacancies in
 roles and facilitating code or other donations by individuals or companies.
 The Planning Group will accomplish its objectives by working closely with
 the development teams and the PMC.
 </p>

 <h1>Roles</h1>

 The Projects under this Charter are operated as meritocracies -- the more
 you contribute, and the higher the quality of your contribution, the more
 you are allowed to do. However with this comes increased responsibility.
 <p>
 <dl>
 <dt>Users</dt>
 <dd>
 Users are the people who use the products that the Project produces. People
 in this role aren't contributing code, but they are using the products,
 reporting bugs, and making feature requests and suggestions. Users are
 encouraged to participate through the user newsgroup(s), asking questions,
 providing suggestions, and helping other users. Users are also encouraged
 to report problem reports using the bug tracking system. </dd>

 <dt>Developers</dt>
 <dd>
 Users who contribute code or documentation become developers. Developers
 are the people who contribute code, fixes, documentation, or other work
 that goes into the product. Developers are also encouraged to participate
 in the user newsgroup(s), and should monitor the developer mailing list
 associated with their area of contribution. When appropriate, developers
 may also contribute to development design discussions related to their
 area of contribution. Developers are expected to be proactive in reporting
 problems in the bug tracking system. </dd>

 <dt>Committers </dt>
 <dd>
 Developers who give frequent and valuable contributions to a Project,
 or component of a Project (in the case of large Projects), can have their
 status promoted to that of a &quot;Committer&quot; for that Project or
 component respectively. A Committer has write access to the source code
 repository for the associated Project (or component), and gains voting
 rights allowing them to affect the future of the Project (or component).
 </dd>
 </dl>
 <p>
 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. If there are at least 3 positive votes and no
 negative votes, the Developer is recommended to the PMC for commit privileges.
 If the PMC also approves and the Developer signs the Committer Agreement
 established by the EMO (wherein, at the very least, the Developer agrees
 to abide by the Eclipse Intellectual Property Policy), the Developer is
 converted into a Committer and given write access to the source code repository
 for that Project (or component). Becoming a Committer is a privilege that
 is earned by contributing and showing discipline and good judgment. It
 is a responsibility that should be neither given nor taken lightly.
 <p>
 At times, Committers may go 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
 that is disruptive, does not participate actively, or has been inactive
 for an extended period may have his or her commit status removed by the
 PMC.
 <p>
 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.
 <p>
 Committers are required to monitor the developer mailing list 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 removed.
 <p>
 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).
 <p>
 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.
 <p>
 <h1>Projects</h1>

 The work under this Top Level Project is further organized into Projects.
 New Projects must be significant works consistent with the mission of
 the Top Level Project, be recommended by the PMC, and confirmed by the
 EMO. Projects can be discontinued by decision of the Board.
 <p>
 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.
 </p>

 <h1>Project Components </h1>

 The PMC may decide to divide a Project further into components. If a Project
 is divided 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.
 </p>

 <h1>Ports</h1>

 For components that contain platform-specific code, it may be advantageous
 to allow developers to work on a port of the component to a new platform
 without requiring that they already be committers for the component. In
 this case the main code base is known as the component &quot;core&quot;,
 and the port code base is known as a component &quot;port&quot;. The decision
 to set up a port is made by the PMC. When a new port of a component is
 created, the PMC appoints a Port Lead, and an initial set of committers
 who will have commit and voting privileges specifically for the port.
 The port is done under the auspices of the core component, and all committers
 for the core component automatically also have commit and voting privileges
 on the port. Normally the Component Lead will also be the Port Lead.
 </p>

 <h1>Coordinated Release Cycles</h1>

 All projects and components under this Project will have coordinated release
 plans, milestone dates, freeze cycles, builds, and ship dates. These projects
 will be coordinated by a group consisting of the project leads, the component
 leads from these projects, and the members of the PMC assisted by the
 members of the Planning Committee.
 </p>

 <h1>Infrastructure</h1>

 The PMC works with the EMO to ensure the required infrastructure for the
 Project. The Project infrastructure will include, at minimum: <br>
 </p>

 <dl>
 <dt>Bug Database</dt>
 <dd>Bugzilla-like database for tracking bugs and feature
   requests. </dd>

 <dt>Source Repository</dt>
 <dd>One or more CVS repositories containing both the
   master source code and documentation for the projects. </dd>

 <dt>Website</dt>
 <dd>A Web site will contain information about the project, including
   documentation, downloads of releases, and this charter. </dd>

 <dt>General Mailing List</dt>
 <dd>Mailing list for development discussions pertaining
   to the project as a whole or that cross projects. This mailing list
   is open to the public. </dd>

 <dt>Project Mailing Lists</dt>
 <dd>Development mailing list for technical discussions
   and committer voting related to the project. These mailing lists are
   open to the public. </dd>

 <dt>Component Mailing Lists</dt>
 <dd>Development mailing list for technical discussions
   and committer voting related to the component. This mailing list is
   open to the public. </dd>

 <dt>Newsgroup</dt>
 <dd>A newsgroup where users, developers, and committers can
   interact regarding general questions and issues about the project. </dd>

 </dl>

 <h1>The Development Process </h1>

 Each Project lead must produce a development plan for the release cycle,
 and the development plan must be approved by the PMC and by a majority
 of Committers of the Project.
 <p>
 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.
 <p>
 The Committers of a Project or component decide which changes may be committed
 to the master code base of a Project or component respectively. 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.
 <p>
 Special rules may be established by the PMC for Projects or components
 with fewer than three Committers. 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. More restrictive rules for releasing changes
 may be established by the PMC near the end of release cycles or for maintenance
 streams.
 <p>
 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.
 <p>
 The PMC is responsible for establishing the level of testing appropriate
 for each Project, and approving the test plans.
 <p>
 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 informed.
 </p>

 <h1>Licensing</h1>

 All contributions to Projects under this Charter must adhere to the Eclipse
 Foundation Intellectual Property Policy. <br>
 </body>
 </html>
	<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
	<html>
	<head>
	<title>BIRT Project Charter</title>
	<link rel="stylesheet" href="../style/compose.css"/>
	</head>
	<body>
	<p class="head">The Business Intelligence & Reporting Tools Project Charter</p>

	<h1>Overview</h1>

	The Eclipse Business Intelligence & Reporting Tools Top-Level Project
	is an open source collaborative software development project dedicated
	to providing an extensible, standards-based platform to address a broad
	range of needs in the business intelligence and reporting space using
	the Eclipse platform.
	<p>
	This document describes the composition and organization of the project,
	roles and responsibilities of the participants, and development process
	for the project.

	<h1>Mission</h1>


	The mission of The Business Intelligence and Reporting Tools Project is
	to create a wide variety of capabilities that allow developers to easily
	extract data from data sources, process that data using flexible and powerful
	data manipulation, sorting and aggregation, and present the processed
	information in a formatted layout to the end users.
	<p>
	The capabilities can range from application- and production-level reporting,
	through ad hoc user-driven query tools, to highly interactive multi-dimensional
	online analytical processing (OLAP) and data mining tools.
	<p>
	Some level of reporting is a common requirement in the majority of applications
	developed today - this project provides a focal point for the creation
	of best-of-breed business intelligence and reporting capabilities for
	integration into these applications, or as dedicated applications in their
	own right.

	<h1>Scope</h1>

	The Business Intelligence and Reporting Tools Project encompasses capabilities
	for designing and deploying business intelligence and reporting solutions
	that will be used within an application. The can broadly be divided into
	two categories: design tools for authoring, for example, reports; and
	deployment capabilities for utilizing these designs within an application.
	<p>
	Initially, the Project will focus on leveraging the Eclipse platform to
	provide infrastructure and tools for the designing, deploying, generating
	and viewing of reports in an organization, including ad hoc query and
	reporting tools. While not an initial focus, the BIRT project scope includes
	complementing these reporting capabilities with Online Analytical Processing
	(OLAP) and Business Intelligence dashboard functionality. Over time, but
	not in the initial scope, the creation of additional projects is anticipated
	and encouraged to address additional aspects of business intelligence,
	such as Executive Information Systems (EIS), statistical analysis, modeling
	capabilities (what-if analysis), Data Mining Tools, Data Warehouse Modeling
	Tools, Extract Transform and Load (ETL) tools and Data Quality Tools.
	<p>
	It is recognized that BIRT cannot meet all the requirements of all applications
	and tools that use BIRT. It is therefore a core design principle for all
	projects within BIRT to support a broad range of extension points within
	the tools and frameworks that allow developers to address additional needs,
	and to provide exemplary implementations for these extension points.
	<p>
	The list of the Projects under the Business Intelligence and Tools PMC
	will be maintained as part of <a href="index.php" target="_top">Business
	Intelligence and Reporting Tools Project</a>.
	</p>

	<h1>Project Management Committee</h1>

	The Projects under this Charter are managed by a group known as the Project
	Management Committee (the "PMC").
	<p>
	PMCs are expected to ensure that:

	<ul>
	<li>All Projects operate effectively by providing leadership to guide
	the Project's overall direction and by removing obstacles, solving problems,
	and resolving conflicts. </li>

	<li>All Project plans, technical documents and reports are publicly available.
	</li>

	<li>All Projects operate using open source rules of engagement: meritocracy,
	transparency, and open participation. These principles work together.
	Anyone can participate in a Project. This open interaction, from answering
	questions to reporting bugs to making code contributions to creating
	designs, enables everyone to recognize and utilize the contributions.
	</li>

	</ul>

	<p>The PMC has the following responsibilities: </p>

	<ul>
	<li>Providing the leadership and vision to guide the Project's overall
	direction in a manner consistent with the Eclipse Foundation Architectural
	Roadmap. </li>

	<li>Providing assistance and support to the developers and researchers
	working on the Project by removing obstacles, solving problems, and
	resolving conflicts. </li>

	<li>Ensuring that Project plans are produced. </li>

	<li>Working with the Eclipse Management Organization (the "EMO")
	to establish the development processes and infrastructure needed for
	the development team to be effective. </li>

	<li>Recommending new Projects to the EMO. </li>

	<li>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. </li>

	<li>Helping to ensure that the Projects overseen by the PMC have enough
	contributors, and working to fill vacancies in roles. </li>

	<li>Producing "how to get involved" guidelines to help new potential
	contributors get started. </li>

	<li>Coordinating relationships with other Eclipse Foundation Projects.
	</li>

	<li>Facilitating code or other donations by individuals or companies.
	</li>

	<li>Making recommendations to the Eclipse Foundation Board regarding contributions
	proposed under licenses other than the EPL. </li>

	<li>Working with the EMO and Committers to ensure in-bound contributions
	are made in accordance with the Eclipse Foundation IP Policy. </li>

	<li>Acting as a focal point for the community in representing the Projects
	it oversees. </li>

	</ul>

	<p>
	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.
	<p>
	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.
	<p>
	The PMC is responsible for producing and maintaining the Project Charter.
	Development must conform to any rules or processes outlined in the Charter,
	so a change to the development process may necessitate a change to the
	Charter. Changes to the Charter are approved by the Board.
	<p>
	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.
	<p>
	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.
	</p>

	<h1>Project Requirements Group</h1>

	The Requirements Group is formed at the discretion of the PMC. The Requirements
	Group gathers requirements for the project and communicates them to all
	members of the Project, including the PMC. The Requirements Group will
	accomplish its objectives by working closely with the development teams
	and the PMC.
	</p>

	<h1>Project Architecture Group</h1>

	The Architecture Group is formed at the discretion of the PMC. The Architecture
	Group is responsible for development, articulation and maintenance of
	the Project Architecture, as well as for providing an explicit description
	of the architecture and communicating this description to all members
	of the Project, and for releasing it as part of the project deliverables.
	The Architecture Group will accomplish its objectives by working closely
	with the development teams and the PMC.
	</p>

	<h1>Project Planning Group</h1>

	The Planning Group is formed at the discretion of the PMC. The Planning
	Group assists the PMC in establishing the Project plan in conjunction
	with available Project resources, coordinating relationships between Project
	participants and with other Eclipse projects. The Planning Group helps
	to ensure that projects have enough contributors, filling vacancies in
	roles and facilitating code or other donations by individuals or companies.
	The Planning Group will accomplish its objectives by working closely with
	the development teams and the PMC.
	</p>

	<h1>Roles</h1>

	The Projects under this Charter are operated as meritocracies -- the more
	you contribute, and the higher the quality of your contribution, the more
	you are allowed to do. However with this comes increased responsibility.
	<p>
	<dl>
	<dt>Users</dt>
	<dd>
	Users are the people who use the products that the Project produces. People
	in this role aren't contributing code, but they are using the products,
	reporting bugs, and making feature requests and suggestions. Users are
	encouraged to participate through the user newsgroup(s), asking questions,
	providing suggestions, and helping other users. Users are also encouraged
	to report problem reports using the bug tracking system. </dd>

	<dt>Developers</dt>
	<dd>
	Users who contribute code or documentation become developers. Developers
	are the people who contribute code, fixes, documentation, or other work
	that goes into the product. Developers are also encouraged to participate
	in the user newsgroup(s), and should monitor the developer mailing list
	associated with their area of contribution. When appropriate, developers
	may also contribute to development design discussions related to their
	area of contribution. Developers are expected to be proactive in reporting
	problems in the bug tracking system. </dd>

	<dt>Committers </dt>
	<dd>
	Developers who give frequent and valuable contributions to a Project,
	or component of a Project (in the case of large Projects), can have their
	status promoted to that of a "Committer" for that Project or
	component respectively. A Committer has write access to the source code
	repository for the associated Project (or component), and gains voting
	rights allowing them to affect the future of the Project (or component).
	</dd>
	</dl>
	<p>
	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. If there are at least 3 positive votes and no
	negative votes, the Developer is recommended to the PMC for commit privileges.
	If the PMC also approves and the Developer signs the Committer Agreement
	established by the EMO (wherein, at the very least, the Developer agrees
	to abide by the Eclipse Intellectual Property Policy), the Developer is
	converted into a Committer and given write access to the source code repository
	for that Project (or component). Becoming a Committer is a privilege that
	is earned by contributing and showing discipline and good judgment. It
	is a responsibility that should be neither given nor taken lightly.
	<p>
	At times, Committers may go 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
	that is disruptive, does not participate actively, or has been inactive
	for an extended period may have his or her commit status removed by the
	PMC.
	<p>
	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.
	<p>
	Committers are required to monitor the developer mailing list 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 removed.
	<p>
	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).
	<p>
	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.
	<p>
	<h1>Projects</h1>

	The work under this Top Level Project is further organized into Projects.
	New Projects must be significant works consistent with the mission of
	the Top Level Project, be recommended by the PMC, and confirmed by the
	EMO. Projects can be discontinued by decision of the Board.
	<p>
	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.
	</p>

	<h1>Project Components </h1>

	The PMC may decide to divide a Project further into components. If a Project
	is divided 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.
	</p>

	<h1>Ports</h1>

	For components that contain platform-specific code, it may be advantageous
	to allow developers to work on a port of the component to a new platform
	without requiring that they already be committers for the component. In
	this case the main code base is known as the component "core",
	and the port code base is known as a component "port". The decision
	to set up a port is made by the PMC. When a new port of a component is
	created, the PMC appoints a Port Lead, and an initial set of committers
	who will have commit and voting privileges specifically for the port.
	The port is done under the auspices of the core component, and all committers
	for the core component automatically also have commit and voting privileges
	on the port. Normally the Component Lead will also be the Port Lead.
	</p>

	<h1>Coordinated Release Cycles</h1>

	All projects and components under this Project will have coordinated release
	plans, milestone dates, freeze cycles, builds, and ship dates. These projects
	will be coordinated by a group consisting of the project leads, the component
	leads from these projects, and the members of the PMC assisted by the
	members of the Planning Committee.
	</p>

	<h1>Infrastructure</h1>

	The PMC works with the EMO to ensure the required infrastructure for the
	Project. The Project infrastructure will include, at minimum: <br>
	</p>

	<dl>
	<dt>Bug Database</dt>
	<dd>Bugzilla-like database for tracking bugs and feature
	requests. </dd>

	<dt>Source Repository</dt>
	<dd>One or more CVS repositories containing both the
	master source code and documentation for the projects. </dd>

	<dt>Website</dt>
	<dd>A Web site will contain information about the project, including
	documentation, downloads of releases, and this charter. </dd>

	<dt>General Mailing List</dt>
	<dd>Mailing list for development discussions pertaining
	to the project as a whole or that cross projects. This mailing list
	is open to the public. </dd>

	<dt>Project Mailing Lists</dt>
	<dd>Development mailing list for technical discussions
	and committer voting related to the project. These mailing lists are
	open to the public. </dd>

	<dt>Component Mailing Lists</dt>
	<dd>Development mailing list for technical discussions
	and committer voting related to the component. This mailing list is
	open to the public. </dd>

	<dt>Newsgroup</dt>
	<dd>A newsgroup where users, developers, and committers can
	interact regarding general questions and issues about the project. </dd>

	</dl>

	<h1>The Development Process </h1>

	Each Project lead must produce a development plan for the release cycle,
	and the development plan must be approved by the PMC and by a majority
	of Committers of the Project.
	<p>
	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.
	<p>
	The Committers of a Project or component decide which changes may be committed
	to the master code base of a Project or component respectively. 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.
	<p>
	Special rules may be established by the PMC for Projects or components
	with fewer than three Committers. 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. More restrictive rules for releasing changes
	may be established by the PMC near the end of release cycles or for maintenance
	streams.
	<p>
	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.
	<p>
	The PMC is responsible for establishing the level of testing appropriate
	for each Project, and approving the test plans.
	<p>
	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 informed.
	</p>

	<h1>Licensing</h1>

	All contributions to Projects under this Charter must adhere to the Eclipse
	Foundation Intellectual Property Policy. <br>
	</body>
	</html>