NetarchiveSuite|
Size: 14211
Comment:
|
Size: 14594
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| The !NetarchiveSuite bug/feature-request/patch registration is done by '''''trackers''''' in GForge (https://gforge.statsbiblioteket.dk/tracker/?group_id=7) The trackers are explained in three different ways: 1. via the tracker reporting process [[BR]] ... 1. via overview of fields for different trackers [[BR]] this includes what is displayed and editable both for user logged in and not logged in to GForge 1. via description of all fields that can appear in any tracker [[BR]] this includes explanation of field, description of possible values and default values. There are some differences between order of fields to be set for bugs, feature requests and patches respectively. Furthermore it may be that some of the fields are not included in all trackers. In the following these will be marked as: Values are marked with [TODO: For Version field, we need to find out whether this field should be used more extensively and what the rules then are for trackers found at reviews, in test, in production, in Scotland or somewhere else] |
The !NetarchiveSuite bug/feature-request/patch registration is done by '''''tracker issues''''' in GForge (https://gforge.statsbiblioteket.dk/tracker/?group_id=7) The tracker issues are explained in three different ways: 1. via the tracker issue reporting process [[BR]] ... 1. via overview of fields for different tracker issues [[BR]] this includes what is displayed and editable both for user logged in and not logged in to GForge 1. via description of all fields that can appear in any tracker issue [[BR]] this includes explanation of field, description of possible values and default values. There are some differences between order of fields to be set for bugs, feature requests and patches respectively. Furthermore it may be that some of the fields are not included in all tracker issues. In the following these will be marked as: Values are marked with [TODO: For Version field, we need to find out whether this field should be used more extensively and what the rules then are for tracker issues found at reviews, in test, in production, in Scotland or somewhere else] |
| Line 24: | Line 24: |
| [TODO: Remind tracker to report name if they are not users] [TODO: Remind users to indicate "tracker status" for external trackers (they can only see open closed status)] [TODO: Write work-around for non-users, if log-files where not attached when creating the tracker] [TODO: Write tracker life-cycle] = Tracker Life-cycle = <to be written> = Tracker Reporting Process = |
[TODO: Remind tracker issue creater to report name if they are not users] [TODO: Remind users to indicate "tracker issue status" for external tracker issues (they can only see open closed status)] [TODO: Write work-around for non-users, if log-files where not attached when creating the tracker issue] [TODO: Write tracker issue life-cycle] = Tracker issue Life-cycle = <to be written> = Tracker issue Reporting Process = |
| Line 53: | Line 53: |
| = Tracker implementation process = | = Tracker issue implementation process = |
| Line 63: | Line 63: |
| = Overview of fields for different trackers = | = Overview of fields for different tracker issues = |
| Line 67: | Line 67: |
| For each tracker following is noted per field: * [new] if the field can be edited at the creation time of the tracker * [edit] if the field can be edited in updates of the tracker |
For each tracker issue following is noted per field: * [new] if the field can be edited at the creation time of the tracker issue * [edit] if the field can be edited in updates of the tracker issue |
| Line 73: | Line 73: |
| ||<tablewidth="645px" tableheight="824px">'''Tracker Fields''' ||'''Bugs''' ||'''Feature''' ||'''Patches''' || | ||<tablewidth="645px" tableheight="824px">'''Tracker issue Fields''' ||'''Bugs''' ||'''Feature''' ||'''Patches''' || |
| Line 94: | Line 94: |
| For each tracker following is noted per field: | For each tracker issue following is noted per field: |
| Line 99: | Line 99: |
| ||''' Tracker Fields ''' ||||<style="text-align: center;"> '''View of existing ''' ||||<style="text-align: center;">'''Creation of new ''' || | ||''' Tracker issue Fields ''' ||||<style="text-align: center;"> '''View of existing ''' ||||<style="text-align: center;">'''Creation of new ''' || |
| Line 119: | Line 119: |
| = Tracker fields description = In this section all fields that can appear in a bug/feature-request/patch (from here called tracker) is listed and explained. The fields are listed in alphabetic order. |
= Tracker issue fields description = In this section all fields that can appear in a bug/feature-request/patch (from here called tracker issue) is listed and explained. The fields are listed in alphabetic order. |
| Line 123: | Line 123: |
| The person the tracker is assigned to. That means it is this person that will be responsible for next action on the tracker (except from points where QA needs to take action). A tracker can be assigned to a person either via the module specification which each has a responsible person. Or it can be assigned by the person themselves, in case they want to take it, or it can be reassigned by the already assigned person or QA. * '''Nobody '''in case the tracker is not assign to anybody ''(default value)''' ''' '' |
The person the tracker issue is assigned to. That means it is this person that will be responsible for next action on the tracker issue (except from points where QA needs to take action). A tracker issue can be assigned to a person either via the module specification which each has a responsible person. Or it can be assigned by the person themselves, in case they want to take it, or it can be reassigned by the already assigned person or QA. * '''Nobody '''in case the tracker issue is not assign to anybody ''(default value)''' ''' '' |
| Line 132: | Line 132: |
| Log of changes already made to the tracker. | Log of changes already made to the tracker issue. |
| Line 135: | Line 135: |
| The data type tells whether it is a bug, a feature request or a patch. For new bugs/feature-requests/patches, it is automatically set to the selected tracker | The data type tells whether it is a bug, a feature request or a patch. For new bugs/feature-requests/patches, it is automatically set to the selected tracker type |
| Line 143: | Line 143: |
| The date when the tracker was submitted is automatically set and given on form YYYY-MM-DD HH:MM. | The date when the tracker issue was submitted is automatically set and given on form YYYY-MM-DD HH:MM. |
| Line 146: | Line 146: |
| The detailed description adds information as basis for planning and doing resolution of the tracker. This information must be provided as detailed as possible at the time of registering the tracker. Furthermore it is used to add information at later stages. Additional comments must be entered via the 'OR Attach A Comment' field and they will then appear in the 'Followup' field.''' ''' | The detailed description adds information as basis for planning and doing resolution of the tracker issue. This information must be provided as detailed as possible at the time of registering the tracker issue. Furthermore it is used to add information at later stages. Additional comments must be entered via the 'OR Attach A Comment' field and they will then appear in the 'Followup' field.''' ''' |
| Line 150: | Line 150: |
| * a detailed description of what the tracker is about''' ''' | * a detailed description of what the tracker issue is about''' ''' |
| Line 155: | Line 155: |
| If the tracker is a duplicate then the number of the tracker that it is a duplicate of is written here. The status must then be set to Duplicate.''' ''' | If the tracker issue is a duplicate then the number of the tracker issue that it is a duplicate of is written here. The status must then be set to Duplicate.''' ''' |
| Line 158: | Line 158: |
| List of files already attached to the tracker. | List of files already attached to the tracker issue. |
| Line 161: | Line 161: |
| List of additional comments to 'Detailed description' of the tracker. See also explanation of the 'Detailed Description' field. | List of additional comments to 'Detailed description' of the tracker issue. See also explanation of the 'Detailed Description' field. |
| Line 167: | Line 167: |
| This module field '''''must''''' be set in order to have the tracker directed to the correct tracker owner. | This module field '''''must''''' be set in order to have the tracker issue directed to the correct tracker issue owner. |
| Line 182: | Line 182: |
| The priority can only be changed by QA in cooperation with the daily production manager. The priority is basis for planning resolution order of tracker and which procedures can be used in order to have fixes quickly patched into the production environment. | The priority can only be changed by QA in cooperation with the daily production manager. The priority is basis for planning resolution order of tracker issue and which procedures can be used in order to have fixes quickly patched into the production environment. |
| Line 191: | Line 191: |
| The status tells where the tracker is in the implementation process, thus it '''''must be set during process''''' of implementation of the tracker. Resolution values for '''''bugs''''' and '''''feature requests''''' which '''''must be set during process''''' of treating the tracker |
The status tells where the tracker issue is in the implementation process, thus it '''''must be set during process''''' of implementation of the tracker issue. Resolution values for '''''bugs''''' and '''''feature requests''''' which '''''must be set during process''''' of treating the tracker issue |
| Line 196: | Line 196: |
| * '''Need Info''' [[BR]] The tracker needs additional information before it can be evaluated. Information about what sort of information is needed must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment') * '''Evaluated''' [[BR]] if the tracker is evaluated for when the tracker can be implemented. For '''''bugs '''''and '''''feature requests''''' an estimate must be made as preparation for prioritisation. This estimate must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). For '''''patches''''' the result of the evaluation must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). * '''In progress''' [[BR]] if the tracker is being implemented. That means the process of programming, documentation, unit test development and code reviews has started and no other developer should interfere without coordinating first. * '''Fixed''' [[BR]] if the tracker is implemented with source and unit tests checked into GForge, and after sanity test and code review. Note that the description of how it is implemented and check e.g. in unit test must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). * '''Fixed, Passed QA''' [[BR]] if QA has accepted the tracker as fixed/implemented. Only QA must change to this status. Before a release test all trackers included must have this status before the release test can start. * '''Fixed, Released''' [[BR]] if the tracker has been release tested and the implementation is part of a stable release. * '''Duplicate''' [[BR]] if the tracker was already registered and therefore are duplicate of another tracker. The duplicate tracker number must then be noted in the 'Duplicate Of' field. * '''Invalid''' [[BR]] if the tracker is not valid as a bug or feature request, e.g. if it was caused by wrong use of the system * '''Won’t fix''' [[BR]] if it is decided not to implement the tracker ever, for instance if the behavior described in a bug is the intended behavior of the system or if a patch is not to be included. A reason for this status must be noted in the Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). |
* '''Need Info''' [[BR]] The tracker issue needs additional information before it can be evaluated. Information about what sort of information is needed must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment') * '''Evaluated''' [[BR]] if the tracker issue is evaluated for when the tracker issue can be implemented. For '''''bugs '''''and '''''feature requests''''' an estimate must be made as preparation for prioritisation. This estimate must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). For '''''patches''''' the result of the evaluation must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). * '''In progress''' [[BR]] if the tracker issue is being implemented. That means the process of programming, documentation, unit test development and code reviews has started and no other developer should interfere without coordinating first. * '''Fixed''' [[BR]] if the tracker issue is implemented with source and unit tests checked into GForge, and after sanity test and code review. Note that the description of how it is implemented and check e.g. in unit test must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). * '''Fixed, Passed QA''' [[BR]] if QA has accepted the tracker issue as fixed/implemented. Only QA must change to this status. Before a release test all tracker issues included must have this status before the release test can start. * '''Fixed, Released''' [[BR]] if the tracker issue has been release tested and the implementation is part of a stable release. * '''Duplicate''' [[BR]] if the tracker issue was already registered and therefore are duplicate of another tracker issue. The duplicate tracker issue number must then be noted in the 'Duplicate Of' field. * '''Invalid''' [[BR]] if the tracker issue is not valid as a bug or feature request, e.g. if it was caused by wrong use of the system * '''Won’t fix''' [[BR]] if it is decided not to implement the tracker issue ever, for instance if the behavior described in a bug is the intended behavior of the system or if a patch is not to be included. A reason for this status must be noted in the Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). |
| Line 207: | Line 207: |
| The initials of the person which the tracker is submitted by are automatically set. | The initials of the person which the tracker issue is submitted by are automatically set. |
| Line 210: | Line 210: |
| The summary consists of a short description of the tracker. The summary is used when an overview of tracker is made. This information must''' '''be provided when the tracker is registered.''' ''' | The summary consists of a short description of the tracker issue. The summary is used when an overview of tracker issue is made. This information must''' '''be provided when the tracker issue is registered.''' ''' |
| Line 216: | Line 216: |
| The version field is '''''only used''''', when it is critical in order to understand the tracker or reproduce a bug. Version of code that the tracker relates to. This means that it '''''must''''' be set for patches, since these will include code that need to be compatible with the rest of the code. | The version field is '''''only used''''', when it is critical in order to understand the tracker issue or reproduce a bug. Version of code that the tracker issue relates to. This means that it '''''must''''' be set for patches, since these will include code that need to be compatible with the rest of the code. |
title(Bug/Feature Request/Patch Information Guideline)
Introduction
The NetarchiveSuite bug/feature-request/patch registration is done by tracker issues in GForge (https://gforge.statsbiblioteket.dk/tracker/?group_id=7)
The tracker issues are explained in three different ways:
via the tracker issue reporting process BR ...
via overview of fields for different tracker issues BR this includes what is displayed and editable both for user logged in and not logged in to GForge
via description of all fields that can appear in any tracker issue BR this includes explanation of field, description of possible values and default values. There are some differences between order of fields to be set for bugs, feature requests and patches respectively. Furthermore it may be that some of the fields are not included in all tracker issues. In the following these will be marked as: Values are marked with
[TODO: For Version field, we need to find out whether this field should be used more extensively and what the rules then are for tracker issues found at reviews, in test, in production, in Scotland or somewhere else]
[TODO: For Status, check what invalid means for patches????]
[TODO: For Monitor value of Module field find better description]
[TODO: Write reporting processes]
[TODO: Write implementation processes]
[TODO: Remind tracker issue creater to report name if they are not users]
[TODO: Remind users to indicate "tracker issue status" for external tracker issues (they can only see open closed status)]
[TODO: Write work-around for non-users, if log-files where not attached when creating the tracker issue]
[TODO: Write tracker issue life-cycle]
Tracker issue Life-cycle
<to be written>
Tracker issue Reporting Process
time when information should be updated, by who and when ... <to be written>
Reporting a Bug
Choose the Bug Tracker in case you want to report a bug which should be implemented as a fix in NetarchiveSuite.
include logs
... <to be written>
Reporting a Feature Request
Choose the Feature Request Tracker in case you want to report a feature request which you would like to have implemented in NetarchiveSuite. The rest of the process is the same as for Bugs, please refer to the Reporting a Bug section.
Reporting a Patch
Choose the Patch Tracker in case you want to report a patch to inclusions in NetarchiveSuite.
... <to be written>
Tracker issue implementation process
time when information should be updated, by who and when ... <to be written>
Implementing/fixing a Bug
<to be written>
Implementing a Feature Request
<to be written>
Implementing/including a Patch
<to be written>
Overview of fields for different tracker issues
Display and edit ability of fields depends on whether you have a login to GForge. Therefore the overview is given for both cases.
Overview for users logged on GForge
For each tracker issue following is noted per field:
- [new] if the field can be edited at the creation time of the tracker issue
- [edit] if the field can be edited in updates of the tracker issue
- [auto] if the field is automatically set by the system without possibility to change it
- - if not present
Tracker issue Fields |
Bugs |
Feature |
Patches |
Assigned To: |
[new, edit] |
[new, edit] |
[new, edit] |
Attach Files: |
[new, edit] |
[new, edit] |
[new, edit] |
Change Log: |
[auto] |
[auto] |
[auto] |
Data Type: |
[edit] |
[edit] |
[edit] |
Date Submitted: |
[auto] |
[auto] |
[auto] |
Detailed description: |
[new, edit] |
[new, edit] |
[new, edit] |
Duplicate Of: |
[new, edit] |
[new, edit] |
[new, edit] |
Existing Files: |
[edit] |
[edit] |
[edit] |
Followup: |
[auto] |
[auto] |
[auto] |
For project: |
[auto] |
[auto] |
[auto] |
Module: |
[new, edit] |
[new, edit] |
[new, edit] |
OR Attach A Comment: |
[edit] |
[edit] |
[edit] |
Priority: |
[new, edit] |
[new, edit] |
[new, edit] |
Status: |
[new, edit] |
[new, edit] |
[new, edit] |
Submitted By: |
[auto] |
[auto] |
[auto] |
Summary: |
[new, edit] |
[new, edit] |
[new, edit] |
Use Canned Response: |
[edit] |
[edit] |
[edit] |
Version: |
[new, edit] |
[new, edit] |
[new, edit] |
Overview for users NOT logged on GForge
For each tracker issue following is noted per field:
- [editable] if the field can be edited
- [locked] if the field is locked for a person not logged into GForge
- - if not present
Tracker issue Fields |
View of existing |
Creation of new |
||
Assigned To: |
Assigned To: |
[locked] |
- |
- |
Attach Files: |
Attach Files: |
[locked] |
Attach Files: |
[editable] |
Change Log: |
Changes: |
[locked] |
Not applicable |
Not applicable |
Data Type: |
(in header) |
[locked] |
(in header) |
[locked] |
Date Submitted: |
Date: |
[locked] |
Not applicable |
Not applicable |
Detailed description: |
Detailed description: |
[locked] |
Detailed description: |
[editable] |
Duplicate Of: |
- |
- |
Duplicate Of: |
[editable] |
Existing Files: |
Attached Files: |
[downloadable] |
Not applicable |
Not applicable |
Followup: |
Followup: |
[locked] |
Not applicable |
Not applicable |
For project: |
Not applicable |
Not applicable |
For project: |
[locked] |
Module: |
- |
- |
Module: |
[editable] |
OR Attach A Comment: |
Add a Comment: |
[editable] |
- |
- |
Priority: |
Priority: |
[locked] |
- |
- |
Status: |
State: |
[locked] only shows open or closed |
Status: |
Status: |
Submitted By: |
Submitted By: |
[locked] |
- |
- |
Summary: |
Summary: |
[locked] |
Summary: |
[editable] |
Use Canned Response: |
- |
- |
- |
- |
Version: |
- |
- |
Version: |
Version: |
Tracker issue fields description
In this section all fields that can appear in a bug/feature-request/patch (from here called tracker issue) is listed and explained. The fields are listed in alphabetic order.
Assigned To: [new, edit]
The person the tracker issue is assigned to. That means it is this person that will be responsible for next action on the tracker issue (except from points where QA needs to take action). A tracker issue can be assigned to a person either via the module specification which each has a responsible person. Or it can be assigned by the person themselves, in case they want to take it, or it can be reassigned by the already assigned person or QA.
Nobody in case the tracker issue is not assign to anybody (default value)
The <name> of the person that the bug/enhancement is assign to
Attach Files: [new, edit]
This field offers functionality to add attached files to the list of files under the 'Existing Files' field.
Change Log:
Log of changes already made to the tracker issue.
Data Type: [edit]
The data type tells whether it is a bug, a feature request or a patch. For new bugs/feature-requests/patches, it is automatically set to the selected tracker type
Bugs for bugs
Feature Requests for feature requests
Patches for patches with code sent NetarchiveSuite for inclusion
NOTE: if the data type is changed, there may be some of the values that are not transferred to the new tracker type. These values need to be set again.
Date Submitted:
The date when the tracker issue was submitted is automatically set and given on form YYYY-MM-DD HH:MM.
Detailed description: [new, edit]
The detailed description adds information as basis for planning and doing resolution of the tracker issue. This information must be provided as detailed as possible at the time of registering the tracker issue. Furthermore it is used to add information at later stages. Additional comments must be entered via the 'OR Attach A Comment' field and they will then appear in the 'Followup' field.
The detailed description must include
a detailed description of what the tracker issue is about
- possible resolutions if known
- estimated time for fixing in case the Keywords field includes setting of the ESTIMATED keyword.
Duplicate Of: [new, edit] (not for patches)
If the tracker issue is a duplicate then the number of the tracker issue that it is a duplicate of is written here. The status must then be set to Duplicate.
Existing Files:
List of files already attached to the tracker issue.
Followup:
List of additional comments to 'Detailed description' of the tracker issue. See also explanation of the 'Detailed Description' field.
For project:
The project field in this context is automatically set to NetarchiveSuite.
Module: [new, edit]
This module field must be set in order to have the tracker issue directed to the correct tracker issue owner.
None BR if not set (which it must be before it is assigned to a person) (default value)
Access BR if it concerns the Access (viewerproxy) module
Archive BR if it concerns the Archive module
Common BR if it concerns the Common module
Deploy BR if it concerns the Deploy module
Documentation BR if it concerns the documentation related to NetarchiveSuite
Harvester BR if it concerns the Harvester module
Monitor BR if it concerns monitoring
Test BR if it concerns the test of NetarchiveSuite
OR Attach A Comment: [edit]
This field is used to enter additional comments to the 'Detailed description' field.
Priority: [new, edit]
The priority can only be changed by QA in cooperation with the daily production manager. The priority is basis for planning resolution order of tracker issue and which procedures can be used in order to have fixes quickly patched into the production environment.
Priority 5 (highest): Must be fixed as a patch in current stable release.
Priority 4 : Must be fixed in next stable release.
Priority 3 : Should be fixed in next stable release. (Default value)
Priority 2 : Not planned in next stable release.
Priority 1 (lowest): Not expected to be fixed.
Status: [new, edit]
The status tells where the tracker issue is in the implementation process, thus it must be set during process of implementation of the tracker issue.
Resolution values for bugs and feature requests which must be set during process of treating the tracker issue
New BR if new and not set (Default value)
Need Info BR The tracker issue needs additional information before it can be evaluated. Information about what sort of information is needed must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment')
Evaluated BR if the tracker issue is evaluated for when the tracker issue can be implemented. For bugs and feature requests an estimate must be made as preparation for prioritisation. This estimate must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment'). For patches the result of the evaluation must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment').
In progress BR if the tracker issue is being implemented. That means the process of programming, documentation, unit test development and code reviews has started and no other developer should interfere without coordinating first.
Fixed BR if the tracker issue is implemented with source and unit tests checked into GForge, and after sanity test and code review. Note that the description of how it is implemented and check e.g. in unit test must be noted in the 'Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment').
Fixed, Passed QA BR if QA has accepted the tracker issue as fixed/implemented. Only QA must change to this status. Before a release test all tracker issues included must have this status before the release test can start.
Fixed, Released BR if the tracker issue has been release tested and the implementation is part of a stable release.
Duplicate BR if the tracker issue was already registered and therefore are duplicate of another tracker issue. The duplicate tracker issue number must then be noted in the 'Duplicate Of' field.
Invalid BR if the tracker issue is not valid as a bug or feature request, e.g. if it was caused by wrong use of the system
Won’t fix BR if it is decided not to implement the tracker issue ever, for instance if the behavior described in a bug is the intended behavior of the system or if a patch is not to be included. A reason for this status must be noted in the Detailed description' field or in the 'Followup' field (via 'OR Attach A Comment').
Submitted By:
The initials of the person which the tracker issue is submitted by are automatically set.
Summary: [new, edit]
The summary consists of a short description of the tracker issue. The summary is used when an overview of tracker issue is made. This information must be provided when the tracker issue is registered.
Use Canned Response: [edit]
This field is not used at the moment, and thus should never be set.
Version: [new, edit]
The version field is only used, when it is critical in order to understand the tracker issue or reproduce a bug. Version of code that the tracker issue relates to. This means that it must be set for patches, since these will include code that need to be compatible with the rest of the code.
Default is None.