Capitalisation in examples #41

New Issue

GiteaMirror · 2026-02-17T11:37:27-06:00

GiteaMirror commented

2026-02-17 11:37:27 -06:00

Originally created by @robcresswell on GitHub (Aug 20, 2018).

This is minor I suppose, but shouldn't the examples use capitals after the :? Given that text is parsed into a CHANGELOG and each commit title is supposed to be a standalone sentence, would it make sense to capitalise the first letter of each explanation?

For example, instead of:

feat: allow provided config object to extend other configs

use:

feat: Allow provided config object to extend other configs

Then the generated changelogs would use proper grammar, I think?

Originally created by @robcresswell on GitHub (Aug 20, 2018). This is minor I suppose, but shouldn't the examples use capitals after the `:`? Given that text is parsed into a `CHANGELOG` and each commit title is supposed to be a standalone sentence, would it make sense to capitalise the first letter of each explanation? For example, instead of: ``` feat: allow provided config object to extend other configs ``` use: ``` feat: Allow provided config object to extend other configs ``` Then the generated changelogs would use proper grammar, I think?

GiteaMirror closed this issue

2026-02-17 11:37:27 -06:00

GiteaMirror commented

2026-02-17 11:37:29 -06:00

@damianopetrungaro commented on GitHub (Aug 20, 2018):

@robcresswell thank you for opening the issue!

We just merged a PR about capitalization in the commit type.

I agree with your idea, but think that this should not care about it, because the changelogs tools may do it on the fly while generating it.

We may change #82 to be more generic maybe.

wdyt about it?

@damianopetrungaro commented on GitHub (Aug 20, 2018): @robcresswell thank you for opening the issue! We just merged a PR about capitalization in the commit type. I agree with your idea, but think that this should not care about it, because the changelogs tools may do it on the fly while generating it. We may change #82 to be more generic maybe. wdyt about it?

GiteaMirror commented

2026-02-17 11:37:30 -06:00

@dijonkitchen commented on GitHub (Aug 20, 2018):

Yeah, as noted in #24, I think the type and the message itself should be capitalized so easier readability. But I can't tell if there's any advantage/disadvantage for the tooling around this.

@dijonkitchen commented on GitHub (Aug 20, 2018): Yeah, as noted in #24, I think the type and the message itself should be capitalized so easier readability. But I can't tell if there's any advantage/disadvantage for the tooling around this.

GiteaMirror commented

2026-02-17 11:37:31 -06:00

@robcresswell commented on GitHub (Aug 20, 2018):

Ah that's sensible reasoning, to not be opinionated about casing at this level of the spec and leave it up to parsers. Thanks for the feedback; seems like something I should open in the tools themselves 😃

@robcresswell commented on GitHub (Aug 20, 2018): Ah that's sensible reasoning, to not be opinionated about casing at this level of the spec and leave it up to parsers. Thanks for the feedback; seems like something I should open in the tools themselves :smiley:

GiteaMirror commented

2026-02-17 11:37:32 -06:00

@damianopetrungaro commented on GitHub (Aug 20, 2018):

It's right to discuss about it, and we may enforce it to be capitalized if the community want it and it's reasonable ;)

@damianopetrungaro commented on GitHub (Aug 20, 2018): It's right to discuss about it, and we may enforce it to be capitalized if the community want it and it's reasonable ;)

GiteaMirror commented

2026-02-17 11:37:33 -06:00

@dijonkitchen commented on GitHub (Aug 20, 2018):

Is there an official parser?

@dijonkitchen commented on GitHub (Aug 20, 2018): Is there an official parser?

GiteaMirror commented

2026-02-17 11:37:35 -06:00

@tayflo commented on GitHub (Dec 31, 2020):

I understand casing should not be an issue for parser, but still capital after the : seems to me common good practice (it's recommended by GitHub, Tim Pope, Chris Beams).

Since the Conventional Commits page is a reference for people looking to write tidy commits, using capitalization in given examples would be better, I think.

@tayflo commented on GitHub (Dec 31, 2020): I understand casing should not be an issue for parser, but still capital after the `:` seems to me common good practice (it's recommended by [GitHub](https://github.com/trein/dev-best-practices/wiki/Git-Commit-Best-Practices#formatting-rules), [Tim Pope](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), [Chris Beams](https://chris.beams.io/posts/git-commit/#capitalize)). Since the [Conventional Commits page](https://www.conventionalcommits.org) is a reference for people looking to write tidy commits, using capitalization in given examples would be better, I think.

GiteaMirror commented

2026-02-17 11:37:36 -06:00

@tayflo commented on GitHub (Feb 5, 2021):

@damianopetrungaro may I draw your attention on this topic again? Considering the three authority sources I referred to in my previous post, un-capitalized examples seem to me... pretty unconventional!

Maybe re-open this issue? If it would be accepted and it could help, I would do a pull request but I'm unsure about the project structure; all files in content/v1.0.0/ should be modified accordingly, is that it? Also the file in content/next/ I presume.

@tayflo commented on GitHub (Feb 5, 2021): @damianopetrungaro may I draw your attention on this topic again? Considering the three authority sources I referred to in my previous post, un-capitalized examples seem to me... pretty unconventional! Maybe re-open this issue? If it would be accepted and it could help, I would do a pull request but I'm unsure about the project structure; all files in `content/v1.0.0/` should be modified accordingly, is that it? Also the file in `content/next/` I presume.

GiteaMirror commented

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

@keikoro commented on GitHub (Jun 29, 2023):

I understand casing should not be an issue for parser, but still capital after the : seems to me common good practice (it's recommended by GitHub, Tim Pope, Chris Beams).

@damianopetrungaro may I draw your attention on this topic again? Considering the three authority sources I referred to in my previous post, un-capitalized examples seem to me... pretty unconventional!

The examples you linked to recommend the capitalisation of commit messages/commit subjects, they don't recommend what you seem to be suggesting, i.e. the capitalisation of some other word that appears later in the sentence.

Conventional commits "naturally" decrease readability because their defaulting to lowercase goes against English orthography, which the recommendation by these often cited older sources is obviously based on. Capitalising whatever comes after the colon would only make matters worse because it'd break orthographic convention a second or even third time within one short sentence.

@keikoro commented on GitHub (Jun 29, 2023): > I understand casing should not be an issue for parser, but still capital after the : seems to me common good practice (it's recommended by [GitHub](https://github.com/trein/dev-best-practices/wiki/Git-Commit-Best-Practices#formatting-rules), [Tim Pope](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), [Chris Beams](https://chris.beams.io/posts/git-commit/#capitalize)). > @damianopetrungaro may I draw your attention on this topic again? Considering the three authority sources I referred to in my previous post, un-capitalized examples seem to me... pretty unconventional! The examples you linked to recommend **the capitalisation of commit messages/commit subjects**, they don't recommend what you seem to be suggesting, i.e. the capitalisation of some other word that appears later in the sentence. Conventional commits "naturally" decrease readability because their defaulting to lowercase goes against English orthography, which the recommendation by these often cited older sources is obviously based on. Capitalising whatever comes after the colon would only make matters worse because it'd break orthographic convention a second or even _third time_ within one short sentence.

GiteaMirror commented

2026-02-17 11:37:38 -06:00

@keikoro commented on GitHub (Jun 29, 2023):

Sorry, should perhaps have tagged you, @Tayflo. ^

@keikoro commented on GitHub (Jun 29, 2023): Sorry, should perhaps have tagged you, @Tayflo. ^

GiteaMirror commented

2026-02-17 11:37:39 -06:00

@tayflo commented on GitHub (Sep 1, 2023):

@keikoro Sorry, I forgot to answer.

For me the tag before the colon is a tag, i.e. a label for a category, and hence not a part of the sentence, which starts right after the colon, usually with a verb describing the action taken.

The colon is here used as a semantic separator, not as it would be in a sentence following proper English grammar. To me it equals something like [feat] Allow provided config object to extend other configs, except using the colon is quicker to write, probably neater to read, and use only one character.

Hence, it makes more sense to capitalize the character right after the colon. And it also makes sense to me not to put a dot at the end because it is also a kind of title (in addition to saving another character).

@tayflo commented on GitHub (Sep 1, 2023): @keikoro Sorry, I forgot to answer. For me the tag before the colon is a tag, i.e. a label for a category, and hence not a part of the sentence, which starts right after the colon, usually with a verb describing the action taken. The colon is here used as a semantic separator, not as it would be in a sentence following proper English grammar. To me it equals something like `[feat] Allow provided config object to extend other configs`, except using the colon is quicker to write, probably neater to read, and use only one character. Hence, it makes more sense to capitalize the character right after the colon. And it also makes sense to me not to put a dot at the end because it is also a kind of title (in addition to saving another character).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#41