Skip to main content

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.

Jump to: navigation, search

Project Management Infrastructure Redesign 2011

Revision as of 10:00, 29 September 2011 by Wayne.eclipse.org (Talk | contribs) (Project Lead)

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.

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
    • Integration with Facebook, Twitter, etc.
    • Access information via RESTful webservices
  • Build-in (no-brainer) database support
  • Integrated Development tools + Eclipse/PDT
  • Existing IT Infrastructure support
  • Drupal-specific data structures and formats.
  • Not dogfooding; perception in the community
Skalli
  • Java based: Some Java skills on staff
  • "Dogfooding" solution
  • Eclipse-based development tools available
  • Leverage existing Eclipse technologies (EMF, workflow projects, SOA, EclipseLink, etc.)
  • Project developers have expressed interest in implementing some Eclipse Foundation processes (though with no specific commitments)
  • Opportunity to fully control the database structure
  • New project, very small community
  • Limited availability of skilled resources
    • Ramp up time for new developers is relatively long.
    • Good quality Java-savvy developers are relatively difficult to find.
    • Virtually impossible to find developers familiar with Skalli itself
  • Integration opportunities with existing Eclipse technologies remain largely unexplored
  • No existing IT Infrastructure support
Apricot
  • Java based: Some Java skills on staff
  • "Dogfooding" solution
  • High-quality, established project with several high-volume consumers
  • Eclipse-based development tools available
  • Leverage existing Eclipse technologies (EMF, workflow projects, SOA, EclipseLink, etc.)
  • Community size is unknown
  • Unknown availability of skilled resources
    • 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.

Technology

LDAP authentication

  • All user information stored in LDAP

Core Requirements

  • 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.
  • 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


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

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)
    • Flagged comments are moderated by content owners and EMO(PM)

Approvals

  • Approvals are required at various points in the lifecycle of proposals, reviews, and more.
  • Approvals are made on behalf of an individual (e.g. EMO) or body (e.g. PMC)
  • Approvals record a timestamp, identity of the approving individual, and the body on behalf of which the individual is acting.
  • In general, the order of approval is not strictly governed.

Elections

  • Elections for committers, project leads, PMC members, and PMC leads are all automated
  • Elections run for one week, or until all eligible voters have cast their positive (+1) vote
  • Any negative vote (-1) left unresolved at the end of the election is effectively a veto
  • Voters can change their vote at any time during the election period
  • When the election is complete, the required approvals are solicited
  • The nominee is automatically (inasmuch as automation is possible) installed.

Committer Elections

  • Committers can be nominated to a specific project by any existing committer, project lead, PMC Member or PMC Lead for that same project
  • Nominee must already have an account with the system (though they need not necessarily be a committer)
  • Only project committers can vote.
  • Committer election must be approved by PMC, EMO(PM)
  • EMO(IP) ensures that appropriate paperwork has is available and approves (or not) the election.
  • Webmaster provisions to the committer
  • Committer is active.

Project Lead Elections

  • Project Leads can be nominated to a specific project by any existing committer, project lead, PMC Member or PMC Lead for that same project
  • Nominee must already have an account with the system
  • Only project committers can vote.
  • Committer election must be approved by PMC, EMO(PM), and EMO(ED).
  • Relationship is automatically created when approvals are obtained

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

References and Links

Back to the top