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 "Review process"

From EGIWiki
Jump to navigation Jump to search
Line 1: Line 1:
The formal outputs from the project (milestones and deliverables) will pass through a formal review process. The review process is timed to ensure the output is available to the EC at the end of the project month (PM) that the material is due.
The formal outputs from the project (milestones and deliverables) will pass through a formal review process. The review process is timed to ensure the output is available to the EC at the end of the project month (PM) that the material is due.


The activity manager from the activity that is producing the document is responsible for updating its status in the Request Tracker as it moves through its various stages. This includes:
*'''STEP1'''
*Adding in the document URL form the Document store once it is available.
*Adding the reviewer moderator and reviewers once known
*Updating the ticket history with any additional information relating to delays, problems, etc.


Once the '''author''' has completed the  document, and put his/her name, the activity code and the date in the deliver slip on page 2, it should be uploaded to DocDB with all the metadata filled in. This is when the review process can start.


====[[EU deliverable review procedure|EU deliverable review procedure]]====
*'''STEP2'''
====[[Milestone review procedure|Milestone review procedure]]====


In the next step an RT ticket is created for the document by the '''Quality Officer''' in order to track the status of the document as it passes through the review process. This ticket should include the names of the moderators and reviewers together with the DocDB url(s) for the document itself and the review space.


*'''STEP3'''


Once the review process has been completed, the project office will produce a PDF of the document and upload this to the document repository and submit the material to the EC.
The chosen '''moderators''' and '''reviewers''' are informed by e-mail by the '''Project Office''' about their duty, with a deadline for completing the task and the urls for the document and the feedback form.
 
*'''STEP4'''
 
'''Reviewers''' and '''moderators''' should upload their completed feedback forms to the related Feedback DocDB space (the url for this is always provided in the notification e-mail!). If the '''reviewer''' or '''moderator''' creates a new version of the revised document with comments and/or tracked changes, that should also be uploaded to the feedback space. It should NOT be uploaded by updating the original document. In each case the ‘’Add files’’ option must be used in the DocDB when uploading. '''Reviewers''' should notify the '''moderator''' when the feedback is available.
 
*'''STEP5'''
 
Once the feedback forms are available, the '''author''' should be notified by the '''moderator'''. The '''author''' should check them and provide responses to each of the reviewers’ comments on the feedback forms. The new versions with the responses included should also be uploaded to the DocDB feedback space by the '''author'''. The '''author''' should then include any necessary changes in the main document and produce a new version. This should be be uploaded with major changes tracked to the document space by the '''author'''. The '''author''' should then notify the '''moderator''' that a new version is available. The versions of the document must be recorded to the Document Log (page 2) by the '''author''' again.
 
*'''STEP6'''
 
The''' moderator''' should check the new version and ask the '''reviewers''' to confirm that their comments have been addressed to their satisfaction. If not, a second internal review round may be necessary. If the '''reviewers''' and '''moderator''' are happy, the moderator should notify the '''Quality Officer''', who can then update the ticket to move the document from ‘External Review’ to ‘AMB review’. The '''Quality Officer''' also has to make sure that the Delivery Slip of each document is filled in properly.
 
 
Once the review process has been completed, the '''Project Office''' will produce a PDF of the document and upload this to the document repository and submit the material to the EC.

Revision as of 14:20, 13 October 2010

The formal outputs from the project (milestones and deliverables) will pass through a formal review process. The review process is timed to ensure the output is available to the EC at the end of the project month (PM) that the material is due.

  • STEP1

Once the author has completed the document, and put his/her name, the activity code and the date in the deliver slip on page 2, it should be uploaded to DocDB with all the metadata filled in. This is when the review process can start.

  • STEP2

In the next step an RT ticket is created for the document by the Quality Officer in order to track the status of the document as it passes through the review process. This ticket should include the names of the moderators and reviewers together with the DocDB url(s) for the document itself and the review space.

  • STEP3

The chosen moderators and reviewers are informed by e-mail by the Project Office about their duty, with a deadline for completing the task and the urls for the document and the feedback form.

  • STEP4

Reviewers and moderators should upload their completed feedback forms to the related Feedback DocDB space (the url for this is always provided in the notification e-mail!). If the reviewer or moderator creates a new version of the revised document with comments and/or tracked changes, that should also be uploaded to the feedback space. It should NOT be uploaded by updating the original document. In each case the ‘’Add files’’ option must be used in the DocDB when uploading. Reviewers should notify the moderator when the feedback is available.

  • STEP5

Once the feedback forms are available, the author should be notified by the moderator. The author should check them and provide responses to each of the reviewers’ comments on the feedback forms. The new versions with the responses included should also be uploaded to the DocDB feedback space by the author. The author should then include any necessary changes in the main document and produce a new version. This should be be uploaded with major changes tracked to the document space by the author. The author should then notify the moderator that a new version is available. The versions of the document must be recorded to the Document Log (page 2) by the author again.

  • STEP6

The moderator should check the new version and ask the reviewers to confirm that their comments have been addressed to their satisfaction. If not, a second internal review round may be necessary. If the reviewers and moderator are happy, the moderator should notify the Quality Officer, who can then update the ticket to move the document from ‘External Review’ to ‘AMB review’. The Quality Officer also has to make sure that the Delivery Slip of each document is filled in properly.


Once the review process has been completed, the Project Office will produce a PDF of the document and upload this to the document repository and submit the material to the EC.