Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Project Management Infrastructure Redesign 2011"
(→Proposal Phase) |
|||
| Line 127: | Line 127: | ||
During the proposal phase, any authenticated user may make comments on the proposal. Comments are maintained alongside the proposal itself. | 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 | + | 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 | + | The Proposal Phase runs a minimum of two 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. | ||
| + | # 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 | ||
| + | #* EMO(LC) approves. | ||
| + | # Project Creation Phase is initiated. | ||
Revision as of 11:34, 20 July 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.
| Language | Existing Resources | Community Size | Pros | Cons | |
|---|---|---|---|---|---|
| Drupal | PHP | 5 | 100,000s |
|
|
| Skalli | Java | 1 | 1 |
|
|
| Apricot | Java | 1 | 10s? |
|
|
Roles
- EMO(ED) - EMO Executive Directory (i.e. Mike)
- EMO(PM) - EMO Project Manager (i.e. Wayne)
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 Workflows
Project Proposal
Pre-proposal Phase
Any authenticated user can create a proposal. The proposal document is only accessible and editable by the proposer, anybody that they explicitly designate, the EMO(ED), and EMO(PM).
The proposal must contain:
- 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. The list of committers is generally be drawn from the list of known individuals (using predictive typing support), but new individuals can be added.
Workflow:
- Proposer and team assemble the proposal.
- Proposer submits the proposal for consideration.
- Proposal is reviewed by EMO(PM)
- Proposal is either kicked back to the proposer with comments and input for further refinement (i.e. goto 1), or is approved (i.e. continue)
- Proposal is reviewed by EMO(ED)
- Proposal is either kicked back to the proposer with comments and input for further refinement (i.e. goto 1), or is approved (i.e. continue)
- Proposal is posted live on the eclipse.org website for community review
- Community is notified and invited to comment on the proposal via established channels
- Pre-proposal Phase ends; enter the Proposal Phase.
At any point in time, the EMO(PM) can review the collection of pending project proposals with the power to modify or remove.
Proposal Phase
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 two 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.
- 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
- EMO(LC) approves.
- Project Creation Phase is initiated.