Difference between revisions of "Documentation Validation procedure"

Revision as of 15:21, 13 March 2013

This page provides information about the procedure that must be followed for the validation of the documentation content and the status of this procedure . This procedure is essential for maintaining high quality documentation in the Administrator's [1], the Developer's [2] and the User's [3] guide. The actors in the procedure are the authors of each section in the aforementioned guides, and the reviewers, which are recipients of the information provided in the content for which they are responsible.

Validation Procedure

Wikidoc Validation

Procedure

Each review process workflow consists of four stages

1. Whenever a documentation section becomes eligible for review, the Review Process Status should be changed from orange (pending) to blue (eligible for review). The Documentation Editor will then open a ticket to the assigned reviewer of the aforementioned section and place a link to that ticket in the Related Ticket column.
2. The assigned reviewer of the section performs the review, classifying this section into APPROVED - MINOR CHANGES - MAJOR CHANGES, and sets one of these three options into the Content Status column. This classification will give an overall estimation for the situation of the given section and will help each author understand how extensive the changes in his content should be. Reviewers should also provide more detailed comments to authors, in order to inform them about parts that have not clear meaning or must be described in more detail, parts that should be extended to broaden their scope and include more information and missing parts. During this first stage of the review process, the Initial Comments column of the Review Process Status field has yellow color (in progress). This stage finishes when the reviewer reassigns the ticket to the author (or the person responsible for the corresponding subsystem if the section is written by more than one authors), to provide him with the detailed comments of his review. The reviewer then changes the Initial Comments column of the Review Process Status field to green (accomplished) and the Address Comments column to yellow (in progress).
3. The author/maintainer(s) of the section must perform the changes needed to address the initial comments of the reviewer. When this stage is completed the latter changes the Address Comments column of the Review Process Status field to green (accomplished) and the Approval column to yellow (in progress).
4. The reviewer of a specific section must check that the changes performed by the author, addressed his comments. Additional comments can be provided to the author by the reviewer, through the open ticket, in order to help the author address the initial comments. When this stage is completed the reviewer must change the Approval column of the Review Process Status field to green (accomplished), place APPROVED into the Content Status column and close the open ticket.

Reasons to Review

A new review for a specific section is indicated by inserting a new line, in one of the tables below, beneath the lines that correspond to previous reviews for this section. The reason for a new review can be:

• An extended change in the contents of a section(if this change involves only a specific subsection of this section then the name of this subsection is placed into the SubSection column). In this case the new line should be inserted by the author of the section, who is also responsible for informing the corresponding reviewer about the initiation of a new review procedure for this section.
• A minor release closure. In this case the responsible for initiating the procedure is the Documentation Editor.
• Some other reason that demands validation of some parts in the three guides.

The reason must be placed into the Reason to review column.

Deadlines

The Due Date depends on the reason for which the review is performed, being 5 weeks in case of a Major Review and 4 weeks in case of a minor release closure. The Initial Comments should be provided to the author by the reviewer in about one weeks' time after the initial ticket creation by the Documentation Editor. The documentation update should be performed in 3 weeks' time in case of a Major Review or other reason and in 2 weeks' time in case of a minor release closure. The final review should be performed in an additional one weeks' time. Each subsequent review/update cycle, if any, should be performed in one weeks' time for each action. In this case, the Due date should be updated accordingly by the reviewer to 2 weeks past the previous date.

If a review process fails to be completed within the Due Date, the reviewer must place the red color (expired) to the appropriate stage in the Review Process Status field. The reviewer can change the Content Status column during the third stage of a review process(i.e. he may decide that a section that needed MAJOR CHANGES, still needs some minor changes after the second stage). If the reviewer considers a section as APPROVED after the first stage, then this review process for this section, is considered to be completed without any actions taken by the author.

Distribution Validation

Description

Distribution validation is an additional documentation validation procedure defined from the distribution point of view instead of the documentation point of view. Its purpose is to complement the Wikidoc Validation procedure by

• Making it easier to identify software lacking documentation
• Facilitating access to documentation by correcting documentation-related issues in the distribution
• Eliminating all possibilities of confusion by ensuring that all documentation links point to the project's current Wiki

The documentation issues are identified by the Documentation Editor and fall into three categories

• Components lacking documentation. This category in turn includes
  • Components for which documentation exists, but don't include a link to that documentation. The expected action for such components is simply to include the link to the existing documentation.
  • Components which contain documentation links pointing to empty documentation pages or sections. The expected action for such components is to produce the required documentation.
  • Components which neither contain documentation links nor there exists documentation for them. The expected action for such components is both to produce the required documentation and to include the link the latter.
• Components containing documentation links pointing to the old Wiki. This is a fairly common distribution issue which can generate confusion, especially when the correct page is updated often. This category includes
  • Components for which a corresponding documentation page or section already exists in the current Wiki. The expected action for such components is simply to update the documentation link included in the component.
  • Components for which a corresponding documentation page or section does not exist in the current Wiki. The expected actions for such components is to produce the required documentation and to update the documentation link included in the component.
• Components containing problematic documentation links. This category includes all components with documentation link issues which cannot be classified into the previous two categories. In this case, a description of the identified issue is included.

Procedure

The procedure workflow consists of three stages

1. The party in charge of the procedure (either the Documentation Editor, or an associate of them) opens a ticket (Type: defect, Defect Category: Documentation) for the issue to the Developer responsible for the component, describing the issue category. The former then changes the Ticket Creation column of the Issue Resolution Status field to green (accomplished) and the Resolution in HEAD column to yellow (in progress).
2. Once the issue is resolved and the corresponding HEAD configuration is updated in ETICS, the Developer updates the ticket in order to notify the party in charge of the procedure of the progress made. The latter then updates the Resolution in HEAD to green (accomplished) and the Component Release column to yellow (in progress). If the changes made do not require a component release, the latter also updates the Component Release to green and closes the ticket, signifying that the procedure was successfully completed.
3. If the changes made require a component release and once the component is released, the Developer updates the ticket in order to notify the party in charge of the procedure and the latter updates the Component Release column to green and closes the ticket, signifying that the procedure was successfully completed.

n Note: The component validation procedure is designed to address mainly distribution-related issues and it is expected that there will be no major overlaps with the Wikidoc Validation procedure. However, if such overlaps occur, the author responsible for the documentation section under review is expected to add a link to the related ticket in order to make the monitoring of the two procedures more efficient as they run simultaneously.

Status of Wikidoc Validation

Developer's Guide

User's Guide

To be filled.

Administrator's Guide

To be filled.

Status of Distribution Validation

Components Lacking Documentation

To be filled.

Components Containing Wikidoc Links Pointing to the Old Wiki

To be filled.

Components Containing Problematic Wikidoc Links

To be filled.