Document contributing guidelines #66

Merged
prologic merged 5 commits from add-contributing-guildelines into master 2 months ago
Collaborator
  • Document contributing guidelines
- Document contributing guidelines
gumbo2000 added 3 commits 2 months ago
Poster
Collaborator

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 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!" 😆
Owner

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 😅

> 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 😅
prologic reviewed 2 months ago
CONTRIBUTING.md Outdated
- 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
Owner

This should go in the PR title itself.

We should use Fixes #xxx or Closes #xxx in 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"™ 👌

This should go in the PR title itself. We should use `Fixes #xxx` or `Closes #xxx` in 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"™ 👌
Poster
Collaborator

🤔 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 .chglog/config.yml

Could you find a link to that format for me?

🤔 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 `.chglog/config.yml` Could you find a link to that format for me?
Owner

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.

The config:

$ cat .chglog/config.yml
---
style: Github
template: CHANGELOG.tpl.md
info:
  title: CHANGELOG
  repository_url: https://git.mills.io/prologic/saltyim
options:
  commits:
    filters:
      Type:
        - Add
        - Fix
        - Update
        - Document
  commit_groups:
    title_maps:
      Add: Features
      Update: Updates
      Fix: Bug Fixes
      Document: Documentation
  header:
    pattern: "^((\\w+)\\s.*)$"
    pattern_maps:
      - Subject
      - Type
  refs:
    actions:
      - Closes
      - Fixes
  reverts:
    pattern: "^Revert \"([\\s\\S]*)\"$"
    pattern_maps:
      - Header
  notes:
    keywords:
      - NOTE
      - BREAKING CHANGE

Means PR titles like:

  • Add new features to do X
  • Fix a bug in blah

All translate to auto-generated (somewhat) nice Release Notes 😅

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. The config: ```#!yaml $ cat .chglog/config.yml --- style: Github template: CHANGELOG.tpl.md info: title: CHANGELOG repository_url: https://git.mills.io/prologic/saltyim options: commits: filters: Type: - Add - Fix - Update - Document commit_groups: title_maps: Add: Features Update: Updates Fix: Bug Fixes Document: Documentation header: pattern: "^((\\w+)\\s.*)$" pattern_maps: - Subject - Type refs: actions: - Closes - Fixes reverts: pattern: "^Revert \"([\\s\\S]*)\"$" pattern_maps: - Header notes: keywords: - NOTE - BREAKING CHANGE ``` Means PR titles like: - Add new features to do X - Fix a bug in blah All translate to auto-generated (somewhat) nice Release Notes 😅
Owner

For examples, see the yarnsocial/yarn project and it's releases 👌

For examples, see the [yarnsocial/yarn](https://git.mills.io/yarnsocial/yarn) project and it's releases 👌
Poster
Collaborator

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_maps to 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.yml is 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!

  • I've italicised the keywords that are recognised for clarity.
  • I've only put in the first line of a commit message. Obviously the commit message can/should have a body with further details like references to issues.
Conventional Commit .chglog/config.yml Meaning
fix: Plug leaking bucket Fix Plug leaking bucket Bugfix
feat: Make section selectable Add New selector for section New feature
docs: Add foo to roadmap Document Add foo to roadmap Changes to documentation
chore: Update external lib "bar" Update deps on bar Update to use new versions of external libs
refactor: break up 200 lines uploadHandler ? refactor code for readability without changing functionality
build: Allow go 1.19 in preflight check ? Changes to build tooling like makefiles or build containers. (Manual and/or automatic builds)
ci: reconfigure PR builder to ignore "WIP:" PRs ? Changes to the CI/CD pipeline. (Only automatic builds)
style: Change camelCase to kebab-case in foo.go ? refactoring of code style without structural change
test: Add edge case of empty list to list tests ? Changes to tests instead of code

Only the first four are used in genereating CHANGELOG.md

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_maps` to 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.yml` is 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! * I've *italicised* the keywords that are recognised for clarity. * I've only put in the first line of a commit message. Obviously the commit message can/should have a body with further details like references to issues. | Conventional Commit | `.chglog/config.yml` | Meaning | | -------- | -------- | -------- | | *fix:* Plug leaking bucket | *Fix* Plug leaking bucket | Bugfix | | *feat:* Make section selectable | *Add* New selector for section | New feature | | *docs:* Add foo to roadmap | *Document* Add foo to roadmap | Changes to documentation | | *chore:* Update external lib "bar" | *Update* deps on bar| Update to use new versions of external libs | | *refactor:* break up 200 lines uploadHandler | ? | refactor code for readability without changing functionality | | *build:* Allow go 1.19 in preflight check | ? | Changes to build tooling like makefiles or build containers. (Manual and/or automatic builds) | | *ci:* reconfigure PR builder to ignore "WIP:" PRs | ? | Changes to the CI/CD pipeline. (Only automatic builds) | *style:* Change camelCase to kebab-case in foo.go | ? | refactoring of code style without structural change | | *test:* Add edge case of empty list to list tests | ? | Changes to tests instead of code | Only the first four are used in genereating CHANGELOG.md
Owner

Hmmm I see what you mean...

Hmmm I see what you mean...
Owner

What do you propose? I've not really invested in anything beyond what I've developed over the years with the chglog tool which has works kind of "okay".

What do you propose? I've not really invested in anything beyond what I've developed over the years with the `chglog` tool which has works kind of "okay".
Poster
Collaborator

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?

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?
prologic marked this conversation as resolved
prologic approved these changes 2 months ago
prologic left a comment
Owner

Rest of this looks good to me 👌 Might borrow this verbage and add to other projects 👌

Rest of this looks good to me 👌 Might borrow this verbage and add to other projects 👌
gumbo2000 added 1 commit 2 months ago
continuous-integration/drone/pr Build is passing Details
29d0fc73c9
docs: Nuke the code of conduct
gumbo2000 added 1 commit 2 months ago
continuous-integration/drone/pr Build is passing Details
e9c82276af
Document PR convention
gumbo2000 force-pushed add-contributing-guildelines from e9c82276af to 7248a7a42c 2 months ago
gumbo2000 changed title from WIP: Document contribution contributing guidelines to WIP: Document contributing guidelines 2 months ago
Poster
Collaborator

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 😆

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 😆
prologic approved these changes 2 months ago
Owner

LGTM 👌 Might wanna remove the `WIP prefix now 😅

LGTM 👌 Might wanna remove the `WIP prefix now 😅
gumbo2000 changed title from WIP: Document contributing guidelines to Document contributing guidelines 2 months ago
prologic merged commit c0ca374a16 into master 2 months ago
prologic deleted branch add-contributing-guildelines 2 months ago
prologic referenced this issue from a commit 2 months ago

Reviewers

prologic approved these changes 2 months ago
continuous-integration/drone/pr Build is passing
The pull request has been merged as c0ca374a16.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: prologic/tube#66
Loading…
There is no content yet.