Create an RFC process

[birkland]

Create a github repository in the OCFL organization for the purpose of community review and publishing of individual OCFL-related RFCs. Make any decisions related to policies and ongoing maintenance.

Background

At the 8/14 OCFL community meeting there was interest in creating an RFC process separate from the specification effort. This was found to be a nice solution to citing specific layouts, and collecting implementation details/recommendations that are out of scope for the spec, but are a practical necessity.

An example collection of RFCs related to specific layout choices may be found in the demo repository. At the community meeting, it was thought that:

• The implementation notes would be a good home for a general description of considerations when creating software for an OCFL repository, whereas published RFCs would be a good home for specific implementation patterns
• Some RFCs might eventually make their way into a future specification revision
• The specification might cite RFCs, and certain information might move from the spec into a RFC (for example, defining or amending the list of supported hash algorithms)

Open Questions

• What is the policy for review and merging of RFCs into this repository?
• Who would be the maintainers of the RFC repository? Community volunteers who may or may not be editors?

[rosy1280]

This sounds less like a request for comment process and more like a way of gathering the community's implementation notes. Can we rename this?

[zimeon]

I agree with @rosy1280 that calling such notes RFCs would be confusing/misleading and another name would be better

[birkland]

Do feel free to think of a better name. RFC seemed like a good fit to me at the time as it's rather analogous to the IETF's RFCs in spirit, and I've seen projects adopt the term in a genericised sense. That being said, if it causes any sort of confusion or ambiguity, it should change.

At the last community meeting, use cases for an rfc-like process included:

• Discussion/collaboration/review of specific OCFL layouts before they're published in a citable form
• Concrete implementation approaches (as opposed to general principles as discussed in the implementation notes)
• A possible avenue to publish amendments to the spec (such as an updated list of supported hash algorithms), or new approaches that might eventually be incorporated into a future spec revision.

Pull requests and associated commenting/reviewing was seen as a good fit for shaping these things before they're published. If I recall correctly, both @ahankinson and @pwinckles had some comments/feedback related to the layout specifications which currently live in a demo repository, pending creation of a "real" repository for that purpose.

[rosy1280]

decided: create a github repo called community extenstions

[birkland]

Once it's up, I'll send along some directory layout PRs

[zimeon]

Have created a repository https://github.com/OCFL/extensions . Still need to define an organization, some formatting rules or suggestions, and process

[zimeon]

Have copied from https://github.com/birkland/ocfl-rfc-demo to set up an example on https://github.com/OCFL/extensions

[zimeon]

Closing this now, will refine process as we go with new issues