Difference between revisions of "Project Management Infrastructure/Overview and Design"

Latest revision as of 15:47, 7 June 2013

Project Management Infrastructure Model

Much of the design is captured in Bugzilla (as indicated above).

The model of the system is captured in an Ecore file. Note that the model will continue to evolve as we progress through implementation.

Project

Much of the project management infrastructure revolves around the Project type. Much of the information tracked by a project is represented very simply as fields (e.g. websiteUrl and wikiUrl).

Representation of projects in the new system is not all that different from the old system. The main difference is that we will represent the project description, scope, and retention policy directly with the project.

• Project information can be viewed by anybody;
• Project information can be modified by any project member;
• Values for all URLs represented by a project must point to eclipse.org properties (www, downloads, wiki) unless otherwise specified;
• The project's relationship with Bugzilla is specified as a combination of Bugzilla Product and Component names that can be used to query Bugzilla in arbitrary ways, or provide assistance to a user in creating a bug;
• Text-based fields (description, scope, retention policy) are restricted to a subset of HTML tags:
  • Basic text markup, and links;
  • Limited use of links is recommended;
  • Content is expected to be concise, so there should be no need for heading ("Hn") or structural ("div") tags.
• Description is a short (1-2 paragraph) description of the project that is suitable for displaying on the project summary, on pages that provide an overview of multiple projects, and other places (a consistent, paragraph-based format will make for a very consistent experience);
• Additional information about the project (over and above the information provided in the description) can be obtained from the project web site (websitesUrl);
• Scope is the scope of the project as defined in the project proposal;
• The scope is editable by anybody with access with the caveat that changes to the text are permitted, but changes to the actual meaning of the scope must be vetted by the community via Restructuring Review;
• The retention policy is the formal policy set by the project regarding how they distribute their code, how older versions are retained, archived, etc.; and
• Projects are marked active immediately upon creation, they are marked inactive when terminated.

Issues to be addressed:

• Links to external content;
• Incubation conforming vs. nonconforming;

Person

Person instances have relationships with projects and organizations via roles

Person is the generalized term that we use to represent committers, project leads, company representatives, and more.

Very basic information, including a committerId (UNIX name), firstName, and lastName are represented in the instance. A person has zero or more phone numbers, mailing addresses, and email addresses.

Instances of person represent relationships with other types through direct and indirect means. A person optionally tracks a primary employer (primaryEmployer). Indirectly, an instance has relationships with zero or more Project instances, and zero or more Organization instances; those relationships are represented via Role instances.

Roles define the relationships between a person and zero or more organizations, and zero or more projects;

• Roles have a start and end date (an open end date implies that the person is currently active in the role);
• Additional role types can be added;

A person has zero or more organization roles, e.g.:

• Employee;
• Accounting contact;
• Administrative contact;
• Architecture Council Representative (Strategic Members only);
• Planning Council Representative (Strategic Members only);
• Board representative (Strategic Members only);
• Committer member;
• Company representative;
• Contact person for 24/7 IT support;
• Delegate;
• IT contact;
• Legal contact;
• Marketing contact;
• Membership page editor; and
• Organization alternate display.

A person has zero or more project roles, e.g.:

• Committer;
• Committer Emeritus;
• Project lead;
• PMC Lead (top-level projects only);
• PMC Member (top-level projects only);
• Architecture Council Representative (top-level projects only); and
• Planning Council Representative (top-level projects only).

Elections

Elections are connected directly to the role.

In the case of a person assuming a committer, project lead, or PMC Member roles, an election is required. Elections are attached directly to the project role.

• The nominee must already have an account;
• An election can only be initiated by any existing project member (committer, project lead, PMC Member, or PMC Lead);
• A user can only be nominated into a role if they do not currently hold that role;
• The nomination criteria must specify suitable merit;
  • We can generate a reasonable initial stab at a of merit based on activity in Bugzilla/Git;
• All project members are invited via email to vote;
• Project members vote yes (+1), no (-1), or abstain (0);
• The vote ends when:
  • all eligible voters have cast their votes; or
  • a full week has passed.

Election state transitions:

Dashboard

The user dashboard provides users with a customized view of pertinent information about the system, including:

• Information about the projects they lead or commit to;
  • e.g. missing, or incorrectly specified metadata
• Notification of upcoming releases;
• Elections that they are eligible to vote in;
• Missing or invalid personal data;
• Project proposals.