Differences

This shows you the differences between two versions of the page.

--- erratasystem:rethink [2015/02/03 00:10] – rsewikiadmin
+++ erratasystem:rethink [2015/02/06 17:41] (current) – rsewikiadmin
@@ Line 1: / Line 1: @@
 ===Criteria for a successful errata system===
-  -  a measure of a successful errata system will be one visually and through metadata differentiate between levels of usefulness for an implementer/reader.
+  -  visually and through metadata differentiate between levels of usefulness for an implementer/reader.
+     -  or, possibly another way to say that, more clearly differentiates between editorial and technical things implementors may need to care about
+  - shouldn’t be a PITA to use
+  - should not be a path for people to change WG consensus
+Other critical points:
+  - RPC to be the gatekeeper for editorial errata; need to have a way to pass through things that look editorial but may have impact on the technical meaning of the text.
+  - level of effort is a consideration, both on the part of the RPC and the community, but it is only one criteria.
+  - editorial errata and EFL issues may tie together, but that’s hard for this group to really understand without more information
+  - a system that allows for modding of technical reports seems to have consensus
+===Discussion===
+[[http://piratepad.net/mqCvFxyR8w]]
 ===Proposal 1===
@@ Line 11: / Line 22: @@
 ===Proposal 2===
-[A]n IETF-operated web site that is preferable to the competition (e.g., tools) and that presents errata of this sort as highlighted in a different color on the presented RFC, rather than as comments that are in a separate visual stream from the presented RFC.   I would like errata to be done similarly, if they are verified by someone who can check whether a new consensus is required to affirm the erratum.
+A single website that presents errata of this sort as highlighted in a different color on the presented RFC, rather than as comments that are in a separate visual stream from the presented RFC.   I would like errata to be done similarly, if they are verified by someone who can check whether a new consensus is required to affirm the erratum.
 ===Process Diagram for errata submission===
@@ Line 19: / Line 31: @@
   * Do we need a portal so that the user has a simpler experience, rather than having to figure out the rules for the bug tracker, modding system, and errata system?
   * How will entries move from one system to another?  E.g., if something is in technical and needs to move to editorial, who hits that switch?  How will all the necessary fields transfer from one system to a completely different system?
+     * At what points in that process do we have to design tools to interface between systems?
   * With multiple publication formats, do all formats get an alternate, corrected version?  Or do we just focus on one of the outputs (example, create a second HTML in a separate location that includes all the approved corrections and links to the modding system?)
   * Is there still value in having the info page link to all the different types of errata (RSE votes yes).
 Note:
 Additional diagrams or descriptions required for the approval processes