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

Difference between revisions of "Project Management Infrastructure Redesign 2011"

(Pre-proposal Phase)
(Technology)
 
(60 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
This effort is being tracked by [https://bugs.eclipse.org/bugs/show_bug.cgi?id=243223 Bug 243223].
 
This effort is being tracked by [https://bugs.eclipse.org/bugs/show_bug.cgi?id=243223 Bug 243223].
 +
 +
Note that this document is not intended to be all inclusive. The combination of this document, the existing Developer Portal [https://dev.eclipse.org/portal/myfoundation/tests/index.php Use Cases], and the [http://www.eclipse.org/projects/dev_process/development_process.php Eclipse Development Process] form a more complete picture.
  
 
=Problem Statement=
 
=Problem Statement=
 
Current infrastructure (i.e. The Developer Portal) is inadequate.
 
Current infrastructure (i.e. The Developer Portal) is inadequate.
  
Multiple, separate data sources.
+
Data concerning projects, people, organizations, members, and more is spread across multiple, separate data sources. This makes querying across data challenging. In some cases, data is replicated from one database to another to facilitate some queries while providing an added layer of protection. The database that contains committer information, the so-called "Foundation" database, is kept separate from other systems to provide an added layer of protection against private data being compromised. Bits of that database are replicated into an "Eclipse" database for access from the public website.
  
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.
+
Portal is separate from the the resources being managed; this requires a context switch to use. The content displayed in the project summary pages, for example, comes from the portal. When a committer notices that the data in the project summary is incorrect, they must switch into the portal to make the change. 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.
+
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. This is very difficult to maintain as it is separated from where and how the description is used, and requires multiple steps with multiple tools to complete. As a result, descriptions tend to be poorly specified, and rarely maintained.
  
Too much information is not included in or managed by the portal. Project proposals, review documentation, IP logs, are all separate.  
+
Too much information is not included in or managed by the portal. Project proposals, review documentation, IP logs, are all separate.
  
 
=Technology Choices=
 
=Technology Choices=
  
Project management is essentially a document-management and workflow problem. Several solutions exist in this area.
+
Moved to [[Project Management Infrastructure/Technology Choices]].
 
+
The Eclipse Foundation currently uses Drupal for [http://markeplace.eclipse.org Eclipse Marketplace], [http://live.eclipse.org Eclipse Live], and the [http://www.eclipsecon.org 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.
+
 
+
{|  border="1" cellpadding="2"
+
|+Technology comparison
+
|- style="vertical-align:top;"
+
!   !! Pros !! Cons
+
 
+
|- style="vertical-align:top;"
+
! 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
+
 
+
|- style="vertical-align:top;"
+
! [http://www.eclipse.org/skalli 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
+
 
+
|- style="vertical-align:top;"
+
! [http://www.eclipse.org/aprcot Apricot]
+
|
+
* "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=
 
=Roles=
Line 92: Line 30:
 
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.
 
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=
+
=Technology=
 +
 
 +
Moved to [[Project Management Infrastructure/Technology Choices]].
  
==Project Proposal==
+
=Themes=
  
===Pre-proposal Phase===
+
Moved to [[Project Management Infrastructure]].
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:
+
=Requirements and Implementation=
* 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. The list of committers is generally be drawn from the list of known individuals (using predictive typing support), but new individuals can be added.
+
Moved to [[Project Management Infrastructure/Development]].
  
Workflow:
+
=Overview and Design=
# 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
+
#* Proposal is approved (i.e. continue)
+
# Proposal is reviewed by corresponding PMC
+
#* Proposal is either kicked back to the proposer with comments and input for further refinement (i.e. goto 1); or
+
#* Proposal 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
+
#* Proposal 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|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.
+
Moved to [[Project Management Infrastructure/Overview and Design]].
  
===Proposal Phase===
+
=Structure=
  
During the proposal phase, any authenticated user may make comments on the proposal. Comments are maintained alongside the proposal itself.
+
Moved to [[Project Management Infrastructure/Development]].
  
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.
+
=Application Lifecycle Management=
  
The Proposal Phase runs a minimum of three 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.
+
Moved to [[Project Management Infrastructure/Development]].
  
When the proposer feels that the project is ready for creation, they submit a creation request.
+
=Schedule=
  
Workflow:
+
April 2/2012 - Phase I beta-testing for projects.eclipse.org and PolarSys. Support for maintaining and disseminating project and release information, project proposals, and committer and project lead elections.
# 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 (i.e. continue)
+
# 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 and update the proposal as necessary; and
+
#* EMO(LC) approves (i.e. continue)
+
# Provisioning Phase initiated
+
  
The EDP-mandated "Creation Review" is implicit in the Proposal Phase.
+
May 21/2012 - Phase II beta-testing for projects.eclipse.org and PolarSys. Support for user dashboard, email notification, simultaneous release tracking,
  
===Provisioning Phase===
+
July 2/2012 - Go-live for Eclipse.org
  
During the provisioning phase, project resources are allocated. This includes such things as space on the various servers, creation of project and committer records, and so-forth.
+
=References and Links=
 +
*[http://drupal.org/node/997082 LDAP for Drupal 7]

Latest revision as of 16:25, 17 April 2012

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.

Problem Statement

Current infrastructure (i.e. The Developer Portal) is inadequate.

Data concerning projects, people, organizations, members, and more is spread across multiple, separate data sources. This makes querying across data challenging. In some cases, data is replicated from one database to another to facilitate some queries while providing an added layer of protection. The database that contains committer information, the so-called "Foundation" database, is kept separate from other systems to provide an added layer of protection against private data being compromised. Bits of that database are replicated into an "Eclipse" database for access from the public website.

Portal is separate from the the resources being managed; this requires a context switch to use. The content displayed in the project summary pages, for example, comes from the portal. When a committer notices that the data in the project summary is incorrect, they must switch into the portal to make the change. 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. This is very difficult to maintain as it is separated from where and how the description is used, and requires multiple steps with multiple tools to complete. As a result, descriptions tend to be poorly specified, and rarely maintained.

Too much information is not included in or managed by the portal. Project proposals, review documentation, IP logs, are all separate.

Technology Choices

Moved to Project Management Infrastructure/Technology Choices.

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

Moved to Project Management Infrastructure/Technology Choices.

Themes

Moved to Project Management Infrastructure.

Requirements and Implementation

Moved to Project Management Infrastructure/Development.

Overview and Design

Moved to Project Management Infrastructure/Overview and Design.

Structure

Moved to Project Management Infrastructure/Development.

Application Lifecycle Management

Moved to Project Management Infrastructure/Development.

Schedule

April 2/2012 - Phase I beta-testing for projects.eclipse.org and PolarSys. Support for maintaining and disseminating project and release information, project proposals, and committer and project lead elections.

May 21/2012 - Phase II beta-testing for projects.eclipse.org and PolarSys. Support for user dashboard, email notification, simultaneous release tracking,

July 2/2012 - Go-live for Eclipse.org

References and Links

Back to the top