Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC-1: Fix a typo and add consistent empty line after every heading #262

Merged
merged 2 commits into from
Sep 12, 2024
Merged

RFC-1: Fix a typo and add consistent empty line after every heading #262

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6ba58f4
RFC-1: Fix a typo and add consistent empty line after every heading
yarikoptic Sep 11, 2024
c3cdfef
One more spotted typo fix
yarikoptic Sep 11, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 11 additions & 2 deletions rfc/1/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -183,7 +183,7 @@ will merge it as a record of the fact that the suggestion has been made, and
it will then become available on https://ngff.openmicroscopy.org.

**Endorsers** are non-**Author** supporters of an RFC, listed in a table within the RFC.
**Reviewers** who have given an "Accept" recommendation and **Implementers** are also also considered **Endorsers**.
**Reviewers** who have given an "Accept" recommendation and **Implementers** are also considered **Endorsers**.

**Editors** are responsible for facilitating all parts of the RFC process.
They identify whether a PR should or should not follow the RFC process,
Expand Down Expand Up @@ -212,7 +212,7 @@ The RFC process can be represented as a state diagram with the various stakehold

![State diagram of the RFC process](./diagram.png)

**Figure 2. State digram of the RFC process.** The RFC text will refer frequently to this diagram. Readers may want to familiarize themselves with it at this point.
**Figure 2. State diagram of the RFC process.** The RFC text will refer frequently to this diagram. Readers may want to familiarize themselves with it at this point.
Identifiers such as "D1", "R2", "S3", refer to individual steps.

### Legend
Expand Down Expand Up @@ -389,21 +389,25 @@ specification will be slotted into a release version by the **Editors** and the
> 📂 Two released implementations required for being adopted.

## Policies

This section defines several concrete aspects of the RFC process not directly related to the state diagram above. These policies are referred to by section title elsewhere in the document for clarification. They also provide extension points in RFC-1 which may later be amended by separate RFCs. If so, those sections will be marked as deprecated and a reference made to the new RFC.

### Decision-making

Unless otherwise specified in the text, the following considerations are taken
into account when making decisions regarding RFCs:
- **prefer working examples**: whether an implementation of an RFC or a failing test which exposes an issue in a proposal, working examples will tend to carry more weight in decision making.
- **technical expertise**: all other considerations being equal, feedback from stakeholders with more technical expertise in a matter under consideration will tend to carry more weight in decision making.
- **newcomer advantage**: care will be taken not to let existing implementations overly dictate the future strategic direction of NGFF in order to avoid premature calcification.

### RFC Prioritization

RFCs are welcome from the community as a way to contribute to the public record of NGFF. It is **not** a goal to explicitly limit the number of RFCs and they need not only include specification changes. (See [this list of RFCs](https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for_Comments) for comparison.)

That being said, not every RFC MUST be sent to **Reviewers**. Priority will be given to RFCs which move the specification forward followed by RFCs which address non-specification concerns of the community like the process itself.

### Choice of Reviewers

Where possible, **Reviewers** SHOULD be chosen to represent a cross-section of the community. Which cross-sections are chosen MAY depend on a given RFC but might include geographic distributions, the variety of imaging modalities, and/or programming languages of the expected implementations. An attempt MUST also be made to select both positive and negative voices from the community.

### Deadline enforcement
Expand All @@ -419,6 +423,7 @@ The **Editors**, however will endeavor to:
**Authors** and **Reviewers** are encouraged to be open and honest, both with themselves and the other members of the process, on available time. A short message stating that an edit or a review will not occur on deadline or even at all is preferable to silence.

### Implementation requirements

The process description describes “sufficient endorsement” in two locations, once for when an RFC can move into the [SPEC phase](#spec) and once when it can be considered “adopted”. This policy describes the current definition of “sufficient”, which is currently kept minimal with an eye towards updating it in the future.

Under RFC-0, three implementation languages — Javascript, Python, and Java — were considered “reference”, or “required”, for a specification to be complete. This proved a difficult barrier since the implementation teams were not directly funded for work on NGFF.
Expand Down Expand Up @@ -449,6 +454,7 @@ Before an RFC is _adopted_ there are a number of versions of an RFC which are pr
* opening a long-lived “review PR” with a dedicated URL

### Specification Versions

The semantics of versioning for the NGFF specification are not yet sufficiently well-defined. There is currently no clear definition of which parts of the specification, if
any, MUST be implemented by software projects. This has been handled in the
Zarr community by adding a "must understand" flag to extensions to warn
Expand Down Expand Up @@ -486,14 +492,17 @@ model of other RFC-using communities, e.g., IETF's [IAB](https://www.ietf.org/ab
"governing authority".

### Editorial Board

The Editorial Board consists of all current **Editors** and can be reached at \<mailto:[email protected]\>. Josh Moore, as the author of this RFC, is the sole initial member.

This proposal does not try to define how **Editors** are chosen. Therefore, the use of "Editors" in this document is intended as a placeholder. A future RFC will define the selection and removal of editors.

### Editorial Workflow

This proposal also does not define the day-to-day specifics of how **Editors** work. The [Editorial Board](#editorial-board) is encouraged to publish a separate document, e.g. Best Practice Guide, containing the daily or weekly workflow of managing the NGFF process. This document can be more quickly updated than the RFC and can contain updates to GitHub interactions (use of “draft” status, milestones, issues, etc.) and possible automation (reply bots and similar).

## Drawbacks, risks, alternatives, and unknowns

The primary **drawbacks**, **risks**, and **unknowns** of the proposal revolve
around the cost that the process will place on those participating in it. This
equally points to the primary **alternative** which is to not have such a
Expand Down
Loading