Respec: Teach release script about "enhancement"

[marcoscaceres]

The release script doesn't know how to treat commits prefixed with "enhancement"... they should be treated the same as "feat". The kids are also using "enh()" as a shorthand, I hear. We might want to support that too because "enhancement" eats like half a commit message.

[marcoscaceres]

Relevant bits to change:
https://github.com/w3c/respec/blob/67edc4971ece9c91acccc7b03bc15a47cb136363/tools/release.js#L134-L146

And, in particular:
https://github.com/w3c/respec/blob/67edc4971ece9c91acccc7b03bc15a47cb136363/tools/release.js#L196

[marcoscaceres]

@janiceshiu would you be ok to take this one? Should be a quick one. We can probably just use the same emoji that we use for "feat".

[marcoscaceres]

(the release script has no tests ... because that's how we roll 🔥🦹‍♀️🔥 )

[sidvishnoi]

The kids are also using "enh()" as a shorthand, I hear.

:rofl:

We might want to support that too because "enhancement" eats like half a commit message.

:+1:

[saschanaz]

Or just enh, because we don't support longhands e.g. accessibility, documentations, and feature 😁

[marcoscaceres]

Whatever is most natural. So long as we all agree on what to use and we are not overly restrictive.

[saschanaz]

BTW, what kind of enhancement are we talking about? Can't we use feat, fix and refactor there?

[marcoscaceres]

That's a great question... because it makes me think we are solving the wrong problem. Maybe what we actually want is a GitHub action that checks that every pull request starts with feat, fix, refactor, or one of our known types.

[janiceshiu]

Since we're discussing naming... is there a guide somewhere that contributors - especially new ones - can refer to when naming their PRs and commits?

back when i first contributed to respec, i read the developer's guide and didn't see anything about the format. I ended up guessing that the pattern is something along the lines of $TYPE(path/to/changed/file): $SUMMARY_OF_PR by looking at recent commits to master. I named my recent PR by guessing and imitating the same pattern.

Also - now that I look at recent commits again - some commits with the filename have the filename's extension, and others don't. If this is important, perhaps we could standardise it and make it clear.

[saschanaz]

We are generally following AngularJS conventions. This should be added to the guide too 👀

[saschanaz]

The developer's guide doesn't really seem to be a contribution guide. Should we also add a GitHub pull request template too?

[janiceshiu]

We are generally following AngularJS conventions. This should be added to the guide too 👀

I did not realise this. Yes - a guide would be good. We do allow more types than the linked doc though. For example, we have l10n and breaking change. Thus, perhaps we should write a respec-specific guide? We could always link to the original inspiration.

---

The developer's guide doesn't really seem to be a contribution guide. Should we also add a GitHub pull request template too?

This would be good, yes. To start, we could include something like

Fixes #issue_number 

[] All tests pass

Regarding the contribution guide - things such as a reminder to run prettier on one's code would also help.

^ the suggestions above are based off my experience as a new contributor to respec - these are things I didn't know and figured out by trial and error or by someone letting me know.

[marcoscaceres]

Ok, let’s start with adding the labels to the docs and saying we roughly follow Angular. We should add a CONTRIBUTING.md file too, with the labels and a link to the developer guide.

[sidvishnoi]

Closing based on https://github.com/w3c/respec/issues/2618#issuecomment-564496630