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.
Difference between revisions of "Project Management Infrastructure Redesign 2011"
(→New Project Proposal) |
(→Technology) |
||
| (51 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. | ||
| − | + | 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 | + | 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. | + | 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= | ||
| − | + | Moved to [[Project Management Infrastructure/Technology Choices]]. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
=Roles= | =Roles= | ||
| Line 93: | 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. | ||
| − | = | + | =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= | |
| − | + | *[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.
Contents
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