Document contributing guidelines
Mergedprologic merged 5 commits from
master2 months ago
Reference in new issue
There is no content yet.
Delete Branch 'add-contributing-guildelines'
Deleting a branch is permanent. It CANNOT be undone. Continue?
I am not sure if I understood the config of git-chglog right.
Please feel free to rip it apart. 😁
I am not married the
CODE_OF_CONDUCT.md. In fact it feels strange that you need to tell people these days to behave like human beings. Feel free to remove it and replace I with a simple "Don't be an a-hole!" 😆
I'm not married to it either, and I feel the same as you. Let's just nuke it. honestly we should all just get along 😅
- Include a brief description of the changes made in the pull request title, following the [conventional commits](https://www.conventionalcommits.org/) standard.
- Include a brief description of the changes in the pull request body.
- Use keywords or labels in the pull request body to identify and categorize the changes
This should go in the PR title itself.
We should use
Closes #xxxin the PR body to reerence/close issues. Otherwise the PR body should just expand upon the title and be a bit more description. I don't always follow this myself, but I do try to always follow the PR title == Conventional COmmit(s) so taht Release Notes (auto-generation) "just works"™ 👌
🤔 I think we are talking about different conventions for commits.
The conventional commits that I know ( https://www.conventionalcommits.org/en/v1.0.0/ ) use
<type>:in the commit titles, but there is no "Add" or "Update" types there like here in
Could you find a link to that format for me?
Nah I think we're talking about the same thing. I just meant that the PR Title becomed the Squashed Commit Message. So the PR Title should really also be a conventional title.
Means PR titles like:
All translate to auto-generated (somewhat) nice Release Notes 😅
For examples, see the yarnsocial/yarn project and it's releases 👌
OK, let me try to summarise:
I understand that the PR title becomes the commit message for the squashed commit.
That commit message will be matched against the
commits.filters.Type. (unsure if that is a regex match or a prefix-match)
If a commit matches any of those filters, it will get mapped via
commit_groups.title_mapsto one of four changelog categories ("Features", "Updates", "Bug Fixes", "Documentation").
Correct so far?
Now to "conventional commits". "Conventions" are like standards. There are so many different and competing ones to choose from, that really need to specify which ones you follow.
When I say "conventional commits", I mean https://www.conventionalcommits.org/en/v1.0.0/#specification
Is there a similar spec for the convention that the current
.chglog/config.ymlis configured for?
Here's what I think are the differences between those and the ones that are currently configured in
.chglog/config.yml. Please correct me where I am wrong!
Only the first four are used in genereating CHANGELOG.md
Hmmm I see what you mean...
What do you propose? I've not really invested in anything beyond what I've developed over the years with the
chglogtool which has works kind of "okay".
I don't have any proposal. I just wanted to clarify for myself how we want to work. I am completely OK with just four keywords. 👍
But I will remove the mention of "conventional commits" and the link to spare other people the confusion.
Instead I'd add the explanation of the commit convention that we use in this project. Agreed?
Rest of this looks good to me 👌 Might borrow this verbage and add to other projects 👌
7248a7a42c2 months ago
WIP: Document contribution contributing guidelinesto WIP: Document contributing guidelines 2 months ago
Done. I think I am happy with it now. If you don't see any more issues I'll remove the
WIP:and we'll see if this change makes it into the next changelog 😆
LGTM 👌 Might wanna remove the `WIP prefix now 😅
WIP: Document contributing guidelinesto Document contributing guidelines 2 months ago
c0ca374a16into master 2 months ago