/
charter.html
409 lines (409 loc) · 20.1 KB
/
charter.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
<?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>