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.
Note that this document is not intended to be all inclusive. The combination of this document, the existing Developer Portal Use Cases, and the Eclipse Development Process form a more complete picture.
Contents
- 1 Problem Statement
- 2 Technology Choices
- 3 Roles
- 4 Communication Channels
- 5 Technology
- 6 Themes
- 7 Use Cases
- 7.1 User creates a Project Proposal
- 7.2 User Modifies a Proposal
- 7.3 Approve an unpublished Proposal: Proposer
- 7.4 Approve an unpublished Proposal: PMC
- 7.5 Approve an unpublished Proposal: EMO(PM)
- 7.6 Approve an unpublished Proposal: EMO(ED)
- 7.7 Publish a Proposal
- 7.8 Authenticated user comments on Proposal
- 7.9 User Changes Company Affiliation from one Known Company to Another
- 8 References and Links
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.
Technology
LDAP authentication
- All user information stored in LDAP
Themes
The following themes will guide the development of the new Project Management Infrastructure:
- Trust committers to do the right thing;
- Everything is undoable (i.e. revision tracking); and
- Do the simplest thing that can possibly work (avoid complexity)
We assume that committers will always endeavour to do the right thing. Specifically, we give committers leeway to do what they think is right. This, in combination with revision tracking means that mistakes can be easily undone. A committer may, for example, make ill-informed changes to a project's scope that is later reversed by the project lead or PMC.
It would be easy to get mired in multiple layers of approvals for various activities, or complex logic to prevent committers from shooting themselves in the proverbial foot. But such complexity makes the cost of later change and ongoing maintenance prohibitively high.
Note that we make a distinction between committers and general users. We do not--as a general rule--trust the general population to do the right thing. For completeness, we include with the definition of "committers" all those users with roles that permit them access to the project (including project leads, pmc members, EMO staff, etc.)
Use Cases
User creates a Project Proposal
- User logs in
- User clicks "Propose a project"
- User is presented with new "project proposal form"
- Provides proposal information (short name, long name, parent project, description, scope, etc.)
- User clicks "Save"
User Modifies a Proposal
- Proposer User logs in
- User clicks "Browse work items"
- User is presented with a list of proposals they created.
- User identifies project proposal and clicks corresponding "edit" link
- Information is modified
- User clicks "Save"
- A record of the change (including date/time stamp and the identity of the user) is stored along with the modified information
Approve an unpublished Proposal: Proposer
- Proposer User logs in
- User clicks "Browse work items"
- User is presented with a list of proposals they created.
- User identifies project proposal and clicks corresponding "view" link
- User clicks "Approve"
- Corresponding PMC is informed of the proposal (via email) requesting their approval.
Approve an unpublished Proposal: PMC
- PMC User logs in
- User clicks "Browse work items"
- User is presented with a list of proposals
- User identifies project proposal labelled "Awaiting PMC Approval" and clicks corresponding "view" link
- Label reflects state implied by proposer approval
- User reviews the contents, optionally provides comments, and clicks "Approve"
- Proposer is informed (via email) of the PMC approval.
- EMO(PM) is informed (via email) requesting their approval.
Approve an unpublished Proposal: EMO(PM)
- EMO(PM) User logs in
- User clicks "Browse work items"
- User is presented with a list of proposals
- User identifies project proposal labelled "Awaiting EMO(ED) Approval" and clicks corresponding "view" link
- Label reflects state that is implied by proposer and PMC approval
- User reviews the contents, optionally provides comments, and clicks "Approve"
- Proposer and PMC are infomred (via email) of the EMO(PM) approval.
- EMO(ED) is informed (via email) requesting their approval.
Approve an unpublished Proposal: EMO(ED)
- EMO(ED) User logs in
- User navigates to "Projects" landing page
- User identifies project proposal labelled "Awaiting EMO(ED) Approval" in "Action Items" section and clicks corresponding "view" link
- Label reflects state that is implied by proposer, PMC, and EMO(PM) approval
- User reviews the contents, optionally provides comments, and clicks "Approve"
- Proposer, PMC, and EMO(PM) are informed (via email) of the EMO(ED) approval.
- EMO(ED) is informed (via email) requesting their approval.
Publish a Proposal
- Approval obtained from Proposer, corresponding PMC, EMO(PM), and EMO(ED).
- Make proposal available to all users for review.
Authenticated user comments on Proposal
- User logs in
- User navigates to "Projects" landing page
- User identifies project proposal in "Proposals" section, and clicks corresponding "view" link
- User enters comments in provided text field.
- User clicks "Save"
- Proposer is informed (via email) of the comment and invited to reply
User Changes Company Affiliation from one Known Company to Another
- Committer User logs in
- User navigates to "Profile" landing page
- User clicks "I've changed employers"
- User enters date of end of employment with current company
- User enters new Employer information
- Content assist is provided to assist user in selecting known company
- User optionally provides a new primary email address
- User enters date of start of employment with new company
- User clicks "Save"
- IP team is informed of the change
- IP team confirms that required agreement is in place
- IP team authorizes the employment change