User Tools

Site Tools


erratasystem:rethink

Criteria for a successful errata system

  1. visually and through metadata differentiate between levels of usefulness for an implementer/reader.
    1. or, possibly another way to say that, more clearly differentiates between editorial and technical things implementors may need to care about
  2. shouldn’t be a PITA to use
  3. should not be a path for people to change WG consensus

Other critical points:

  1. 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.
  2. level of effort is a consideration, both on the part of the RPC and the community, but it is only one criteria.
  3. editorial errata and EFL issues may tie together, but that’s hard for this group to really understand without more information
  4. a system that allows for modding of technical reports seems to have consensus

Discussion

Proposal 1

Replace the concept of errata with a system that would allow anyone to comment on an RFC, with the RFC Editor or stream controllers to mark some concepts as important. The 'errata system' would be a system of comments, not a system of discretely managed items. Comments that stream controllers (or their delegates) mark as important could then be shown through an “errata” link. Alternatively, there could be a general 'mod up/down' [1] system that anyone with a datatracker account could use to indicate the importance of the entry. The RFC Editor could handle unambiguous typos

[1] http://en.wikipedia.org/wiki/Modding

Proposal 2

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

  • Who decides if the submission path is correct?
  • 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

erratasystem/rethink.txt · Last modified: 2015/02/06 09:41 by rsewikiadmin