fix some spelling

[SimonCropp]

No description provided.

[ghost]

Thanks SimonCropp for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[SimonCropp]

does this buy me some good will for me being disruptive in #3405 ? :)

[michael-hawker]

Hi @SimonCropp! We do appreciate the spelling contributions, it's a huge help. I know it's somewhat obvious in this case, but it'd still be great to provide at least some description in the PR body and not just delete our template. :) Checking things off like 'no breaking changes' is important to know at a glance.

We'll see where the other PR goes, as I stated, it'd probably have been better to start it off as in issue for discussion first in the repo. We do need to update our contribution guidelines, I'm planning to get to that soon after UnoConf as part of the review of #3269. If you have any feedback there as a new contributor, that'd be great! Thanks!

[SimonCropp]

@michael-hawker

Checking things off like 'no breaking changes' is important to know at a glance.

There are some spelling errors in the public api. i plan on doing those as a single PR, and we can pick and choose how to handle each one.

re instantly know if a public api has changes... have u considered using PublicApiGenerator? https://github.com/PublicApiGenerator/PublicApiGenerator

it serializes you public contract to a file, which you commit to source control. then if someone accidentally breaks an api, the test fails. and on any PR you can look to see if that one file has change to visualise any api changes in one place.

[mrlacey]

Having checks for things like "Tested code with current supported SDKs" and "contains NO breaking changes" in the PR template are about more than a way of ensuring that nothing has changed.

They provide (at least) two things:

• A prompt to the person submitting the change that this is something to be considered as part of the change.
• An indication to the person doing the review that there are or aren't specific things to be considered as part of the review.

Without accurately completed checklists like it increases the burden on the reviewer.

[SimonCropp]

@mrlacey fair enough. i will take that on board for the next PR i submit to this project. given i didnt follow the process, i will close my current PRs