summarize semantic commit requirements #12665
Conversation
zeke
requested review from
a team,
jkleinsc,
codebytere,
ckerr and
alexeykuzmin
.github/config.yml
Outdated
| - refactor: A code change that neither fixes a bug nor adds a feature | ||
| - style: Changes that do not affect the meaning of the code (linting) | ||
|
|
||
| Here is a list of things that will help get your PR across the finish line: |
There was a problem hiding this comment.
I like what's here, would also like to see a small examples section as that will go a long way to showing best practices
There was a problem hiding this comment.
I agree that examples would be 💯
.github/config.yml
Outdated
| - refactor: A code change that neither fixes a bug nor adds a feature | ||
| - style: Changes that do not affect the meaning of the code (linting) | ||
|
|
||
| Here is a list of things that will help get your PR across the finish line: |
There was a problem hiding this comment.
I agree that examples would be 💯
.github/config.yml
Outdated
| @@ -12,9 +12,24 @@ newIssueWelcomeComment: | | |||
| newPRWelcomeComment: | | |||
| 💖 Thanks for opening this pull request! 💖 | |||
|
|
|||
|  | |||
| We use [semantic commit messages](https://conventionalcommits.org/) to streamline the Electron release process. Before | |||
| your pull request can be merged, you must **update your pull request title** | |||
There was a problem hiding this comment.
Instead of saying "you must update your pull request title", how about "please ensure that your pull request title...."
.github/config.yml
Outdated
|  | ||
| We use [semantic commit messages](https://conventionalcommits.org/) to streamline the Electron release process. Before | ||
| your pull request can be merged, you must **update your pull request title** | ||
| to start with a semantic prefix, OR prefix at least one of your commit messages. |
There was a problem hiding this comment.
From an automation perspective it would be much easier to just use PR titles vs commit messages.
There was a problem hiding this comment.
Why? Can you elaborate?
There was a problem hiding this comment.
@zeke I was wrong. I was thinking the automatic process only queries PRs, but it actually queries all the commits, so yeah, commits or PR titles are both good.
|
I'd agree that examples would be awesome, but i think it might be easier for brevity of comment to add the examples to contribution docs somewhere and link to them? |
Yessss. Definitely want to have this documented so we can link to it as needed, especially because the message here only applies to first-timers, not the hundreds of people who have already landed PRs on electron. 👍 Started a TODO list up top ☝️ |
|
I made some updates based on all the feedback. This is ready for 👀 again. |
zeke
changed the title
|
I like new examples in the present tense much more than the old ones in the past tense. New:
Old:
|
There was a problem hiding this comment.
- The first line should:
- contain a short description of the change (preferably 50 characters or less,
and no more than 72 characters)
...
- Wrap all other lines at 72 columns.
Are we going to drop line width requirement?
I guess a lot of people work with git in a console, and long commit messages just create a mess.
So I think the requirement should be kept and probably even enforced by a pre-commit hooks and CI checks (bots can work too).
|
@alexeykuzmin I restored the line-width info. 👍 |
This PR represents a first step toward a "conventional commits" requirement on electron/electron.
Rather than requiring every single commit message to follow a convention, the approach here is to require at least one semantic commit message in the PR, or a semantic PR title.
We've been using the https://github.com/apps/semantic-pull-request probot app on electron/i18n for a few weeks, and it's worked well. If a PR is ready to go but doesn't yet meet the semantic requirements, a maintainer can change the PR title to get checks passing, then merge.
Feedback welcome!
TODO: