(mOSAIC) Trac

Observations:

• there are three main parts:

  • Wiki -- describes the layout, guidelines, etc. about the wiki;

  • Project management -- covers the ticketing system and the resulting project management facilities;

  • Security -- how the security is organized (maybe this should be read first because it's referenced all over the place);

• maybe there should be two Trac instances: one for the open source code, and another one for the EU-FP project;

Wiki

Hierarchy:

• Bureaucracy (internal):

  • here we store everything related to the project organization;

    according to Wikipedia description: Bureaucracy is the combined organizational structure, procedures, protocols, and set of regulations in place to manage activity, usually in large organizations.

  • WorkPackages;

  • Deliverables;

  • Reviews;

  • Meetings;

• Releases (public):

  • Stable:

    • Version:

      • here we can store release notes, change logs or other relevant information about a particular release;

  • Development;

• Members (public):

  • FirstnameLastname (identical to the user-name);

    • user-dependent, defined by each user (some content could be internal or private);

  • OrganizatInitials -- the initials of the organization but wikified (first letter is uppercase, next are lowercase) (ex. Ieat, Sun, etc.);

    • organization-dependent, defined by each organization (some content could be internal or private);

• Publications (public):

  • PublicationInitials-Year (ex. Synasc-2010);

• Documentation (public):

  • this structure will be decided when we'll have any documentation to put here;

• Cache (internal):

  • Publications:

    • this page (or a small domain-clustered hierarchy) should contain references and downloadables of external papers (or presentations, etc.) relevant for our project; the name of the attachments should follow the following naming convention rule (for better usability): by taking the title of the paper, replacing all long dashes with a double underscore __, then replacing all spaces with single underscores _, and lowercasing everything; usually we should put here PDF's, or PS in worst case; because it will contain downloadable versions of external papers (to which we have no publication rights) this page will be readable only by Mosaic/Members and Mosaic/Students (thus the internal authorization level); no copyrighted material which is not available on the Internet (directly from the author or publisher) shall be stored here;

Project management

Tickets

As a general rule everything that happens inside the project should happen as a consequence of a ticket issued in the Trac site.

Each Trac ticket has the following attributes:

• contexts -- should be set only by Mosaic/Members or Mosaic/Students (with the following noted exceptions):

  • Milestone -- the release or EU commission report that should contain this task's outputs (see below for further details);

  • Component -- the module or deliverable that the ticket belongs to; (again see below;) (this could be set by the initial reporter, or changed afterward;)

  • Version -- the version of the module for which the ticket applies; (again see below;) (this also could be set by the initial reporter;)

  • Keywords -- additional categorization keywords; (we could build a database of most used keywords;) (we could use them as tags;)

• task categorization -- should be set only by Mosaic/Members or Mosaic/Students :

  • Type -- evident; (see below for further details);

  • Status -- evident; (again see below;)

  • Resolution -- evident; (again see below;)

  • Priority -- evident; (again see below;)

• involved persons -- should be set only by Mosaic/Members or Mosaic/Students :

  • Reporter -- automatically set by the Trac instance;

  • Assigned to / Owner -- the one that is responsible for doing or (if multiple persons are involved) overseeing the entire activity;

• Summary and Description -- evident;

For more details please see the Trac documentation.

Contexts

Trac knows about the following project management related entities (for further details see the Trac documentation):

• milestones -- allows to group tasks in order to provide an estimate of the effort invested / remaining for a specific goal (release or review);

• components -- like milestones, the components provide another axis for the effort estimation, by allowing tasks to be grouped by working item (deliverable, module, etc.);

• versions -- applicable only for release related entities (like modules, etc.);

Milestones

• Reviews/MonthYear -- it shall group all tasks related with preparing for a particular EU commission review (by using components in place of deliverables we can asses the progress per review per deliverable (and thus per work package));

• Releases/Version -- it group all tasks related to a particular code release;

• Publications/PublicationInitials-Year -- if there are complex publications (involving multiple teams) we could define a milestone specifically for it;

Components

• Deliverables/x.x.x-SomeTitle;

• Modules/ModuleName;

• Publications/PublicationInitials-Year;

• Documentation/ItemName;

• Infrastructure/Trac -- Trac administration related tasks;

• OrganizationInitials/CustomName -- custom work-items that are local to a particular organization;

Versions

• Releases/VersionNumber;

• if the modules are released in a bundled fashion (all modules are grouped and released together under the same version), we can use generic components like Modules/AmazonAgent and generic versions like Release/2.1.0, but if the modules are shipped individually we could either create new components for each new release (like Modules/AmazonAgent/2.1.0) or create versions specific to components (like Releases/AmazonAgent/2.1.0);

Ticket types

Types:

• Stuff -- the default type, when the nature of the ticket is uncertain; set by anyone;

• Defect -- evident; set only by Mosaic/Members or Mosaic/Students;

• Enhancement -- evident; set only by Mosaic/Members or Mosaic/Students;

• Task -- anything that has to be done and is not related with software;

• Discussion -- this is not actually a ticket, but could be used to capture discussions about a certain topics (like RFC, enhancements proposals, etc.);

Ticket status

Status:

• Opened -- set initially by the tool;

• Pending -- after a responsible (Assigned to / Owner) is chosen and the ticket type is changed from Stuff; set only by Mosaic/Members or Mosaic/Students;

• Closed -- when the task was finished; set only by Mosaic/Members or Mosaic/Students;

• Reopened -- when the task solution is not accepted; set only by Mosaic/Members;

Ticket resolutions

Resolutions:

• Finalized -- initially in Trac this is called fixed, but because we shall use tickets also for tasks, it's better to say: I've finalized this task than I've "fixed" this task.

• Aborted -- mainly for tasks that haven't been done; (in Trac the equivalent would be cantfix);

• Rejected -- when the ticket won't be accomplished; (for example the reported bug can't be reproduced, or the enhancement request is not approved);

• Invalid -- when the ticket makes no sense or is a duplicate of another one;

Ticket priorities

Priorities:

• Normal -- the default choice;

• Low -- set by anyone;

• High -- set only by Mosaic/Members or Mosaic/Students;

• Immediate -- something very urgent that needs to be done right away; set only by Mosaic/Members;

Ticket workflow

For a ticket from a Mosaic/Users or anonymous user is created with the following properties:

• contexts:

  • Milestone -- none;

  • Component -- set accordingly;

  • Version -- set accordingly;

  • Keywords -- not set;

• task categorization:

  • Type -- set to either Stuff or Discussion;

  • Status -- Opened;

  • Resolution -- none;

  • Priority -- Normal;

• involved persons:

  • Reporter -- automatically set by the Trac instance;

  • Assigned to / Owner -- none;

• Summary and Description -- set accordingly;

A ticket from a Mosaic/Members or Mosaic/Students user all the properties are set accordingly, but with the following state transition rules:

• for a Stuff ticket type:

  • from Opened state it can only change it's type to either Defect, Enhancement, Task or Discussion;

• for a Defect, Enhancement or Task ticket type:

  • from status Opened or Reopened it can transition only to:

    • to Pending state after the Milestone, Assigned to / Owner, and other properties have been set;

    • to Closed state but with a resolution of Finalized, Rejected or Invalid;

  • from status Pending it can transition only to:

    • to Closed state but with a resolution of Finalized, Aborted, Rejected, or Invalid;

  • from status Closed it can transition only to:

    • to Reopened without any further updates;

    • to Pending state after the Milestone, Assigned to / Owner have been updated;

• for a Discussion ticket type:

  • from status Opened or Reopened it can transition only to:

    • Closed state but with a resolution of Finalized;

  • from status Closed:

    • to Reopened state;

Security

User roles

The following user categories are taken into account for the Trac site:

• Mosaic/Members -- all the official members involved in the project, which will have full access to all content;

• Mosaic/Students -- all the students (or other persons) temporarily involved in the project, which would have read-write access to most of the content (including internal), but could be restricted for highly sensitive content (no such content identified yet);

• Mosaic/Guests -- catch-all group for persons which need more access than normal un-authenticated (anonymous) Internet users; usually these will have read-only access to some internal content (maybe the same as Mosaic/Students);

• Trac/Admins -- persons which are involved in the Trac instance management;

• anonymous -- any un-authenticated Internet user; usually these will have read-only access to public content;

• Mosaic/Users -- created for the purpose of (maybe) controlling access to the ticketing system to only authenticated users; (if we let anonymous people put tickets then we don't need this group);

User accounts

Guidelines:

• anyone can apply for an account (by simply accessing the Register page from the Trac site);

• the user is required to provide a valid email address (which is going to be validated automatically by the Trac instance);

• the user name should respect the following CamelCase pattern: FirstnameLastname (ex. CiprianCraciun, MarianNeagul, etc.);

• after the application one of the Trac/Admins members will have to approve the creation and add the user to the appropriate user groups;

Authorization

In general the content should fall in one of the following levels:

• private -- only Mosaic/Members are granted read-write access to this content;

• internal -- only Mosaic/Members and Mosaic/Students are granted read-write access to this content, and Mosaic/Guests are granted read-only access;

• public -- freely accessible content by anyone on the Internet;

Unfortunately the authorization levels should be coupled with the Trac layout hierarchy (especially for wiki pages);