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.
Project Management Infrastructure Redesign 2011
This effort is being tracked by Bug 243223.
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? |
|
|