The SafeTogether Editorial Process

Committee Draft,

This version:
https://safe-together.github.io/specification/process/
Issue Tracking:
GitHub
Editor:
(g0v-it core team)

Abstract

This document is a description about how changes to the specifications in the SafeTogether Ecosystem may be proposed and accepted. Anyone may participate in this process.

Status of This Document

This document is an incomplete draft. The information in this document is still subject to change.

Anyone may participate in this process. Please read the § 3 Code of Conduct.

You are invited to contribute any feedback, comments, or questions you might have.

1. How to Make Changes

This section details how changes to the SafeTogether Specification may be drafted, proposed, and accepted by the community of the Editors

Anyone may submit a proposal to alter this process.

2. Drafting proposals

Anyone may propose improvements to the SafeTogether Specification. Here are some examples of different ways to contribute:

Proposals for substantive changes to the SafeTogether Specification go through an editorial review process. A change is considered substantive when it alters the normative text of the SafeTogether Specification or the SafeTogether Roadmap. Any proposal must be realistic and reasonable to implement, preferably with example implementations, and demonstrable support from implementers.

Any proposal should also be accompanied with a reasonable explanation of the need for the proposed change. For example:

A draft proposal often involves public discussion before being formally presented for review. After these discussions have occurred and a draft proposal has reached a sufficient level of maturity, t should be presented as a candidate proposal, asking stakeholders and panels if there are any major objections.

When there are objections, notify the safetogether panels and stakeholders about the final proposal with an invitation to vote. If there are options, detail them along with the implications of the options. The final proposal needs to be open for one week to give others a chance to vote. To show your support for a proposal write +1. To show your disapproval for a proposal write -1 along with a detailed reason for the disapproval and a suggestion for a preferred alternative. To abstain type 0 when you have no opinion. If you do not vote by the end of the week it will be assumed that you abstain. At the end of the week anyone may publish an overview of the vote results per safetogether Panel and Stakeholder.

The Editorial Team is comprised of all the Editors. Anyone may apply to be an Editor, and must include one or more requested editorial assignments as part of their application. These requests are reviewed by other Editors Editor applications that can demonstrate the support of a relevant panel or group of community members will be favorably considered.

3. Code of Conduct

Personal threats or discriminatory threats towards arbitrary groups or Community Group call and mailing list may result in a ban of the threatening individual.

Repeated and sustained straying from the defined aims of the communication channels may result in a ban of those individuals straying from those defined aims.

3.1. General Expectations

Below are some general expectations around how participants of the community are encouraged to behave.

Participants in the community are expected to behave professionally and respectfully. This community is committed to maintain a positive and constructive community while helping to build SafeTogether. This commitment calls for a community where participants behave according to the rules of the following Code of Conduct:

3.2. Best Practices

Best practices for the Community include:

Based on:

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119