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 50: Line 50:
== Acknowledgement  ==
== Acknowledgement  ==


Proper [[Copyright|acknowledgement statements]] should be used for EGI-Engage outputs unless the output already uses one of the recognised project templates, where appropriate acknowledgements are already included.  
Proper [[Copyright#EGI-Engage|acknowledgement statements]] should be used for EGI-Engage outputs unless the output already uses one of the recognised project templates, where appropriate acknowledgements are already included.  


<br>  
<br>


== Software and Services  ==
== Software and Services  ==

Revision as of 17:27, 8 September 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 (Quality Manager)


This page is providng rules regarding organization, communication and recording of work within EGI-Engage project.


Project communication and outputs

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 run by EGI-Engage
    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 and posters
    Presentations and/or posters presented at other meetings attended by EGI-Engage staff must be recorded
    in the EGI Document Repository and EGI-Engage templates must be used. A link to the meeting and a summary of the outcome should be recorded in the ‘notes’ section of the document. A dedicated EGI-Engage tag is available to qualify documents, milestones, papers, presentations and other documentation relevant to the project.
  • Mailing list:
    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. If needed mailing list related to EGI-engage project should start with egi-engage-
    Mailing lists to be used within EGI-Engage project:
    • egi-engage-po@egi.eu: EGI-Engage project office
    • egi-engage-cb@mailman.egi.eu: SSO based. Collaboration Board
    • egi-engage-financial@mailman.egi.eu: SSO based. For discussion of project administration and financial aspects
    • egi-engage-pmb@mailman.egi.eu: SSO based. Project Management Board (to be populated)
    • egi-engage-amb@mailman.egi.eu: SSO based. Activity Management Board members - composed of WP leaders.
    • egi-engage-members@mailman.egi.eu: SSO based. Includes all members of the project including people registered to EGI-Engage-related mailing lists
    • For work packages: SSO based
    • Dedicated Task mailing lists can be found on WP wiki pages - WP leader is responsible to decide how many and which one mailing lists are necessary to run efficiently the workpackage.
  • Requirement and actions gathering
    Requirements and actions gathering should be performed through EGI RT system
  • Surveys
    All surveys created and circulated by the project should be created and kept in EGI survey monkey account.
  • Websites
    www.egi.eu is the main website for the project. A dedicated set of project pages is being prepared. It is used mainly for all ‘official’ ‘static’ content. http://www.egi.eu/about/egi-engage/
    The wiki wiki.egi.eu should 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 plan 
    • metrics
      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.

Templates

All EGI-Engage templates can be found under http://www.egi.eu/about/logo_templates/index.html

Acknowledgement

Proper acknowledgement statements should be used for EGI-Engage outputs unless the output already uses one of the recognised project templates, where appropriate acknowledgements are already included.


Software and Services

Quality of services produced within EGI-Engage project will be ensured by the adoption of the EGI Services management standard FitSM, a international standard developed by the FedSM project.


The software produced within the project will follow the well established Software provisioning process that has been adopted since 2010, based on the definition of quality criteria, quality verification and software validation in a controlled production environment of the federated EGI infrastructure.

The development activities within the project will augment capabilities of existing open source software. The resulting software code, tools and interfaces developed as part of EGI-Engage will be released as open source code and the full access will be provided via publicly available source code repositories such as GitHub, SourceForge, Subversion (SVN), Concurrent Version System (CVS) etc. Software developers will be able to choose their preferred source code repository to better integrate with existing practices, nevertheless they will need to

  • ensure that the contribution is openly accessible,
  • add the metadata information needed to enable reuse,
  • communicate the URL to the consortium.

In order to comply with the open access policy and maximise possibility for reuse of results, EGI-Engage software code, tools and interfaces that fall under the joint ownership will be published under an OSI-approved license . If no existing OSI license is being used, we propose the adoption of the Apache 2.0 license. Free and unrestricted access to research result is a measurable barrier to uptake by SME’s and can slow down innovation in measurable terms , and the consortium will make it a priority to comply with the Horizon 2020 Mandate in full support of Europe 2020 Initiative’s Economic Growth Agenda.

All software created by EGI-Engage project should be listed and described (license, source code repository, copyright owner) under Software Copyrights and Licenses


Other

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

Document management

All documents, presentations and other material that form an official output of the project (not just milestones and deliverables) are placed in the document repository to provide a managed central location for all material.


Content

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: EGI-Engage is co-funded by the Horizon 2020 Framework Programme  of the European Union under grant number 654142

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.


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-Engage-<DOCUMENT IDENTIFIER>-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. M1.2, M5.4, 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.

Versioning rule:

  • +0.1 – new version of draft
  • +1.0 – new version of approved document


Example: EGI-Engage-M3.1-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: M3.1 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 M1.1. 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
  • 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.



Glossary

Review process for deliverables and milestones

All deliverables and milestones should be a subject of review. Depending of the type of milestone and deliverable different inputs to the process are required.
Depending of the type of milestone and deliverable, different inputs to the process are expected and required as detailed in the following list.

  • R: Document, report
    • Input: full report
  • DEM: Demonstrators, pilots, prototypes, plan design
    • Input: Delivery of the product, short 1-4 page report
  • DEC: Website, press & media actions, events
    • Input: Delivery of the product, short 1-4 page report
      • Events: in addition feedback on satisfaction is provided
  • OTHER: software, technical diagram etc.
    • Non-user facing software
      • Input: delivery, UMD software provisioning process , short 1-4 report based on the staged rollout process outcome
    • User facing software
      • Input: delivery, feedback on satisfaction is provided, short 1-4 page report
    • Other
      • Input: short 1-4 page report


Classification to the one of above category will be a subject of discussion during AMB meetings.


Roles

Reviewer: Responsible for providing a review of the document on the EGI review form so that responses from the document authors to the reviewer can be tracked. A change tracked version of the document can be provided with corrections for spelling, formatting and other minor issues. The reviewer is generally from the activity and organisation that is not responsible for producing the document.

Moderator: Responsible for deciding in cases of conflicting reviews, which elements of a review must be implemented by the author. The decision to follow or reject a reviewer’s comment must be tracked in the review document. The moderator is normally an EGI-Engage taskleader not from the activity producing the document. Moderator is also reviewer.

Editor: Coordinating work of document authors, in charge to collect and process the reviews and involve the authors to apply the changes and communicate with the reviewers. The person from the activity and the partner who is responsible for the document. They may rely on others within the activity to provide the information. The editor cannot be a moderator or reviewer. 

Quality Manager (QM): The project office provides administrative support for the process.

Shepherd: The shepherd is a member of the AMB who is responsible for overseeing the production of the document. They will work with the Editor to ensure that the work is done in a timely manner, and report to the AMB on its progress. Normally the activity manager or their deputy.

AMB Chair: This is Technical Director, or their deputy.

[NOTE: an individual could hold one or more of these roles if they are not in conflict with each other.]

Review Process

The review process is identical for milestones and deliverables except for:

  • Milestones
    • are expected to have 2 reviews – from the moderator and reviewer - 1 external, 1 AMB member.
    • are not delivered to the EC
  • Deliverables
    • are expected to have 3 reviews – from two reviewers and the moderator - 1 external, 1 PMB member, 1 AMB member.

The reviewers are drawn (one from each of EGI’s functional areas not involved in its production) from EGI’s functional areas (i.e. Operations, User Community, Technology and Policy).

Process (short version):

  • 7 weeks ahead – ToC
  • 5 weeks ahead – Draft Complete
  • START: 4 weeks ahead - END: 2 weeks ahead – Start Review
  • 2 weeks ahead – At AMB and PMB
  • 1 week ahead – At QM/AMB Chair
  • at EC

Process (full version):

Time before submission Person Action RT Action
>2 months
QM
Assign ticket in EGI RT to WP leader responsible for the document
Assigned to WP leader
2 months Shepherd Assign Editor
Remains blank with CC to editor
7 weeks Shepherd
  • ensure the editor has provided an annotated table of contents
  • create an entry in DocDB for the document


Set state to ToC
6 weeks Shepherd Shepherd is aware a draft
  • is available in the repository
  • is under active development with revisions from the contributors
Set state to Draft
5 weeks Shepherd

The draft is stable and undergoes review within the activity

Set state to Internal Review
4 weeks Shepherd The document is ready for external review.

Set state to External Review

Immediately Editor
  • notifies reviewer(s), moderator and AMB and PMB (via AMB chair) that the document is available for review
  • confirm expected review completion date with reviewers

Please use

Enter completion date as Due Date in RT
Immediately Editor
  • Collect reviews and create entry in DOC DB for the review forms
  • Apply changes
  • Involve Moderator in case of conflicting reviews.
Set state to Being Revised
Immediately Editor Notify the Shepherd an updated document is available Set state to External Review
Immediately Shepherd

The external review is complete.

Notify the AMB and PMB that the document has completed external review

Set state to AMB Review
1 week QM/AMB Chair A clean PDF version of the document is generated by the QM and placed in the document repository with updated meta-data Set state to Final
Deadline AMB Chair
Document is delivered to the EC Set state to With EC


Guidelines for editors

While creating Deliverable and Milestones Editor should remember to:

  • Language set in the document should be English (U.K)
  • Use change tracking
  • Mandatory field (Executive summary, Introduction)
  • Once document reach review step use always last version from Document DB
  • References preferably in the footer as footnote

QA internal resources