What is where¶

• Table of contents
• What is where
  • Platform objects
    • Projects
      • Types and hierarchy
      • Versions
    • Issues
      • Trackers (Types)
      • Tags
      • Checklists
      • Hierarchy and linking
    • Documentation
      • Wiki
    • Users
  • Viewing and reporting
    • Issue views
    • Wiki pages and reports
  • Setup of the platform
    • Templates
    • Guidelines

Platform objects¶

Projects¶

Projects allow to view issues connected to an area of work (through "Issues", "Gantt" or "Agile") and can hold their own documentation (in "Wiki", "Help&Support").

Types and hierarchy¶

Projects are used to group contributions from ESFRIS or Work Packages. They can be structured hierarchically, i.e. a WP sub-project concerning e.g. a product development or working group can be set up for a part of the effort.

Versions¶

A project can be assigned "versions" which represent milestones for project development. Issues can be assigned to versions to indicate their time frame.

Issues¶

Issues here can be used to assign and track contributions from ESFRIs to WPs and vice versa. They can be connected or ordered hierarchically, and assigned tags for easier findability or checklists to track progress. Issues should be assigned to the responsible contact person of the project part.

Trackers (Types)¶

Issues can be of different type (trackers), defining the type of contribution. The following trackers are available:

• Use Case: Parent issue to describe a full use case. Useful connected issues are of type Product* or Discussion
• Product: Parent issue to describe a product, e.g. a data set, service, workflow etc. which may be associated to a use case and can/should be integrated in ESCAPE. Should be connected to Use Case or Integration issues
• Integration: Is used to link a product to an integration process like data ingestion, software repository integration or similar. Can be linked to parent issues in WP projects tracking integration campaigns.
• Discussion: Issues to track common discussion points. Can be connected to all issues.
• Request: Can be used to document e.g. a call for contribution concerning an ESFRI and can be linked there.

Tags¶

Tags can freely be assigned to all issues, but should be limited to already established tags. Tags are used for filtering issues for common topics or relations. Useful tags are

• WP names, ESFRIs

Checklists¶

Each issue can have a checklist to track progress. For use cases, it can hold important integration steps, for integrations a checklist for integration stages etc. They are used to auto-calculate the "completeness" of an issue.

Hierarchy and linking¶

Issues can link to other issues via subtasks and Related issues. If the scope of an issues falls completely into the scope of another parent issue (e.g. an integration issue for an integration campaign), the parent-child relation should be used, otherwise, the issues can be linked as "Related to".

Documentation¶

A short description of a use case or product can be given in the issue, however, for more extensive documentation, the information could be stored at (and linked to) a wiki page in the project. In the "Help&Support" section of each project, easily accessible and findable guidelines can be stored or FAQs added. Documents can be added as attachments to issues, wikipages or stored separately in the "documents" section.
However, it is recommended to rather link to external documentation or files in the cloud if the document is not restricted to or very specific for this part of the project.

Wiki¶

The wiki should serve to summarize documentation of the various products and use cases, and additional documentation depending on the aim of the project.
The wiki should provide a link summary for contributions (i.e. talks or documentation) given in the ESCAPE context regarding the project and its components.

Users¶

The management of the ESFRI projects should be handled by representatives of the ESFRIs, and work package projects by representatives of the projects. Linking of issues and editing of content in e.g. wiki pages can be restricted to specific users. However, all users should be able to comment on issues and create issues of certain types, and write questions in the FAQ section.

Viewing and reporting¶

Issue views¶

Issues, Gantt view and Agile view of issues can be filtered by various issue attributes, e.g. project, tags or associations. A solid handling of issue attributes therefore ensures higher findability and tracking of issue relations.

Wiki pages and reports¶

It is possible to extend the capabilities of the platform by including reporting templates or wiki macros for e.g. filtering of issues. The implementation should follow the necessities of the project.

Setup of the platform¶

Templates¶

Templates should be provided for

• Each tracker type of issues
• An ESFRI project
• A workpackage project
• A documentation wiki page

Guidelines¶

• A "How to" is needed to explain the creation of projects and wiki pages
• Short user guidelines should be added on how to log on, view and comment on issues