@gianm updated. I think we should also make the default repo settings on PRs to do a merge and take the PR description (e.g. not just force a *-list of commit messages (which often aren't descriptive at all).

@gianm thoughts here?

@gianm any thoughts here?

@gianm updated. I think we should also make the default repo settings on PRs to do a merge and take the PR description (e.g. not just force a *-list of commit messages (which often aren't descriptive at all).

By "do a merge" you mean "squash and merge"? I think that's already the default and IMO is best.

I'm not sure how I feel about the default description. The problem with concatenating the commits is it can include a bunch of junk. The problem with using the PR description is they tend to be long, IMO too long to be good commit messages. I generally try to edit the commit message when I'm merging a PR. I think there's no way around manual edits being a good idea. Anyway, I'm sort of ambivalent about the default messages, as a result.

@gianm updated. I think we should also make the default repo settings on PRs to do a merge and take the PR description (e.g. not just force a *-list of commit messages (which often aren't descriptive at all).

By "do a merge" you mean "squash and merge"? I think that's already the default and IMO is best.

I'm not sure how I feel about the default description. The problem with concatenating the commits is it can include a bunch of junk. The problem with using the PR description is they tend to be long, IMO too long to be good commit messages. I generally try to edit the commit message when I'm merging a PR. I think there's no way around manual edits being a good idea. Anyway, I'm sort of ambivalent about the default messages, as a result.

Ah – I wasn't referring to the merge method itself, but rather the default commit message provided by GH when merging (I notice it's a *-bulleted list of commit messages, which aren't that descriptive). I was thinking the commit message could be by default the PR description (and people can trim as needed). Just a minor thing, not too important.

Btw, this PR should probably be dev:? It doesn't seem like a minor thing, as it will affect the dev workflow for everyone. To me minor: is for stuff like correcting spelling errors. And here we go with second-guessing the tags before they're even added 😄

Btw, this PR should probably be dev:? It doesn't seem like a minor thing, as it will affect the dev workflow for everyone. To me minor: is for stuff like correcting spelling errors. And here we go with second-guessing the tags before they're even added 😄

Done. I think that difference is largely immaterial; what does matter is that we are now recording context inside the git tree, which makes it WAY easier to bisect for issues without digging through PR links. It also helps that GH release notes structure can be auto-generated from the conventional commit syntax (meaning you don't need to rely on users specifying Release Notes tag and instead do something like (fix!: blah) to know that it's a breaking change).

I could add a general guide on how/what to label things in the workflow – that might be helpful.