charter.html - gerrit/www.eclipse.org/mylyn - Git at Google

 <?xml version='1.0' encoding='utf-8' ?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 </head>
 <body>
 	<p>
 	<h1>Mylyn Charter</h1>
 	</p>
 	<p>
 	<h2>Contents</h2>
 	</p>
 	<ol style="list-style: none;">
 		<li><a href="#Overview">Overview</a></li>
 		<li><a href="#Mission">Mission</a></li>
 		<li><a href="#Scope">Scope</a>
 		<ol style="list-style: none;">
 				<li><a href="#Framework_Projects">Framework Projects</a></li>
 				<li><a href="#Tool_Projects">Tool Projects</a></li>
 				<li><a href="#Incubator_Projects">Incubator Projects</a></li>
 			</ol></li>
 		<li><a href="#Project_Management_Committee">Project
 				Management Committee</a></li>
 		<li><a href="#Roles">Roles</a>
 		<ol style="list-style: none;">
 				<li><a href="#Users">Users</a></li>
 				<li><a href="#Developers">Developers</a></li>
 				<li><a href="#Committers">Committers</a></li>
 			</ol></li>
 		<li><a href="#Projects">Projects</a></li>
 		<li><a href="#Project_Organization">Project Organization</a></li>
 		<li><a href="#Infrastructure">Infrastructure</a>
 		<ol style="list-style: none;">
 				<li><a href="#Bugzilla">Bugzilla</a></li>
 			</ol></li>
 		<li><a href="#The_Development_Process">The Development
 				Process</a></li>
 		<li><a href="#Licensing">Licensing</a></li>
 	</ol>
 	<h1 id="Overview">Overview</h1>
 	<p>
 		The <b>Mylyn Application Lifecycle Tools</b> 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 of accessing task and application lifecycle management
 		tools and services using the Eclipse platform.
 	</p>
 	<ul>
 		<li>Descriptive name: <b>Application Lifecycle Tools</b></li>
 		<li>Nickname: <b>Mylyn</b></li>
 	</ul>
 	<p>
 		For details on the structure of the project see the <b><a
 			href="https://wiki.eclipse.org/Mylyn/Restructuring">Restructuring</a></b>
 		document.
 	</p>
 	<h1 id="Mission">Mission</h1>
 	<p>The mission of the project is to provide:</p>
 	<ol>
 		<li>Frameworks and APIs for Eclipse-based task and Application
 			Lifecycle Management (ALM)</li>
 		<li>Exemplary tools for <a
 			href="http://en.wikipedia.org/wiki/Task-focused_interface">task-focused
 				programming</a> within the Eclipse IDE.
 		</li>
 		<li>Reference implementations for open source ALM tools used by
 			the Eclipse community and for open ALM standards such as <a
 			href="http://open-services.net">OSLC</a>
 		</li>
 	</ol>
 	<p>This document describes the composition and organization of the
 		project, roles and responsibilities of the participants, and
 		development process for the project.</p>
 	<h1 id="Scope">Scope</h1>
 	<ul>
 		<li><b>A task management tool for developers</b></li>
 		<li><b>The revolutionary task-focused interface</b></li>
 		<li><b>A broad ecosystem of Agile and ALM integrations</b></li>
 	</ul>
 	<h4 id="Framework_Projects">Framework Projects</h4>
 	<p>The project will initially be structured into the following
 		sub-projects, each representing an ALM category and providing common
 		APIs for specific ALM tools. The primary consumers of this project are
 		ALM ISVs and other adopters of Eclipse ALM frameworks.</p>
 	<ul>
 		<li><b>Tasks</b> - Integration with Agile, issue, bug and defect
 			tracking servers. The project provides rich task editing, task list
 			management and offline synchronization for ALM servers. Central
 			portion of the ALM integration framework used by other projects, eg,
 			task-based changed tracking for the SCM project.</li>
 		<li><b>Contexts</b> - Usage monitoring, degree-of-interested
 			modeling and the task-focused user extensions implementation for the
 			Eclipse UI, which re-aligns the user experience around tasks and
 			provides features such as workspace focusing and one-click
 			multitasking.</li>
 		<li><b>Versions</b> - Eclipse integration for source code and
 			configuration management tools(SCM, SCCM) and bi-directional linking
 			to change management tools. This project and APIs it provides builds
 			on the existing Eclipse "Team" APIs.</li>
 		<li><b>Builds</b> - Integration of continuous integration and
 			build systems and seamless access to software build and assembly
 			technologies. Mylyn users will be able to access continuous
 			integration processes, control build execution and associate build
 			results with tasks and context.</li>
 		<li><b>Reviews</b> - Eclipse-based code review functionality
 			that's seamlessly integrated with the Tasks and SCM systems supported
 			by Mylyn. Eclipse integration for Agile code reviews, the formal IEEE
 			code review process, review reports with BIRT and aim to support many
 			Eclipse artifact for reviews, e.g. JDT (Java files), CDT (C/C++
 			files), EMF (models).</li>
 		<li><b>Docs</b> - The scope of this project is Eclipse-based
 			access to documentation systems such as Wikis and other portals. This
 			builds on the Mylyn WikiText framework.</li>
 		<li><b>Commons</b> - The scope of this project is to provide a
 			framework of common UI, web service, REST and test utilities to be
 			used by the rest of Mylyn and by other Eclipse-based tools (see <a
 			href="https://wiki.eclipse.org/Mylyn_Integrator_Reference#Commons_API">Mylyn_Integrator_Reference#Commons_API</a>).</li>
 		<li><b>Incubator</b> - New development in areas that are relevant
 			to the other sub-projects.</li>
 	</ul>
 	<h4 id="Tool_Projects">Tool Projects</h4>
 	<p>
 		The primary consumers of the tool projects are developers using
 		Eclipse and wanting integration with their application lifecycle
 		tools. Each of these projects fits under a framework sub-project, but
 		typically will its own branding and user community, which builds on
 		the community defined by the corresponding ALM or application
 		development tool. While the number of tool projects will grow, the
 		goal is only to provide reference implementations, and not the
 		comprehensive set of open source and commercial integrations provided
 		by the <a href="https://wiki.eclipse.org/Mylyn/Extensions">Mylyn/Extensions</a>
 		ecosystem.
 	</p>
 	<ul>
 		<li>Tasks
 			<ul>
 				<li><b>Bugzilla Connector</b>: Mozilla Bugzilla bug tracker
 					integratoin</li>
 				<li><b>Trac Connector</b>: Trac ticket tracker integration</li>
 			</ul>
 		</li>
 		<li>Context
 			<ul>
 				<li><b>Java Bridge</b>: Context management for Java development
 					with JDT</li>
 				<li><b>C/C++ Bridge</b>: Context management for C/C++
 					development with CDT</li>
 			</ul>
 		</li>
 		<li>Versions
 			<ul>
 				<li><b>EGit</b>: the new top-level project is proposed as a new
 					home for EGit/JGit</li>
 				<li><b>CVS Connector</b>: Task-based change set management for
 					CVS, depends on team.cvs</li>
 			</ul>
 		</li>
 		<li>Builds
 			<ul>
 				<li><b>Hudson Connector</b>: Continuous integration access for
 					Hudson</li>
 			</ul>
 		</li>
 		<li>Reviews
 			<ul>
 				<li><b>R4E</b>: The reviews tool leverages the above
 					integrations, and does not require a separate server integration,
 					just a compatible Tasks and SCM integration</li>
 				<li><b>Task-based Reviews</b>: Lightweight code reviews shared
 					through task repositories</li>
 				<li><b>Gerrit Connector</b>: Gerrit code review integration for
 					Git repositories</li>
 			</ul>
 		</li>
 		<li>Docs
 			<ul>
 				<li><b>WikiText</b>: Wiki-based markup editing for popular
 					dialects</li>
 				<li><b>RichText</b>: HTML/XHTML/RTF markup editing</li>
 			</ul>
 		</li>
 	</ul>
 	<h4 id="Incubator_Projects">Incubator Projects</h4>
 	<p>The Mylyn Incubator will focus on new development in areas that
 		are relevant to the other Mylyn Project sub-projects, which because of
 		their nature would not be appropriate for direct inclusion in the
 		effected sub-project. This could be because the work is still
 		experimental, will have a longer timeline than can be contained within
 		a single release, has dependencies on external IP that has not yet
 		cleared the Eclipse Foundation IP process, or is simply potentially
 		too destabilizing in nature.</p>
 	<ul>
 		<li><b>Incubator</b>: Trac Wiki Integration, UI Experiments, UI
 			Usage Reporting
 			<ul>
 				<li><b>Web Templates Connector</b></li>
 				<li><b>WikiText Sandbox</b></li>
 			</ul></li>
 	</ul>
 	<h1 id="Project_Management_Committee">Project Management Committee</h1>
 	<p>
 		The Projects under this Charter are managed by a group known as the
 		Project Management Committee (the "PMC"). The PMC's duties are
 		described in <a
 			href="http://www.eclipse.org/projects/dev_process/development_process.php#4_6_Leaders">"4.6
 			Leaders"</a> of the Eclipse Development Process.
 	</p>
 	<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.
 		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.</p>
 	<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 id="Roles">Roles</h1>
 	<p>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>
 	<h2 id="Users">Users</h2>
 	<p>Users are the people who use the output from the Project. Output
 		will typically consist of software in form of extensible frameworks
 		and exemplary tools. Software in this context means intellectual
 		property in electronic form, including source and binary code,
 		documentation, courseware, reports and whitepapers.</p>
 	<h2 id="Developers">Developers</h2>
 	<p>Users who contribute software, documentation, or other
 		materially useful content become developers. Developers are 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</p>
 	<h2 id="Committers">Committers</h2>
 	<p>
 		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. See <a
 			href="http://www.eclipse.org/projects/dev_process/development_process.php#4_7_Committers_and_Contributors">"4.7
 			Committers and Contributors"</a> of the Eclipse Development Process for
 		the process and responsibilities that entails.
 	</p>
 	<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 commit status revoked by the PMC.</p>
 	<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>
 	<p>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.</p>
 	<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>
 	<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 id="Projects">Projects</h1>
 	<p>The work under this Top Level Project is further organized into
 		Projects. New Projects must be consistent with the mission of the Top
 		Level Project, be recommended by the PMC, and confirmed by the EMO.
 		Projects can be discontinued by recommendation of the PMC, and
 		confirmed by the EMO.</p>
 	<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 id="Project_Organization">Project Organization</h1>
 	<p>Given the fluid nature of Eclipse Projects, organizational
 		changes are possible, in particular: dividing a Project into
 		components; dividing a Project into two or more independent Projects;
 		and merging two or more Projects into a single Project. In each case,
 		the initiative for the change may come either from within the Project
 		or from the PMC, but the PMC must approve any change, and approval
 		must be confirmed by the EMO.</p>
 	<p>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.</p>
 	<p>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 will not necessarily
 		have the same rights after an organizational change that they enjoyed
 		in the previous structure.</p>
 	<h1 id="Infrastructure">Infrastructure</h1>
 	<p>The PMC works with the EMO to ensure the required infrastructure
 		for the Project. The Project infrastructure will include, at minimum:</p>
 	<ul>
 		<li>Bug Database - Bugzilla database for tracking bugs and
 			feature requests.</li>
 		<li>Source Repository -- One or more source repositories
 			containing all the software for the Projects.</li>
 		<li>Website - A website will contain information about the
 			Project, including documentation, reports and papers, courseware,
 			downloads of releases, and this Charter.</li>
 		<li>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.</li>
 		<li>Project Mailing Lists - Mailing list for technical
 			discussions related to the Project. This mailing list is open to the
 			public.</li>
 		<li>Component Mailing Lists - Mailing list for technical
 			discussions related to the component. This mailing list is open to
 			the public.</li>
 		<li>Newsgroups - Newsgroups where users, developers, and
 			committers can interact regarding general questions and issues about
 			the project. The newsgroup is open to the public.</li>
 	</ul>
 	<h2 id="Bugzilla">Bugzilla</h2>
 	<p>Each framework project is represented as a component under the
 		Mylyn product, e.g. Mylyn/Tasks. Tools and incubator projects have
 		their own product that maybe prefixed with the top-level project name,
 		e.g. "Mylyn Bugzilla Connector". Tools and incubator projects may vote
 		on their own components.</p>
 	<h1 id="The_Development_Process">The Development Process</h1>
 	<p>Each Project lead must produce a development plan for the
 		release cycle, and the development plan must be approved by a majority
 		of Committers of the Project. The plan must be submitted to the PMC
 		for review. The PMC may provide feedback and advice on the plan but
 		approval rests with the Project Committers.</p>
 	<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>
 	<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. 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:</p>
 	<ul>
 		<li>Retroactive - changes are proactively made by Committers but
 			can be vetoed by a single Committer.</li>
 		<li>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.</li>
 		<li>Three Positive - No code is committed without a vote; three
 			+1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to
 			approve a code change.</li>
 	</ul>
 	<p>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.</p>
 	<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. Builds in this context are intended to include
 		not only code but also reports, documentation, and courseware.</p>
 	<p>Each Project is responsible for establishing test plans and the
 		level of testing appropriate for the Project.</p>
 	<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, and any other interested parties.</p>
 	<h1 id="Licensing">Licensing</h1>
 	<p>
 		All contributions to Projects under this Charter must adhere to the
 		Eclipse Foundation <a
 			href="http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf">Intellectual
 			Property Policy</a>.
 	</p>
 </body>
 </html>
	<?xml version='1.0' encoding='utf-8' ?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	</head>
	<body>
	<p>
	<h1>Mylyn Charter</h1>
	</p>
	<p>
	<h2>Contents</h2>
	</p>
	<ol style="list-style: none;">
	<li><a href="#Overview">Overview</a></li>
	<li><a href="#Mission">Mission</a></li>
	<li><a href="#Scope">Scope</a>
	<ol style="list-style: none;">
	<li><a href="#Framework_Projects">Framework Projects</a></li>
	<li><a href="#Tool_Projects">Tool Projects</a></li>
	<li><a href="#Incubator_Projects">Incubator Projects</a></li>
	</ol></li>
	<li><a href="#Project_Management_Committee">Project
	Management Committee</a></li>
	<li><a href="#Roles">Roles</a>
	<ol style="list-style: none;">
	<li><a href="#Users">Users</a></li>
	<li><a href="#Developers">Developers</a></li>
	<li><a href="#Committers">Committers</a></li>
	</ol></li>
	<li><a href="#Projects">Projects</a></li>
	<li><a href="#Project_Organization">Project Organization</a></li>
	<li><a href="#Infrastructure">Infrastructure</a>
	<ol style="list-style: none;">
	<li><a href="#Bugzilla">Bugzilla</a></li>
	</ol></li>
	<li><a href="#The_Development_Process">The Development
	Process</a></li>
	<li><a href="#Licensing">Licensing</a></li>
	</ol>
	<h1 id="Overview">Overview</h1>
	<p>
	The <b>Mylyn Application Lifecycle Tools</b> 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 of accessing task and application lifecycle management
	tools and services using the Eclipse platform.
	</p>
	<ul>
	<li>Descriptive name: <b>Application Lifecycle Tools</b></li>
	<li>Nickname: <b>Mylyn</b></li>
	</ul>
	<p>
	For details on the structure of the project see the <b><a
	href="https://wiki.eclipse.org/Mylyn/Restructuring">Restructuring</a></b>
	document.
	</p>
	<h1 id="Mission">Mission</h1>
	<p>The mission of the project is to provide:</p>
	<ol>
	<li>Frameworks and APIs for Eclipse-based task and Application
	Lifecycle Management (ALM)</li>
	<li>Exemplary tools for <a
	href="http://en.wikipedia.org/wiki/Task-focused_interface">task-focused
	programming</a> within the Eclipse IDE.
	</li>
	<li>Reference implementations for open source ALM tools used by
	the Eclipse community and for open ALM standards such as <a
	href="http://open-services.net">OSLC</a>
	</li>
	</ol>
	<p>This document describes the composition and organization of the
	project, roles and responsibilities of the participants, and
	development process for the project.</p>
	<h1 id="Scope">Scope</h1>
	<ul>
	<li><b>A task management tool for developers</b></li>
	<li><b>The revolutionary task-focused interface</b></li>
	<li><b>A broad ecosystem of Agile and ALM integrations</b></li>
	</ul>
	<h4 id="Framework_Projects">Framework Projects</h4>
	<p>The project will initially be structured into the following
	sub-projects, each representing an ALM category and providing common
	APIs for specific ALM tools. The primary consumers of this project are
	ALM ISVs and other adopters of Eclipse ALM frameworks.</p>
	<ul>
	<li><b>Tasks</b> - Integration with Agile, issue, bug and defect
	tracking servers. The project provides rich task editing, task list
	management and offline synchronization for ALM servers. Central
	portion of the ALM integration framework used by other projects, eg,
	task-based changed tracking for the SCM project.</li>
	<li><b>Contexts</b> - Usage monitoring, degree-of-interested
	modeling and the task-focused user extensions implementation for the
	Eclipse UI, which re-aligns the user experience around tasks and
	provides features such as workspace focusing and one-click
	multitasking.</li>
	<li><b>Versions</b> - Eclipse integration for source code and
	configuration management tools(SCM, SCCM) and bi-directional linking
	to change management tools. This project and APIs it provides builds
	on the existing Eclipse "Team" APIs.</li>
	<li><b>Builds</b> - Integration of continuous integration and
	build systems and seamless access to software build and assembly
	technologies. Mylyn users will be able to access continuous
	integration processes, control build execution and associate build
	results with tasks and context.</li>
	<li><b>Reviews</b> - Eclipse-based code review functionality
	that's seamlessly integrated with the Tasks and SCM systems supported
	by Mylyn. Eclipse integration for Agile code reviews, the formal IEEE
	code review process, review reports with BIRT and aim to support many
	Eclipse artifact for reviews, e.g. JDT (Java files), CDT (C/C++
	files), EMF (models).</li>
	<li><b>Docs</b> - The scope of this project is Eclipse-based
	access to documentation systems such as Wikis and other portals. This
	builds on the Mylyn WikiText framework.</li>
	<li><b>Commons</b> - The scope of this project is to provide a
	framework of common UI, web service, REST and test utilities to be
	used by the rest of Mylyn and by other Eclipse-based tools (see <a
	href="https://wiki.eclipse.org/Mylyn_Integrator_Reference#Commons_API">Mylyn_Integrator_Reference#Commons_API</a>).</li>
	<li><b>Incubator</b> - New development in areas that are relevant
	to the other sub-projects.</li>
	</ul>
	<h4 id="Tool_Projects">Tool Projects</h4>
	<p>
	The primary consumers of the tool projects are developers using
	Eclipse and wanting integration with their application lifecycle
	tools. Each of these projects fits under a framework sub-project, but
	typically will its own branding and user community, which builds on
	the community defined by the corresponding ALM or application
	development tool. While the number of tool projects will grow, the
	goal is only to provide reference implementations, and not the
	comprehensive set of open source and commercial integrations provided
	by the <a href="https://wiki.eclipse.org/Mylyn/Extensions">Mylyn/Extensions</a>
	ecosystem.
	</p>
	<ul>
	<li>Tasks
	<ul>
	<li><b>Bugzilla Connector</b>: Mozilla Bugzilla bug tracker
	integratoin</li>
	<li><b>Trac Connector</b>: Trac ticket tracker integration</li>
	</ul>
	</li>
	<li>Context
	<ul>
	<li><b>Java Bridge</b>: Context management for Java development
	with JDT</li>
	<li><b>C/C++ Bridge</b>: Context management for C/C++
	development with CDT</li>
	</ul>
	</li>
	<li>Versions
	<ul>
	<li><b>EGit</b>: the new top-level project is proposed as a new
	home for EGit/JGit</li>
	<li><b>CVS Connector</b>: Task-based change set management for
	CVS, depends on team.cvs</li>
	</ul>
	</li>
	<li>Builds
	<ul>
	<li><b>Hudson Connector</b>: Continuous integration access for
	Hudson</li>
	</ul>
	</li>
	<li>Reviews
	<ul>
	<li><b>R4E</b>: The reviews tool leverages the above
	integrations, and does not require a separate server integration,
	just a compatible Tasks and SCM integration</li>
	<li><b>Task-based Reviews</b>: Lightweight code reviews shared
	through task repositories</li>
	<li><b>Gerrit Connector</b>: Gerrit code review integration for
	Git repositories</li>
	</ul>
	</li>
	<li>Docs
	<ul>
	<li><b>WikiText</b>: Wiki-based markup editing for popular
	dialects</li>
	<li><b>RichText</b>: HTML/XHTML/RTF markup editing</li>
	</ul>
	</li>
	</ul>
	<h4 id="Incubator_Projects">Incubator Projects</h4>
	<p>The Mylyn Incubator will focus on new development in areas that
	are relevant to the other Mylyn Project sub-projects, which because of
	their nature would not be appropriate for direct inclusion in the
	effected sub-project. This could be because the work is still
	experimental, will have a longer timeline than can be contained within
	a single release, has dependencies on external IP that has not yet
	cleared the Eclipse Foundation IP process, or is simply potentially
	too destabilizing in nature.</p>
	<ul>
	<li><b>Incubator</b>: Trac Wiki Integration, UI Experiments, UI
	Usage Reporting
	<ul>
	<li><b>Web Templates Connector</b></li>
	<li><b>WikiText Sandbox</b></li>
	</ul></li>
	</ul>
	<h1 id="Project_Management_Committee">Project Management Committee</h1>
	<p>
	The Projects under this Charter are managed by a group known as the
	Project Management Committee (the "PMC"). The PMC's duties are
	described in <a
	href="http://www.eclipse.org/projects/dev_process/development_process.php#4_6_Leaders">"4.6
	Leaders"</a> of the Eclipse Development Process.
	</p>
	<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.
	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.</p>
	<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 id="Roles">Roles</h1>
	<p>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>
	<h2 id="Users">Users</h2>
	<p>Users are the people who use the output from the Project. Output
	will typically consist of software in form of extensible frameworks
	and exemplary tools. Software in this context means intellectual
	property in electronic form, including source and binary code,
	documentation, courseware, reports and whitepapers.</p>
	<h2 id="Developers">Developers</h2>
	<p>Users who contribute software, documentation, or other
	materially useful content become developers. Developers are 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</p>
	<h2 id="Committers">Committers</h2>
	<p>
	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. See <a
	href="http://www.eclipse.org/projects/dev_process/development_process.php#4_7_Committers_and_Contributors">"4.7
	Committers and Contributors"</a> of the Eclipse Development Process for
	the process and responsibilities that entails.
	</p>
	<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 commit status revoked by the PMC.</p>
	<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>
	<p>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.</p>
	<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>
	<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 id="Projects">Projects</h1>
	<p>The work under this Top Level Project is further organized into
	Projects. New Projects must be consistent with the mission of the Top
	Level Project, be recommended by the PMC, and confirmed by the EMO.
	Projects can be discontinued by recommendation of the PMC, and
	confirmed by the EMO.</p>
	<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 id="Project_Organization">Project Organization</h1>
	<p>Given the fluid nature of Eclipse Projects, organizational
	changes are possible, in particular: dividing a Project into
	components; dividing a Project into two or more independent Projects;
	and merging two or more Projects into a single Project. In each case,
	the initiative for the change may come either from within the Project
	or from the PMC, but the PMC must approve any change, and approval
	must be confirmed by the EMO.</p>
	<p>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.</p>
	<p>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 will not necessarily
	have the same rights after an organizational change that they enjoyed
	in the previous structure.</p>
	<h1 id="Infrastructure">Infrastructure</h1>
	<p>The PMC works with the EMO to ensure the required infrastructure
	for the Project. The Project infrastructure will include, at minimum:</p>
	<ul>
	<li>Bug Database - Bugzilla database for tracking bugs and
	feature requests.</li>
	<li>Source Repository -- One or more source repositories
	containing all the software for the Projects.</li>
	<li>Website - A website will contain information about the
	Project, including documentation, reports and papers, courseware,
	downloads of releases, and this Charter.</li>
	<li>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.</li>
	<li>Project Mailing Lists - Mailing list for technical
	discussions related to the Project. This mailing list is open to the
	public.</li>
	<li>Component Mailing Lists - Mailing list for technical
	discussions related to the component. This mailing list is open to
	the public.</li>
	<li>Newsgroups - Newsgroups where users, developers, and
	committers can interact regarding general questions and issues about
	the project. The newsgroup is open to the public.</li>
	</ul>
	<h2 id="Bugzilla">Bugzilla</h2>
	<p>Each framework project is represented as a component under the
	Mylyn product, e.g. Mylyn/Tasks. Tools and incubator projects have
	their own product that maybe prefixed with the top-level project name,
	e.g. "Mylyn Bugzilla Connector". Tools and incubator projects may vote
	on their own components.</p>
	<h1 id="The_Development_Process">The Development Process</h1>
	<p>Each Project lead must produce a development plan for the
	release cycle, and the development plan must be approved by a majority
	of Committers of the Project. The plan must be submitted to the PMC
	for review. The PMC may provide feedback and advice on the plan but
	approval rests with the Project Committers.</p>
	<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>
	<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. 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:</p>
	<ul>
	<li>Retroactive - changes are proactively made by Committers but
	can be vetoed by a single Committer.</li>
	<li>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.</li>
	<li>Three Positive - No code is committed without a vote; three
	+1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed to
	approve a code change.</li>
	</ul>
	<p>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.</p>
	<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. Builds in this context are intended to include
	not only code but also reports, documentation, and courseware.</p>
	<p>Each Project is responsible for establishing test plans and the
	level of testing appropriate for the Project.</p>
	<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, and any other interested parties.</p>
	<h1 id="Licensing">Licensing</h1>
	<p>
	All contributions to Projects under this Charter must adhere to the
	Eclipse Foundation <a
	href="http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf">Intellectual
	Property Policy</a>.
	</p>
	</body>
	</html>