Update docs on semantic requirements for #13359 (#13365)

.github/PULL_REQUEST_TEMPLATE.md

@@ -12,4 +12,4 @@ Contributors guide: https://github.com/electron/electron/blob/master/CONTRIBUTIN
 - [ ] `npm test` passes
 - [ ] tests are [changed or added](https://github.com/electron/electron/blob/master/docs/development/testing.md)
 - [ ] relevant documentation is changed or added
-- [ ] commit messages or PR title follow semantic [commit guidelines](https://github.com/electron/electron/blob/master/docs/development/pull-requests.md#commit-message-guidelines)
+- [ ] PR title follows semantic [commit guidelines](https://github.com/electron/electron/blob/master/docs/development/pull-requests.md#commit-message-guidelines)

.github/config.yml

@@ -12,7 +12,7 @@ newIssueWelcomeComment: |
 newPRWelcomeComment: |
   💖 Thanks for opening this pull request! 💖
 
-  We use [semantic commit messages](https://github.com/electron/electron/blob/master/docs/development/pull-requests.md#commit-message-guidelines) to streamline the release process. Before your pull request can be merged, you should **update your pull request title** to start with a semantic prefix, OR prefix at least one of your commit messages.
+  We use [semantic commit messages](https://github.com/electron/electron/blob/master/docs/development/pull-requests.md#commit-message-guidelines) to streamline the release process. Before your pull request can be merged, you should **update your pull request title** to start with a semantic prefix.
 
   Examples of commit messages with semantic prefixes:
 

docs/development/pull-requests.md

@@ -86,10 +86,7 @@ A good commit message should describe what changed and why. The Electron project
 uses [semantic commit messages](https://conventionalcommits.org/) to streamline
 the release process.
 
-Before a pull request can be merged, it should include at least one semantic
+Before a pull request can be merged, it **must** have a pull request title with a semantic prefix.
-commit message, though it's not necessary for all commits in the pull request
-to be semantic. Alternatively, you can **update your pull request title**  to
-start with a semantic prefix.
 
 Examples of commit messages with semantic prefixes:
 
@@ -108,6 +105,7 @@ Common prefixes:
   - perf: A code change that improves performance
   - 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)
+  - vendor: Bumping a dependency like libchromiumcontent or node
 
 Other things to keep in mind when writing a commit message:
 

docs/tutorial/electron-versioning.md

@@ -136,12 +136,12 @@ We reconcile flagged code with our versioning strategy as follows:
 
 We seek to increase clarity at all levels of the update and releases process. Starting with `2.0.0` we will require pull requests adhere to the [Conventional Commits](https://conventionalcommits.org/) spec, which can be summarized as follows:
 
-* Commits that would result in a semver **major** bump must start with `BREAKING CHANGE:`.
+* Commits that would result in a semver **major** bump must start their body with `BREAKING CHANGE:`.
 * Commits that would result in a semver **minor** bump must start with `feat:`.
 * Commits that would result in a semver **patch** bump must start with `fix:`.
 
 * We allow squashing of commits, provided that the squashed message adheres the the above message format.
-* It is acceptable for some commits in a pull request to not include a semantic prefix, as long as a later commit in the same pull request contains a meaningful encompassing semantic message.
+* It is acceptable for some commits in a pull request to not include a semantic prefix, as long as the pull request title contains a meaningful encompassing semantic message.
 
 # Versionless `master`