CCRFI "Conventional Commits: Request for Implementation"

[mentalisttraceur]

The Conventional Commits community would benefit a lot from mimicking Scheme's "Request for Implementation" (SFRI) process to coordinate common (or nontrivial-to-design-well) extensions.

This would allow us to

1. keep the core spec really minimal, like it is now
2. have really good discoverability/visibility in one centralized place,
3. refer to proposed/common extensions and tool behaviors with concise unambiguous identifiers,
4. check if a given extension is being used by a project for its commits,
5. check if a given extension/behavior is supported by a given tool, and
6. turn behaviors on/off in a common way.

So I propose:

1. Create a requests-for-implementation repo under the conventional-commits org.
2. Direct people there if they're proposing something (unless they convince you that it really would be much better as a core spec change).
3. The issue/PR number in that repo (which GitHub ensures is a monotonically increasing and unique integer) is the CCRFI number. (Yes, we'll waste some CCRFI numbers on low-quality/unpopular/confused/not-really-a-spec issues+PRs. That's fine. We have integers to spare.)

[mentalisttraceur]

Note: lots of technical projects have something like this. A couple examples:

1. Python's "Enhancement Proposal" (PEP) process,
2. Kubernetes' "Enhancement Proposal" (KEP) process, and
3. the venerable RFC/BCP process which has shaped so many network protocols, open formats, and so on.

I centered SRFI as the main example because of a key similarity: Scheme's RFIs are optional standardized extensions which keep the core spec minimal, and Conventional Commit's RFI would do the same.

[mentalisttraceur]

The current spec seems to suggest just hosting extension specs in our own repos. Here's why I think a conventional-commits/requests-for-implementation repo is a worthwhile addition over that:

1. Specifications hosted in the community org are much more likely to keep existing.

2. Specifications hosted in the community org are much easier to find (both discovering ones you don't know about which might be useful, and ones that you know about but don't know the location of).

I could not ask for a better illustration of these two points than the example extension mentioned in the FAQ, @jameswomack/conventional-commit-spec, which either no longer exists, never existed, or exists somewhere that I was unable to find.

3. If I say CCRFI-1, that's clearly a "CCRFI". You learn once what a CCRFI is, and then you always recognize/know exactly what it what it is. What's the reference to an extension/proposal in someone's repo? jameswomack/conventional-commit-spec could be almost anything, and needs context to even suspect that it's probably a repo on one of the code hosting websites. Even an explicit URL, without context, is just a URL. Meanwhile, the string CCRFI-42 could show up anywhere, with no context or even in a misleading context, and you could have a great chance of immediately identifying it as a reference to a CCRFI.

[damianopetrungaro]

I'm not sure I see value in this. Can you elaborate more on a use case you have that would benefit from this?

[mentalisttraceur]

@damianopetrungaro probably not until I have recharged from how much effort I've put into very thoroughly covering the value more abstractly.

Hopefully someone else has more reserves of unpaid time/patience/desire/knack for concrete examples, or your mind will start to generate/notice examples now that you have the idea.