Changes between Initial Version and Version 1 of RFC/5_Errata

Timestamp:

Mar 19, 2016, 3:08:07 AM (8 years ago)

Author:

marisn

Comment:

First draft of GRASS GIS errata framework

RFC/5_Errata

@@ +1 @@
+[[TOC]]
+= RFC 5: GRASS GIS Errata =
+
+Author of the first draft: Māris Nartišs
+
+Status: Early draft (19 Mar 2016)
+
+== Introduction ==
+
+GRASS GIS is widely used in scientific, private and government sector. Scientific theories, environmental decisions and actions depend on the outcome of spatial analysis performed with GRASS GIS. Any errors in analytical modules might lead to erroneous conclusions and actions based on them. This RFC provides a framework of documenting and spreading information on analysis inaccuracies caused by errors in GRASS GIS code.
+
+== Overall process ==
+
+1. Any bug reporter or developer can nominate a bug for escalating to GRASS GIS erratum issue. Nomination is done by adding a notice to bug at bug tracker or discussing directly at  developer mailing list. Any nomination is discussed in developer mailing list to gather necessary information on it's scope, impact, causes and solutions.
+
+2. GRASS PSC evaluates nomination based on information provided by bug report, discussion in developer mailing list and/or other sources. PSC makes a final decision if nominated bug matches criteria of issuing a GRASS GIS erratum.
+
+3. A draft of erratum text is made in a designated area of developer wiki (issue tracker) holding texts of all published GRASS GIS errata.
+
+4. After a review of at least one more person, the erratum is marked as final one and spread via communication channels.
+
+=== Evaluation criteria ===
+
+* Bug must be present in an official GRASS GIS release.
+* Bug must cause generation of incorrect analysis results that are not so easy to notice.
+Module crashes or bugs causing easy to identify incorrect results should not be given an erratum. Examples of possible erratum worth bugs are single cell shift of raster result, not enough randomness of expected random module output, loss of output precision due to incorrect floating point handling etc.
+
+=== Content and life cycle of an Erratum ===
+
+GRASS GIS Erratum message should contain following elements:
+* it's number;
+* date of issue;
+* name(s) of affected module(s);
+* information about affected release(s);
+* a short description of problem;
+* steps resulting in incorrect output (i.e. specific input parameter combination);
+* current state of problem (in progress, fixed for release x.y.z);
+* references to bug report (Trac bug number), developer mailing list thread;
+* any other information relevant to erratum.
+
+GRASS GIS errata might receive updates, if it's found to be necessary
+(i.e. notice of fixing issue, issue scope update etc.).
+
+=== Spreading the word ===
+
+All GRASS GIS errata texts should be available at two places - developer wiki (Trac) and ERRATA file of any upcoming release.
+Errata should be listed in time descending order (latest on the top).
+
+If the erratum was based on a bug report in issue tracker, a notice to the issue report should be added.
+
+Announcement of the erratum should be sent out to XXXX mailing list.