RFC: Errata

doc/development/rfc/errata.md

@@ -0,0 +1,70 @@
+# 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.