From e21589ddf8a317d0930799fcd0b9ebdd44c9305e Mon Sep 17 00:00:00 2001 From: David Stansby Date: Thu, 13 Nov 2025 15:11:02 +0100 Subject: [PATCH 1/2] Add an RFC process document --- rfc/index.md | 17 +- rfc/process.md | 207 +++++++++++++++++++++ rfc/templates/index.md | 9 + rfc/templates/review_template.md | 28 +++ rfc/templates/rfc_template.md | 302 +++++++++++++++++++++++++++++++ 5 files changed, 547 insertions(+), 16 deletions(-) create mode 100644 rfc/process.md create mode 100644 rfc/templates/index.md create mode 100644 rfc/templates/review_template.md create mode 100644 rfc/templates/rfc_template.md diff --git a/rfc/index.md b/rfc/index.md index 79660a17..05030427 100644 --- a/rfc/index.md +++ b/rfc/index.md @@ -13,22 +13,7 @@ the [specifications](../specifications/index), RFCs are referenced to provide readers background reading and additional details. -The RFC process itself is defined as [RFC-1](1/index.md). -Key sections include: - -* [Stakeholders](1/index.md#stakeholders) -* [DRAFT](1/index.md#draft) -* [RFC](1/index.md#rfc) -* [SPEC](1/index.md#spec) -* [Policies](1/index.md#policies) - -If you are interested in submitting an RFC, start with the -introduction under ["Proposal"](1/index.md#proposal). Once you -are convinced that your RFC is on topic, within scope, and -has support from some members of the community, copy the -[RFC template](1/templates/rfc_template) to a new directory -and open a PR. - +The RFC process itself is defined on [the process page](process.md). If there are any questions, please contact the editors under diff --git a/rfc/process.md b/rfc/process.md new file mode 100644 index 00000000..0a1728b7 --- /dev/null +++ b/rfc/process.md @@ -0,0 +1,207 @@ +This document outlines the request for comment (RFC) process, which is used for suggesting discussing and adopting major changes to the OME-Zarr specification. RFC submissions are encouraged from anyone, and are recorded whether they are adopted or not. + +Not all decisions need to follow the RFC process - this is intended primarily for significant and/or breaking changes to the specification or the community process itself. Other changes, bug fixes, etc. are welcome as PRs without a full RFC. If your are unsure whether or not a change requires an RFC, either open an issue or directly contact the OME-Zarr editor to check. + +The majority of the process is currently derived from [RFC-1](https://ngff.openmicroscopy.org/rfc/1/index.html), but future RFCs may (and are encouraged) to update and improve this process. + +## People involved + +- **Authors** are the original creators of individual RFCs. +- **Endorsers** are non-Author supporters of an RFC. +- **Editors** are responsible for facilitating the RFC process. They identify whether a PR should or should not follow the RFC process, choose when a draft is ready to become an RFC, choose reviewers and manage communication between authors and reviewers. Their sole approval of an RFC (taking into account review comments) is one route to accepting it. +- **Implementers** create a software implementation of the RFC in one or more OME-Zarr library. +- **Reviewers** are invited by editors, provide comments on draft RFCs and their approval of an RFC is one route to accepting it. +- **Commenters** are others who provide feedback on RFCs. + +## Process + +A flowchart of the process is available at the end of this section. + +### Phases + +The overall RFC process is broken down into three phases: the _draft phase_ before a proposal becomes an RFC, the _RFC phase_ during which reviews occur, and the _accepted phase_ after the RFC has been accepted. + +#### Draft + +During the _draft_ phase, authors discuss and develop an idea to maximize its potential as an RFC. This phase is meant to circulate ideas and gather initial feedback, and authors may want to update the RFC based on discussions. Authors who are unsure if they will be able to shepherd an RFC throughout the entire process are still encouraged to open proposals that could be adopted by others during the RFC process. + +This begins when an author opens a new draft pull request with their draft RFC, and lasts at least four weeks to allow anyone to leave comments or ask for clarifications. A [RFC template](templates/rfc_template) is available to start writing an RFC. + +After four weeks, the editor can choose to assign an RFC number and merge the PR at which point it becomes an RFC, or can close it they believe there is no interest in progressing with the proposal. If the RFC is closed the editor will provide feedback on why this happened, which can be taken on board if authors wish to resubmit a similar idea in the future. + +#### RFC + +During the _RFC phase_, an iterative process of community endorsement and feedback helps to achieve a consensus decision on whether to adopt the RFC. Once a PR has been merged and has been assigned an RFC number, two conditions must be met for the RFC be adopted: + +1. All invited reviewers approve the RFC, or in rare circumstances the editors decide to approve the PR. +2. Two pieces of software have started implemented the RFC. + +Throughout the RFC phase feedback is welcome from anyone interested and who has read the RFC in full. Feedback can be given by adding a comment to the RFC, either by contacting the editors or directly opening a PR to add the comment to the NGFF repository. It is also possible to simply endorse a RFC, which amounts to approval with no feedback for improvement. + +The editor also specifically invites reviewers to give feedback on proposals. The rest of this section explains the formal review process. + +##### The review process + +The editor will identify and assign reviewers. Editors and Reviewers should proactively disclose any potential conflicts of interest as part of the RFC process at this point to ensure a transparent review process. Reviewers will be asked to complete a review within four weeks. If keeping to this timescale is not possible, they should contact the editor so appropriate arrangements to extend the review period or find other reviewers can be made. + +Reviewers then submit their comment along with their recommendation, either via a public PR adding the review in markdown to the RFC's subdirectory or by emailing the editor directly (a PR is preferred). + +Possible recommendations from **Reviewers** in ascending order of support are: + +- **Reject** suggests that the downsides of adopting an RFC outweigh the benefits, and there is no pathway to remedy this. This should be a last recourse, and instead major changes can be requested with positive suggestions for improvement. +- **Major changes** suggests an RFC has potential value of an requires significant changes before being adopted. Suggestions should be provided on how to concretely improve the proposal in order to make it acceptable and change the reviewer’s recommendation. + +* **Minor changes** suggests that if the described changes are made reviewers consider the RFC acceptable. +* **Accept** is a positive vote with no requested changes and no text review is strictly necessary, though may be provided. Reviewers who accept an RFC are implicitly considered an endorser. + +Reviewers who also maintain an implementation can also specify when recommending: + +- “Plan to implement” with an estimated timeline +- “Implementation begun” with an estimated timeline +- “Implementation complete” with a link to the available code + +Reviewers are free to structure the text in the most useful way - [a template](templates/review_template) is available but not mandatory Reviews should be cordial and professional. The goal is to communicate to the authors where RFCs can be improved before being adopted, or explain why an RFC should not be adopted. + +Once editors have received reviews they are added to the NGFF repository alongside the RFC, authors are contacted for a response. At this stage authors can update the RFC in response to feedback to improve it. The response to reviewers should reply to each point and explain how they have resolved each comment. Editors then contact the reviewers again, who have the opportunity to revise their review in response to the author comments. This should be done within two weeks of authors replying to the original comments. + +This stage can be iterative - if all reviewers return a formal "approve" review the RFC can be adopted as soon as there are two in-progress implementations. If the reviewers do not all approve, the editor can take one of three decisions: + +- provide authors a list of necessary changes. These will be based on the reviewer suggestions but possibly modified, e.g., to remove contradictions. If the changes are minor the editors might decide that no further review is required. + +* close the RFC . This should only be take if all reviewers recommend the RFC is rejected. Authors can re-submit the RFC in the future taking into account feedback shared during the review process. +* decide that no further changes are necessary and that the RFC should be adopted. + +In the last case editors must provide a reply explaining why the decision of the reviwers was overridden. This might occur if consent between the reviewers cannot be reached. + +If the changes requested by the editor are major, then the review process iterates again and the reviewers re-review after authors have updated the RFC. + +In all cases, the RFC text and all reviews and comments remain available the RFC web page for posterity. + +If at any stage in the process above, reviewers feel it necessary to raise an objection to the decisions by the editors, then the “Handling Disagreements” section below should be followed. + +#### SPEC + +During the _SPEC phase_ necessary changes to the specification and implementations are applied so that the RFC can be officially adopted. At this point the primary purpose of the RFC becomes driving implementations. Implementations may raise problems not foreseen during the review process. In this case implementors should engage directly with authors to resolve these queries. For complex RFCs this period may take substantial time to coordinate with implementers. Editors will also contact in-progress implementers regarding the status of their implementations and update the endorsements table accordingly. + +Once two implementations are complete and released, the RFC is considered adopted 🎉 + +```mermaid +flowchart TD + +open --> discuss_draft + +discuss_draft -->|After mininmum 4 weeks discussion| draft_approve + +draft_approve -->|No, edit| revise_draft + +revise_draft --> discuss_draft + +draft_approve -->|Yes| editor_assign + +draft_approve -->|No, withdraw| close + +editor_assign -->|Maximum 4 weeks| review + +review --> respond + +respond --> re_review + +re_review -->|Max 2 weeks| review_decision + +review_decision -->|No| editor_decision + +review_decision -->|Yes| accept + +editor_decision -->|Yes| accept + +editor_decision -->|No, withdraw| close_after_review + +editor_decision -->|No, minor changes| minor_changes + +minor_changes --> editor_decision + +editor_decision -->|No, major changes| major_changes + +major_changes --> re_review + +accept --> implement + +implement --> adopt + + + +open["Open an RFC as a draft pull request (PR)"] + +discuss_draft["Open discussion on draft PR (and possibly update RFC as a result)"] + +draft_approve{"Editors approve"} + +revise_draft["Revise draft"] + +close["RFC not adopted or merged"] + +editor_assign["Editors assign RFC number, merge PR, and find reviewers"] + +review["Reiewers submit comments"] + +respond["Authors respond to reviewer comments"] + +re_review["Reviewers consider response"] + +major_changes["Authors update RFC"] + +minor_changes["Authors update RFC"] + +review_decision{"Reviewers all accept RFC?"} + +editor_decision{"Editor accepts RFC?"} + +close_after_review["RFC closed, but saved as record of discussion"] + +accept["RFC accepted"] + +implement["Wait for at least two full implementations"] + +adopt["RFC adopted"] +``` + +### RFC Prioritization + +All RFCs are welcome from the community as a way to contribute to the public record of the ongoing evolution of OME-Zarr. That being said, not every RFC is guaranteed to get to the review stage due to people-time constraints. 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 will be chosen to represent a cross-section of the community. This might include geographic distributions, the variety of imaging modalities, and/or programming languages of the expected implementations. An attempt is also made to select a range of views from the community. + +### Deadline enforcement + +Everyone (and especially the editors) should try to prevent the specification process from becoming blocked or stalled. As part of this editors will: + +- keep a record of all communications to identify bottlenecks and improve the RFC process +- frequently contact authors and reviewers regarding approaching deadlines +- find new reviewers when it becomes clear that the current slate is overextended +- and proactively mark RFCs as inactive if it becomes clear that progress has stalled + +Authors and reviewers are encouraged to be open and honest, both with themselves and the other members of the process, on available time. + +### Implementation requirements + +Two separate implementations must have started for an RFC to enter the SPEC phase and two separate implementations (they need not, but can, be the same ones) must be released an RFC to be adopted. In both cases, at least one implementation must come from someone who is not among the RFC authors. Additionally, data written by both implementations must be readable (and therefore validatable) by at least one of the implementations. It is also strongly encouraged that for each specification change, the [ome-ngff-validator](https://github.com/ome/ome-ngff-validator) additionally be updated as a simple to use and widely used too for partial dataset validation. RFCs should provide guidance where possible for implementors on required and optional sections of an RFC. + +### RFC Versions + +RFCs may be edited, but this should only be done in extraordinary cases for: + +- clarification: additional text and examples which simplify the implementation of specifications +- deprecation: where sections are no longer accurate and especially when they have been replaced by a new RFC, the existing text can be marked and a link to the updated information provided; +- and extension: references to new RFCs can be added throughout an existing RFC to provide simpler reading for implementors. + +RFCs should clearly identify any sections which are anticipated to be deprecated or extended in the future. + +### Handling Disagreements + +The OME community is open to everybody and built upon mutual respect. All activities within the NGFF community are conducted under the OME [Code of Conduct](https://github.com/ome/.github/blob/master/CODE_OF_CONDUCT.md#when-something-happens). If you feel that your feedback is not being considered, please follow the steps outlined under “When Something Happens”. + +### Editorial Board + +The Editors can be reached at \. Josh Moore is the current sole editor. diff --git a/rfc/templates/index.md b/rfc/templates/index.md new file mode 100644 index 00000000..e0e1dc2c --- /dev/null +++ b/rfc/templates/index.md @@ -0,0 +1,9 @@ +# Templates + +Templates provided for the RFC process: + +```{toctree} +:maxdepth: 1 +rfc_template +review_template +``` diff --git a/rfc/templates/review_template.md b/rfc/templates/review_template.md new file mode 100644 index 00000000..10597d42 --- /dev/null +++ b/rfc/templates/review_template.md @@ -0,0 +1,28 @@ +# Review Template + +Replace the title above of this file with “RFC-NUM: Review NUM” + +## Review authors + +## Conflicts of interest (optional) + +This section should be included if authors feel that there is any background information (shared grants, financial interests, etc.) which should be shared with the community for transparency. This will not prevent the **Review Authors** from submitting a review, but may trigger the addition of other **Reviewers**. + +## Summary + +## Significant comments and questions + +### Subheadings + +Structure any subheadings as necessary. + +## Minor comments and questions + +Similarly, add any subheadings necessary + +## Recommendation + +Adopt, major changes, minor changes, reject (as last resort) + +See [the list of recommendations under “RFC” in RFC-1](../index.md#rfc-recommendations). + diff --git a/rfc/templates/rfc_template.md b/rfc/templates/rfc_template.md new file mode 100644 index 00000000..a4dfda4c --- /dev/null +++ b/rfc/templates/rfc_template.md @@ -0,0 +1,302 @@ +@: template +# RFC Template + +Summary: Sentence fragment summary + +## Status + +Brief description of status, including the state identifier, e.g. `R4` + +| Name | GitHub Handle | Institution | Date | Status | +| --------- | ------------- | ----------- | ---------- | ------------------------------------- | +| Author | N/A | N/A | xxxx-xx-xx | Author | +| Author | N/A | N/A | xxxx-xx-xx | Author; Implemented (link to release) | +| Commenter | N/A | N/A | xxxx-xx-xx | Endorse (link to comment) | +| Commenter | N/A | N/A | xxxx-xx-xx | Not yet (link to comment) | +| Endorser | N/A | N/A | xxxx-xx-xx | Endorse (no link needed) | +| Endorser | N/A | N/A | xxxx-xx-xx | Implementing (link to branch/PR) | +| Reviewer | N/A | N/A | xxxx-xx-xx | Endorse (link to comment) | +| Reviewer | N/A | N/A | xxxx-xx-xx | Requested by editor | + +## Overview + +The RFC begins with a brief overview. This section should be one or two +paragraphs that just explains what the goal of this RFC is going to be, but +without diving too deeply into the "why", "why now", "how", etc. Ensure anyone +opening the document will form a clear understanding of the RFCs intent from +reading this paragraph(s). + +## Background + +The next section is the "Background" section. This section should be at least +two paragraphs and can take up to a whole page in some cases. The \*\*guiding goal +of the background section\*\* is: as a newcomer to this project (new employee, team +transfer), can I read the background section and follow any links to get the +full context of why this change is necessary? + +If you can't show a random engineer the background section and have them +acquire nearly full context on the necessity for the RFC, then the background +section is not full enough. To help achieve this, link to prior RFCs, +discussions, and more here as necessary to provide context so you don't have to +simply repeat yourself. + +## Proposal + +The next required section is "Proposal". Given the background above, this +section proposes a solution. This should be an overview of the "how" for the +solution, but for details further sections will be used. + +## Sections (at heading 2) + +From this point onwards, the sections and headers are generally freeform +depending on the RFC, though it is typically preferable to make use of the +sections listed below changing the order as necessary. Sections are styled as +"Heading 2". Try to organize your information into self-contained sections that +answer some critical question, and organize your sections into an order that +builds up knowledge necessary (rather than forcing a reader to jump around to +gain context). + +Sections often are split further into sub-sections styled "Heading 3" and beyond. These sub-sections just further help to organize data to ease reading and discussion. + +## Requirements (Recommended Header) + +For the problem(s) solved by this RFC, what constrains the possible solutions? +List other RFCs, or standards (ISO, etc.) which are applicable. It is suggested +that the following text SHOULD be used in all RFCs: + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", +"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in [IETF RFC 2119](https://tools.ietf.org/html/rfc2119) + +## Stakeholders (Recommended Header) + +Who has a stake in whether this RFC is accepted? + +* Facilitator: The person appointed to shepherd this RFC through the RFC + process. +* Reviewers: List people whose vote (+1 or -1) will be taken into consideration + by the editor when deciding whether this RFC is accepted or rejected. Where + applicable, also list the area they are expected to focus on. In some cases + this section may be initially left blank and stakeholder discovery completed + after an initial round of socialization. Care should be taken to keep the + number of reviewers manageable, although the exact number will depend on the + scope of the RFC in question. +* Consulted: List people who should review the RFC, but whose approval is not + required. +* Socialization: This section may be used to describe how the design was + socialized before advancing to the "Iterate" stage of the RFC process. For + example: "This RFC was discussed at a working group meetings from 20xx-20yy" + +## Implementation (Recommended Header) + +Many RFCs have an "implementation" section which details how the implementation +will work. This section should explain the rough specification changes. The +goal is to give an idea to reviewers about the subsystems that require change +and the surface area of those changes. + +This knowledge can result in recommendations for alternate approaches that +perhaps are idiomatic to the project or result in less packages touched. Or, it +may result in the realization that the proposed solution in this RFC is too +complex given the problem. + +For the RFC author, typing out the implementation in a high-level often serves +as "[rubber duck debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging)" and you can catch a lot of +issues or unknown unknowns prior to writing any real code. + +## Drawbacks, risks, alternatives, and unknowns (Recommended Header) + +* What are the costs of implementing this proposal? +* What known risks exist? What factors may complicate your project? Include: + security, complexity, compatibility, latency, service immaturity, lack of + team expertise, etc. +* What other strategies might solve the same problem? +* What questions still need to be resolved, or details iterated upon, to accept + this proposal? Your answer to this is likely to evolve as the proposal + evolves. +* What parts of the design do you expect to resolve through the RFC process + before this gets merged? +* What parts of the design do you expect to resolve through the implementation + of this feature before stabilization? +* What related issues do you consider out of scope for this RFC that could be + addressed in the future independently of the solution that comes out of this + RFC? + +## Abandoned Ideas (Optional Header) + +As RFCs evolve, it is common that there are ideas that are abandoned. Rather +than simply deleting them from the document, you should try to organize them +into sections that make it clear they're abandoned while explaining why they +were abandoned. + +When sharing your RFC with others or having someone look back on your RFC in +the future, it is common to walk the same path and fall into the same pitfalls +that we've since matured from. Abandoned ideas are a way to recognize that path +and explain the pitfalls and why they were abandoned. + +## Prior art and references (Optional Header) + +Is there any background material that might be helpful when reading this +proposal? For instance, do other operating systems address the same problem +this proposal addresses? + +Discuss prior art, both the good and the bad, in relation to this proposal. A +few examples of what this can include are: + +Does this feature exist in other formats and what experiences has their +community had? + +Are there any published papers or great posts that discuss this? If you have +some relevant papers to refer to, this can serve as a more detailed theoretical +background. + +This section is intended to encourage you as an author to think about the +lessons from other domains, and provide readers of your RFC with a fuller +picture. If there is no prior art, that is fine - your ideas are interesting to +us whether they are brand new or if it is an adaptation from other languages. + +Note that while precedent set by other languages is some motivation, it does +not on its own motivate an RFC. + +## Future possibilities (Optional Header) + +Think about what the natural extension and evolution of your proposal would be +and how it would affect the specification and project as a whole in a holistic +way. Try to use this section as a tool to more fully consider all possible +interactions with the project in your proposal. Also consider how this all fits +into the roadmap for the project and of the relevant sub-team. + +This is also a good place to "dump ideas", if they are out of scope for the RFC +you are writing but otherwise related. If you have tried and cannot think of +any future possibilities, you may simply state that you cannot think of +anything. + +Note that having something written down in the future-possibilities section is +not a reason to accept the current or a future RFC; such notes should be in the +section on motivation or rationale in this or subsequent RFCs. The section +merely provides additional information. + +## Performance (Recommended Header) + +What impact will this proposal have on performance? What benchmarks should we +create to evaluate the proposal? To evaluate the implementation? Which of those +benchmarks should we monitor on an ongoing basis? + +Do you expect any (speed / memory)? How will you confirm? + +There should be microbenchmarks. Are there? + +There should be end-to-end tests and benchmarks. If there are not (since this +is still a design), how will you track that these will be created? + +## Compatibility (Recommended Header) + +How does this proposal affect backwards and forwards compatibility? + +Does it restrict existing assumptions or remove existing restrictions? + +How are implementations expected to handle these changes? + +## Testing (Recommended Header) + +How will you test your feature? A typical testing strategy involves unit, +integration, and end-to-end tests. Are our existing test frameworks and +infrastructure sufficient to support these tests or does this proposal require +additional investment in those areas? + +If your proposal defines a contract implemented by other people, how will those +people test that they have implemented the contract correctly? Consider, for +example, creating a conformance test suite for this purpose. + +## Tutorials and Examples (Recommended Header) + +It is strongly recommended to provide as many examples as possible of what both users and developers can expect if the RFC were to be accepted. Sample data should be shared publicly. If longer-term is not available, contact the **Editors** for assistance. + +(additional-considerations)= +## Additional considerations (Optional Header) + +Most RFCs will not need to consider all the following issues. They are included here as a checklist + +### Security +What impact will this proposal have on security? Does the proposal require a +security review? + +A good starting point is to think about how the system might encounter +untrusted inputs and how those inputs might be used to manipulate the system. +From there, consider how known classes of vulnerabilities might apply to the +system and what tools and techniques can be applied to avoid those +vulnerabilities. + +### Privacy + +What impact will this proposal have on privacy? Does the proposal require a +privacy review? + +A good starting point is to think about how user data might be collected, +stored, or processed by your system. From there, consider the lifecycle of such +data and any data protection techniques that may be employed. + +### UI/UX + +If there are user- or frontend-impacting changes by this RFC, it is important +to have a "UI/UX" section. User-impacting changes might include changes in how +images will be rendered. Frontend-impacting changes might include the need to +perform additional preprocessing of inputs before displaying to users. + +This section is effectively the "implementation" section for the user +experience. The goal is to explain the changes necessary, any impacts to +backwards compatibility, any impacts to normal workflow, etc. + +As a reviewer, this section should be checked to see if the proposed changes +feel like the rest of the ecosystem. Further, if the breaking changes are +intolerable or there is a way to make a change while preserving compatibility, +that should be explored. + +## Style Notes (EXAMPLE) + +All RFCs should follow similar styling and structure to ease reading. + +This section will updated as more style decisions are made +so that users of the template can simply cut-n-paste sections. + +### Heading Styles + +"Heading 2" should be used for section titles. We do not use "Heading 1" +because aesthetically the text is too large. Google Docs will use Heading 2 as +the outermost headers in the generated outline. + +"Heading 3" should be used for sub-sections. + +Further heading styles can be used for nested sections, however it is rare that +a RFC goes beyond "Heading 4," and rare itself that "Heading 4" is reached. + +### Lists + +When making lists, it is common to bold the first phrase/sentence/word to bring +some category or point to attention. For example, a list of API considerations: + +* *Format* should be widgets +* *Protocol* should be widgets-rpc +* *Backwards* compatibility should be considered. + +### Spelling + +American spelling is preferred. + +### Code Samples + +Code samples should be indented (tab or spaces are fine as long as it is +consistent) text using the Courier New font. Syntax highlighting can be +included if possible but isn't necessary. Please ensure the highlighted syntax +is the proper font size and using the font Courier New so non-highlighted +samples don't appear out of place. + +CLI output samples are similar to code samples but should be highlighted with +the color they'll output if it is known so that the RFC could also cover +formatting as part of the user experience. + + func example() { + <-make(chan struct{}) + } + + +Note: This template is based on the [RFC template from Hashicorp](https://works.hashicorp.com/articles/rfc-template) used with permission. From 79b768272e6148871c482b633d21a8010c968fc7 Mon Sep 17 00:00:00 2001 From: David Stansby Date: Thu, 13 Nov 2025 15:22:28 +0100 Subject: [PATCH 2/2] Fix spelling --- rfc/process.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/rfc/process.md b/rfc/process.md index 0a1728b7..d7fa24f2 100644 --- a/rfc/process.md +++ b/rfc/process.md @@ -71,7 +71,7 @@ This stage can be iterative - if all reviewers return a formal "approve" review * close the RFC . This should only be take if all reviewers recommend the RFC is rejected. Authors can re-submit the RFC in the future taking into account feedback shared during the review process. * decide that no further changes are necessary and that the RFC should be adopted. -In the last case editors must provide a reply explaining why the decision of the reviwers was overridden. This might occur if consent between the reviewers cannot be reached. +In the last case editors must provide a reply explaining why the decision of the reviewers was overridden. This might occur if consent between the reviewers cannot be reached. If the changes requested by the editor are major, then the review process iterates again and the reviewers re-review after authors have updated the RFC. @@ -81,7 +81,7 @@ If at any stage in the process above, reviewers feel it necessary to raise an ob #### SPEC -During the _SPEC phase_ necessary changes to the specification and implementations are applied so that the RFC can be officially adopted. At this point the primary purpose of the RFC becomes driving implementations. Implementations may raise problems not foreseen during the review process. In this case implementors should engage directly with authors to resolve these queries. For complex RFCs this period may take substantial time to coordinate with implementers. Editors will also contact in-progress implementers regarding the status of their implementations and update the endorsements table accordingly. +During the _SPEC phase_ necessary changes to the specification and implementations are applied so that the RFC can be officially adopted. At this point the primary purpose of the RFC becomes driving implementations. Implementations may raise problems not foreseen during the review process. In this case implementers should engage directly with authors to resolve these queries. For complex RFCs this period may take substantial time to coordinate with implementers. Editors will also contact in-progress implementers regarding the status of their implementations and update the endorsements table accordingly. Once two implementations are complete and released, the RFC is considered adopted 🎉 @@ -186,7 +186,7 @@ Authors and reviewers are encouraged to be open and honest, both with themselves ### Implementation requirements -Two separate implementations must have started for an RFC to enter the SPEC phase and two separate implementations (they need not, but can, be the same ones) must be released an RFC to be adopted. In both cases, at least one implementation must come from someone who is not among the RFC authors. Additionally, data written by both implementations must be readable (and therefore validatable) by at least one of the implementations. It is also strongly encouraged that for each specification change, the [ome-ngff-validator](https://github.com/ome/ome-ngff-validator) additionally be updated as a simple to use and widely used too for partial dataset validation. RFCs should provide guidance where possible for implementors on required and optional sections of an RFC. +Two separate implementations must have started for an RFC to enter the SPEC phase and two separate implementations (they need not, but can, be the same ones) must be released an RFC to be adopted. In both cases, at least one implementation must come from someone who is not among the RFC authors. Additionally, data written by both implementations must be readable (and therefore validatable) by at least one of the implementations. It is also strongly encouraged that for each specification change, the [ome-ngff-validator](https://github.com/ome/ome-ngff-validator) additionally be updated as a simple to use and widely used too for partial dataset validation. RFCs should provide guidance where possible for implementers on required and optional sections of an RFC. ### RFC Versions @@ -194,7 +194,7 @@ RFCs may be edited, but this should only be done in extraordinary cases for: - clarification: additional text and examples which simplify the implementation of specifications - deprecation: where sections are no longer accurate and especially when they have been replaced by a new RFC, the existing text can be marked and a link to the updated information provided; -- and extension: references to new RFCs can be added throughout an existing RFC to provide simpler reading for implementors. +- and extension: references to new RFCs can be added throughout an existing RFC to provide simpler reading for implementers. RFCs should clearly identify any sections which are anticipated to be deprecated or extended in the future.