Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Project Management Infrastructure Redesign 2011
This effort is being tracked by Bug 243223.
Contents
Problem Statement
Current infrastructure (i.e. The Developer Portal) is inadequate.
Multiple, separate data sources.
Portal is separate from the the resources being managed. Requires a context switch to use. Most committers have difficulty (or outright refuse) to make that context switch.
Some management tasks are spread out. Specifying a description for a project, for example, requires that an HTML file be created in the project directory (requires CVS check-in), and then the specification of a URL in the portal. Very difficult to maintain. Very separated from where and how the description is used. As a result, descriptions tend to be poorly specified, and maintained.
Too much information is not included in or managed by the portal. Project proposals, review documentation, IP logs, are all separate.
Technology Choices
Project management is essentially a document-management and workflow problem. Several solutions exist in this area.
The Eclipse Foundation currently uses Drupal for Eclipse Marketplace, Eclipse Live, and the EclipseCon Website. Several Eclipse Foundation employees are already well-versed in Drupal development, and finding temporary resources with the necessary skills in the local area should be relatively easy and cost-effective. Drupal is based on PHP, a language that is known to most of the Eclipse Foundation staff, and is currently in wide deployment by the Eclipse Foundation.
Perhaps one of the features that weighs most heavily in Drupal's favour is the size of the community behind it (which measures in the hundreds of thousands) and the hundreds (perhaps thousands) of plugins that are available to extend it. The availability of plugins, combined with the relative ease with which Drupal can be extended means that the overall amount of custom code that needs to be maintained should be relatively small (as compared to other solutions that may require more customization).
There are several other options that have been considered, including a handful of Eclipse-based solutions (which would allow us to "eat our own dogfood"). After careful consideration, however, we have determined that we do not have the resources to implement these solutions.
Pros | Cons | |
---|---|---|
Drupal |
|
|
Skalli |
|
|
Apricot |
|
|
Roles
- EMO(ED) - EMO Executive Directory (i.e. Mike)
- EMO(PM) - EMO Project Manager (i.e. Wayne)
- EMO(LC) - EMO Legal Council (i.e. Janet)
- EMO(IP) - EMO Intellectual Property Team
- Proposer
- Committer
Communication Channels
The communication channels used by the system are expected to change with time as technologies and communities evolve. Favoured technologies of the day are Twitter, RSS, and the eclipse.proposals forum.
Core Use cases
- New Project Proposal
- Proposal becomes a Project
- Elect a Committer
- Project Release
New Project Proposal
Any authenticated user can create a proposal.
The proposal must contain:
- Project name, id, parent project;
- Rich text description (single paragraph);
- Rich text scope (single paragraph);
- Rich text detailed description (multiple paragraph, bullets, images, etc.);
- Rich text "Why Eclipse?" discussion;
- Rich text "Initial Contribution" discussion;
- List of initial committers (name, optional affiliation, email address); and
- Rich text discussion of legal isues.
All revisions to the document are tracked.
Only the proposer and EMO(PM) can edit the proposal.
Proposal is made public only after it has been approved by the proposer, corresponding PMC, EMO(PM), EMO(ED). Prior to being made public, the proposal document is only accessible to the proposer, corresponding PMC, the EMO(ED), and EMO(PM).
Public proposals are listed on the main page.
At any point in time, the EMO(PM) can review the collection of pending project proposals with the power to modify or remove.
After a minimum of two weeks, the project proposer can request a creation review.
Creation review starts with the approval of the EMO(PM).
The proposal document cannot be modified during the creation review period (the EMO(PM) can make changes in exceptional circumstances).
Creation review runs for a week.
Creation reviews are listed on the main page.
Creation review declared successful with approval of the EMO(PM).
Proposal Becomes a Project
During the proposal phase, any authenticated user may make comments on the proposal. Comments are maintained alongside the proposal itself.
The proposal can be modified by the proposer, their designate, or the EMO(PM) at any point during this phase. All modifications are tracked and notification is sent to the community via established channels.
The Proposal Phase runs a minimum of three weeks. The community needs to be given reasonable opportunity to respond to changes, so the proposal must remain the Proposal Phase for at least one week following any modification.
When the proposer feels that the project is ready for creation, they submit a creation request.
Workflow:
- Community members comment on the proposal and receive responses from the proposer and their designates.
- Proposer requests creation.
- EMO(PM) reviews the state of the proposal and community activity
- Proposal is kicked back to the proposer if it is determined that the proposal needs more time or modification based on community feedback (i.e. goto 1); or
- EMO(PM) approves (i.e. continue)
- EMO(LC) is asked to perform a trademark search on the proposed project name;
- Works with proposer and EMO(PM) to resolve any conflicts or concerns and update the proposal as necessary; and
- EMO(LC) approves (i.e. continue)
- Provisioning Phase initiated
The EDP-mandated "Creation Review" is implicit in the Proposal Phase.
Provisioning Phase
During the provisioning phase, project resources are allocated. This includes such things as space on the various servers, creation of project and committer records, and so-forth.
Committers
Nominate a Committer
Nominate a committer to an existing project.
Workflow:
- Existing committer nominates a new committer, specifying:
- name, email address
- Paragraph describing merit of nomination
- Existing committers vote
- Election ends successfully if all committers vote positively (i.e. goto 4)
- After one week, results are checked
- Election ends successfully if there are at least three positive votes, with no negative votes (i.e. goto 4)
- Election fails otherwise (i.e. exit)
- Notify PMC of vote results, request PMC approval
- If approved, continue
- If disapproved, election fails (i.e. exit)
- Committer provisioning commences
Provision a Committer
Workflow:
- EMO(IP) is informed of the need to provision committer, and is asked for approval
- EMO(IP) works with the project, committer, and PMC to resolve any issues.
- If approved, continue
- If disapproved, notify project, committer, PMC, remove the request and exit
- Committer record is created
- Webmaster is informed of the need to configure backend access (i.e. add new committer to appropriate UNIX group)
- Webmaster indicates that backend access is established
- New committer, project, and PMC is informed of successful completion of committer provisioning