Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "EGI-Engage:Quality Plan"

From EGIWiki
Jump to navigation Jump to search
Line 13: Line 13:
== Meetings  ==
== Meetings  ==


'''The meetings must be recorded '''in the [http://indico.egi.eu/ EGI Indico server ]and all presentations and material provided for the meeting, including any minutes, must be attached to the appropriate agenda page.  
'''The meetings must be recorded '''in the [https://indico.egi.eu/indico/categoryDisplay.py?categId=137 EGI Indico server ]and all presentations and material provided for the meeting, including any minutes, must be attached to the appropriate agenda page.


== Presentations  ==
== Presentations  ==

Revision as of 20:14, 5 March 2015

EGI-Engage project: Main page WP1(NA1) WP3(JRA1) WP5(SA1) PMB Deliverables and Milestones Quality Plan Risk Plan Data Plan
Roles and
responsibilities
WP2(NA2) WP4(JRA2) WP6(SA2) AMB Software and services Metrics Project Office Procedures



Help and support: Malgorzata Krakowian  malgorzata.krakowian@egi.eu

Project outputs and communication

All output produced by staff active within EGI-Engage (funded and unfunded effort) must be recorded so that it can be reported by the project.

The following rules must be used:

Meetings

The meetings must be recorded in the EGI Indico server and all presentations and material provided for the meeting, including any minutes, must be attached to the appropriate agenda page.

Presentations

Presentations and/or papers presented at other meetings attended by EGI-Engage staff must be recorded in the EGI Document Repository

A link to the meeting and a summary of the outcome should be recorded in the ‘notes’ section of the document.

Mailing lists

As the majority of the communication within the project will be electronic having a coherent record of that work is essential.

All mailing lists must use the EGI.eu based mailing lists which allow groups defined within the single sign on to be linked to mailing lists, access to wiki space, document access, etc.

Mailing lists to be used within EGI-Engage project:

leader is responsible to decide how many and which one mailing lists are necessary to run efficiently the workpackage.


Websites

www.egi.eu

www.egi.eu is the main website for the project. It is used mainly for all ‘official’ ‘static’ content.

wiki.egi.eu

The wiki has group based access control provided through the EGI SSO system. This can be used for all dynamic content being maintained or developed within each project activity.

EGI-Engage Project main wiki page: https://wiki.egi.eu/wiki/EGI-Engage:Main_Page
Content:

  • description of the project
  • work packages dedicated pages (tasks, contacts, deliverables, milestones) Please do not change structure of the page.
  • milestones and deliverables
  • quality assurance 

Third party websites

Other third party websites or wikis should not be used to host EGI-Engage related material in order that the egi.eu domain becomes the definitive source of project information. Individual services supported by EGI.eu will have their own hostname in the egi.eu domain.

Other

All tools availabe for EGI-Engage to be used are listed under EGI Collaboration tools

Document management

Document naming convention

  • Filenames

Filenames must use the following format in order to link any item back to other versions placed in the document repository. The filename format is:

EGI-<DOCUMENT IDENTIFIER>-<REPOSITORY ID>-V<VERSION>

DOCUMENT IDENTIFIER The document identifier is dependent on the document type. If the document is:
  • Deliverable: Use the deliverable name: e.g. D1.1, D5.5, etc.
  • Milestone: Use the milestone name: e.g. MS102, MS504, etc.
  • Activity: Use the activity code: e.g. SA1, NA3, etc.
  • Committee/Board: Use an acronym based on the committee or board name: e.g. TCB, OMB, UCB, SPG, etc.
  • Other: If the source of the material cannot be identified then ignore this section.
VERSION This is the version number generated by the document repository for the particular repository identifier.


Example: EGI-Engage-MS301-V1.0.pdf


  • Document titles

The title of documents uploaded to document repository must be in the following format:

<DOCUMENT IDENTIFIER> Title (from the first page of the document)


Example: MS301 User Support Contacts


Metadata management

Document metadata 

The first page of the document (along with the header and footer) contains metadata that needs to be reviewed and completed:

  • Title: This must be the title of the milestone or deliverable as described in the Description of Work.
  • Deliverable/Milestone code: e.g. D1.1 or MS101. Delete if not required.
  • Document identifier: With a correctly formulated filename (see ‘Naming Convention’) this field can be updated in MS Word by highlighting, right clicking and selecting ‘Update Field’.
  • Date: This field records the last date the document was saved and can be updated in MS Word by highlighting, right clicking and selecting ‘Update Field’.
  • Activity: Enter the work package name (WP1, WP2, etc.) that is producing this document.
  • Lead Partner: Enter the recognised shortname within the EGI-Engage project of the lead partner.
  • Document Status: This will move through the following states for milestones and deliverables:
    • TOC (Table of Contents)
    • Draft
    • Review
    • AMB/PMB Review
    • FINAL
  • Dissemination Level: This indicates the final dissemination level of the document:
    • INTERNAL: The document is internal to the project consortium and will not be passed onto the European Commission or the reviewers.
    • CONFIDENTIAL: The document is available to the project and the European Commission and its staff and reviewers, but must not be disclosed any further.
    • PUBLIC: The document is publicly available.
  • Document Link: The URL in the EGI document repository that provides access to the document.
  • Abstract: An abstract describing the document’s contents and main conclusions. On submission of the final version this should be entered into the relevant field in the repository metadata.

The document title must be repeated into the header and before submitting a new version to the document repository the date and filename fields in the header must be updated.

Repository metadata

When creating the entry in the document repository there are a number of compulsory metadata fields that need to be completed. These should be copied from the document metadata where duplicated:

  • Title
  • Abstract
  • Keywords
  • Notes and changes
  • Media type
  • Submitter: Select the person submitting the document.
  • Authors: Select the people involved in writing significant portions of the document.
  • View: Select the groups able to view the document. Documents that are drafts may be restricted to the groups within the project that are working on the document. Documents that are complete must be marked public unless they are marked for distribution just inside the project.
  • Modify: The ‘office’ group must me marked as able to modify the document.
  • Topics: Select the topics relevant for the material. These will generally include ‘EGI-Engage’, committee/board that the material is coming from
    • Any inout from EGI-Engage would minimally have the topics ‘EGI-Engage’
    • There are also documents that are generated within the community that go beyond the scope of just the EGI-Engage project (e.g. operational policy documents) would minimally have the topics from ‘EGI’ category selected.

Access to documents

Access to internal or confidential documents is controlled at SSO group level, with SSO IDs being assigned to particular groups depending on their permissions to view or modify documents. Public documents are available to all, without restriction or the requirement to log in. Restricted documents can only be viewed and/or modified by logging in using an account with the correct permissions.

Content guidelines

All documents will be written in English and use document formats described in the following section. In addition to the fields and sections already described in the document template, deliverables must include an Executive Summary and, if required, one or more Annexes. References to external document and a Glossary to terms not listed on the website must be recorded. The correct capitalisation of the project name is EGI-Engage. English date format must be used (DD/MM/YYYY) when required.


All output from the project (paper or presentation) must include the phrase:

[To be defined]

unless the output is using one of the recognised project templates where appropriate acknowledgements are already included.

Formats and tools

The following tools and formats will be recognised within the project:

  • Word Processing: ‘Word Format’ allowing its use on MS Office on Windows/Mac and OpenOffice on Linux
  • Spreadsheet: ‘Excel Format’ allowing the use of MS Office on Windows/Mac.
  • Presentation: ‘Powerpoint Format’ allowing the use of MS Office on Windows/Mac.

Final version of all formal documents (milestones and deliverables) must be available in PDF format.

Glossary

Copyright


EGI-Engage
Copyright © Members of the EGI-Engage Collaboration,


EGI.eu

Copyright © EGI.eu. This work is licensed under the Creative Commons Attribution-NonCommercial- NoDerivs 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/3.0/ or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. The work must be attributed by attaching the following reference to the copied elements: “Copyright © EGI.eu (www.egi.eu). Using this document in a way and/or for purposes not foreseen in the license, requires the prior written permission of the copyright holders. The information contained in this document represents the views of the copyright holders as of the date such views are published.

Review process for deliverables and milestones

[To be defined]



QA internal resources