Problem Statement

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.

Technology comparison

Pros

Cons

Drupal

Skilled resources within existing Eclipse Foundation staff

Large number of skilled resources available

Very large community of developers, adopters, and users.

Deployed by 1,000s of organizations

Hundreds of plug-ins available to leverage in favour of writing custom code

Assumed to be no skilled Apricot developers available in the local area.

Ramp up time for new developers is relatively long.

Good quality Java-savvy developers are relatively difficult to find.

Availability and usefulness of extensions is unknown

No existing IT Infrastructure support

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.

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.

Any authenticated user can add themselves as an interested party (either as an individual, or as representative of an organization)

At any point in time, the EMO(PM) can review the collection of pending project proposals with the power to modify or remove.

Project Creation

The project proposer can request a creation review:

After a minimum of two weeks;

Only if all the committers indicated in the proposal have user accounts

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

New project is created

Some information copied from the proposal

Id, short/long name

Description

Scope

Committer/Project Lead/Mentor relationships captured

Project id

User id

Active Date

Committer relationships remain inactive until approved by EMO(IP) and Webmaster (indicating that the necessary paperwork/information has been recorded and the corresponding backend configuration has occurred).

A project retains linkage to the proposal.

A project is made active when approved by the EMO(PM), Webmaster, and EMO(IP)

Project's Active Date is recorded

Other

A project's metadata can be edited by the project lead, or any active project committer.

Any change to project metadata is tracked (including the date of the change and the identity of the individual who made the change).

Project id and scope cannot be edited

Elect a Committer

Nominee must be a registered user

Any project committer, or project lead can nominate a committer.

Committer election is successful if:

All existing committers vote +1

A minimum of three committers vote +1, no committers vote -1, and a week of generally-accepted business days have passed.

PMC must approve the vote

Committer relationship captured

Project id

User id

Active Date

Committer relationships remain inactive until approved by EMO(IP) and Webmaster (indicating that the necessary paperwork/information has been recorded and the corresponding backend configuration has occurred).

Release

A project can schedule any number of releases.

An attempt to schedule a release with less than one month lead time results in a stern warning

Releases should be scheduled well in advance of the actual event itself.

Need to give the community reasonable time to participate in the release.

Release record includes fields to concisely track:

New features included in the release

Changes, additions, and deletions of APIs

Architectural Issues

Non-Code Aspects

Security Issues

Usability

End-of-Life

Standards

Schedule

Communities

IP Issues

Additional values tracked:

Date of the release

Version name (e.g 1.0.1)

Download links

p2 repository links

SCM Tags

Field to track the Bugzilla milestones associated with the release

Fields can be filled out during the release

Projects are encouraged to fill out as much as possible as early as possible and keep information up-to-date

General Requirements

Authentication

Most items in the system can be viewed by unauthenticated users.

Unauthenticated users have limited ability to make changes.

User Accounts

Anybody can register for an account

Password strength checker provided

Automatic password generator provided

Record user's first name, last name, contact information

Optional picture, biographical information

Record user's affiliations over time (i.e. companies worked for and when)

Changes to affiliation information must be validated by the IP Team

Record multiple email addresses

Primary contact email address

one or more Git email, Bugzilla email

Other email addresses

Email addresses must be checked to avoid shenanigans

Users must confirm added email addresses via email

Each email address can be assigned to exactly one user

Users maintain their own information

Comments

Proposals, review documents, projects may all be commented on by an authenticated user

Comments carry the identity of the commentor, timestamp

No anonymous commenting

Comments are immediately visible

Comments can be flagged as inappropriate by any authenticated user (user id, timestamp is recorded)