|
|
||
|---|---|---|
| .. | ||
| config.json | ||
| fifty-radios-beam.md | ||
| hungry-clocks-move.md | ||
| light-bobcats-prove.md | ||
| nice-jobs-ring.md | ||
| README.md | ||
| strong-pugs-cover.md | ||
| unlucky-tips-smash.md | ||
Changeset
Writing guidelines
Rules:
1. Avoid repetition when describing bug fixes
Bad:
Fixed a bug where the component fired confetti uncontrollably when typing into the input. Fixed a bug when...
Good:
The input no longer fires confetti on typing.
2. Use more personal tone
Bad:
It is now possible to use the class xyz directly in…
Good:
You can now use the class xyz directly in…
3. Make it about the user, not the code
Bad:
Added the X and Y fields to the schema returned by Z.
Good:
You can now see how many users are connected to a deployment (X), and the users capacity of the deployment (Y).
4. Use a minimal amount of fluff
Bad:
After many long nights at the office, several cans of beer, and consuming the amount of pizza equal to the surface of a helipad, we finally managed to squash a bug that’s been haunting you forever. Its origin reaches back to the times when Tim Berners-Lee…
Good:
The application no longer shuts down when attempting to abort a payment.
5. Use a template when lost
If you don’t have an idea how to start, you may use some of those openings:
- “You can now…”
- “X no longer does Y when Z.”
- “X no longer does Y. This means you no longer need to Z.”
6. Describe known issues
When the release introduces some issues or limitations, describe them:
You may experience issues when trying to use the new view with an adblocker turned on. The issue will be fixed in the next release. For now, please…