Spell-checking forces text of user issues to be changed in the release notes/
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- github
- Domain
- documentation
Research direction
Start with the release-note process described in this issue, including the GitHub release notes and the website's manual copy-and-paste step. Determine where spell-checking changes issue text and whether that process can preserve the original wording; done means release notes no longer require altering copied issue descriptions.
Written by the indexing model from the issue text.
Description
I'd say this is fairly minor and depends on the policy of each project regarding spelling of the text in user issues.
My own policy in the engine project (and the whole project when I was responsible for it) was always to keep the exact text entered by the user unless it wasn't understandable at all. (In that case I'd change it and add a comment to the issue) I felt (and still do) that it was disrespectful to "correct" trivial errors made by the user...
The user descriptions live in the GitHub issues database. When creating releases, they are copied verbatim to the Release Notes on GitHub by an automatic process. Creating release notes on the website is currently a manual process, which I do using cut and paste from GitHub. In future, I would have wanted to automate it.
Whether done manually or not, however, the issue descriptions, which are listed in two places in GitHub are sometimes invalid for the release notes on the website and must be changed. This bothers me a bit because the description of a given issue is now in three places and one of them is different. I'd suggest eliminating spell checking on the release notes if that's easy to do.
- Dominant language
- Dockerfile
- Stars
- 600
- Forks
- 158
- Avg merge
- 16h 8m
- Merged PRs (30d)
- 21
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nunit/docs
-
area:framework
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
area:framework
-
area:framework
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
area:framework
Difficulty 4/5 3-5 days Newbie friendliness 40/100
Similar issues
-
sync-en
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
agilepathway/label-checker#640 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
BasedHardware/omi#15662 · 1 comment ·
-
documentation help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100