CCRFI "Conventional Commits: Request for Implementation" #183

New Issue

GiteaMirror · 2026-02-17T11:52:13-06:00

GiteaMirror commented

2026-02-17 11:52:13 -06:00

Originally created by @mentalisttraceur on GitHub (Aug 22, 2023).

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

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

So I propose:

Create a requests-for-implementation repo under the conventional-commits org.
Direct people there if they're proposing something (unless they convince you that it really would be much better as a core spec change).
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.)

Originally created by @mentalisttraceur on GitHub (Aug 22, 2023). The Conventional Commits community would benefit a lot from mimicking [Scheme's "Request for Implementation" (SFRI)](https://en.wikipedia.org/wiki/Scheme_(programming_language)#Scheme_Requests_for_Implementation) 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.)

GiteaMirror commented

2026-02-17 11:52:14 -06:00

@mentalisttraceur commented on GitHub (Aug 22, 2023):

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

Python's "Enhancement Proposal" (PEP) process,
Kubernetes' "Enhancement Proposal" (KEP) process, and
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 commented on GitHub (Aug 22, 2023): Note: lots of technical projects have something like this. A couple examples: 1. [Python's "Enhancement Proposal" (PEP)](https://peps.python.org/pep-0001/) process, 2. [Kubernetes' "Enhancement Proposal" (KEP)](https://github.com/kubernetes/enhancements/blob/master/keps/README.md) 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.

GiteaMirror commented

2026-02-17 11:52:16 -06:00

@mentalisttraceur commented on GitHub (Aug 23, 2023):

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:

Specifications hosted in the community org are much more likely to keep existing.
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.

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.

@mentalisttraceur commented on GitHub (Aug 23, 2023): The [current spec seems to suggest just hosting extension specs in our own repos](https://www.conventionalcommits.org/en/v1.0.0/#how-should-i-version-my-extensions-to-the-conventional-commits-specification-eg-jameswomackconventional-commit-spec). 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.

GiteaMirror commented

2026-02-17 11:52:16 -06:00

@damianopetrungaro commented on GitHub (Aug 23, 2023):

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

@damianopetrungaro commented on GitHub (Aug 23, 2023): I'm not sure I see value in this. Can you elaborate more on a use case you have that would benefit from this?

GiteaMirror commented

2026-02-17 11:52:17 -06:00

@mentalisttraceur commented on GitHub (Aug 23, 2023):

@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.

@mentalisttraceur commented on GitHub (Aug 23, 2023): @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.

GiteaMirror commented

2026-02-17 11:52:18 -06:00

@bcoe commented on GitHub (May 2, 2025):

@mentalisttraceur I like the idea of formalizing some process for extensions, so that we can direct people towards it when they have a recommendation like:

Using Jira identifiers as a type.
Or feature: rather than feat:.
Or a hotfix type.

One goal of Conventional Commit from the get go, was that it's a pretty simple specification. It was a slightly trimmed down version of the angular commit convention (which was already simple).

Any process we have for extension should be equally lightweight. I do see value in a second repo, just so that people building tools like commit lint can interact with the community, e.g., maybe parsers start supporting feature: if it becomes popular.

Within reason, I'd like to treat the Conventional Commit convention itself as finished at this point.

@bcoe commented on GitHub (May 2, 2025): @mentalisttraceur I like the idea of formalizing some process for extensions, so that we can direct people towards it when they have a recommendation like: * Using Jira identifiers as a `type`. * Or `feature:` rather than `feat:`. * Or a `hotfix` type. One goal of Conventional Commit from the get go, was that it's a pretty simple specification. It was a slightly trimmed down version of the angular commit convention (which was already simple). Any process we have for extension should be equally lightweight. I do see value in a second repo, just so that people building tools like commit lint can interact with the community, e.g., maybe parsers start supporting `feature:` if it becomes popular. Within reason, I'd like to treat the Conventional Commit convention itself as finished at this point.

GiteaMirror referenced this issue

2026-02-17 11:59:55 -06:00

[PR #183] [MERGED] fix(spanish): Improve title translation #344

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#183