I've noticed a few PRs made since the latest template update, that have said things like "this PR was created because of #ISSUE" or things along those lines. It seems like people are reading the template and following its advice! But Github requires a specific syntax to auto-close an issue, so we may as well encourage people to use that to save everyone a bit of time. So in this PR I've added a comment to the template explaining that.
I think no one is reading this because I've seen an increase in draft
PRs. To fix that I've moved the draft statement to the top. I also think
the number of check boxes is a lot and isn't resulting in better PRs
because the length means they are not being read. I removed ones that I
think are repetitive or unhelpful. I wish I could A/B test this...
Two things were changed:
- line number are added to errors so its easier to find them
- blank lines with trailing whitespace now correctly show 1 error
(trailing whitespace) instead of 2 (trailing whitespace + wrong
indentation)
As the codespell dictionary changes between versions, we should declare
explicitly the version we are ready for so that this CI doesn't break
every time there is a new version.
Ideally this would be upgraded periodically to catch new errors, but I
don't think the need is urgent enough for us to fail CI on PRs.
There have been a number of recent commits introducing incorrectly
formatted CHANGELOG entries:
- 9f0b8eb was missing an author
- 936a862 had trailing whitespace
- 238432d had wrong number of leading whitespace
- 51852d2 had wrong number of leading whitespace in the header
To prevent these inconsistencies from happening in the future, I wrote a
small linter for CHANGELOG files that catches all of the above errors.
The major change is to add checklist so that it's easier to be read
than comments.
Also, `Summary` is not clear about what should be written, so here
it's changed to `Motivation` and `Detail`.
Finally, it clearly says they can discard this template if they need to.
While the idea of cleaning up the the PRs list by nudging reviewers
with the stale message and closing PRs that didn't got a review in time
cloud work for the maintainers, in practice it discourages contributors
to submit contributions.
Keeping PRs open and not providing feedback also doesn't help with
contributors motivation, so while I'm disabling this feature of the bot
we still need to come up with a process that will help us to keep
the number of PRs in check, but celebrate the work contributors already
did instead of ignoring it, or dismissing in the form of a "stale"
alerts, and automatically closing PRs.
If the `client9/misspell` repo is compromised, an attacker could control
the contents of `install-misspell.sh`. Since we execute that file
directly, we should use a URL that guarantees its contents will not
change.
Note that, at the time of writing, the last commit to `client9/misspell`
was in March 2018 (client9/misspell@c0b55c8239),
so the code appears to be stable.
Also, although using a tag would be prettier than using a hash, the
repo's last commit is after its most recent tag (`v0.3.4`).
A lot of bug reports have useful reproduction steps that could be a reproduction script, but they seem to have either not found the reproduction script template or didn't read the 'contributing to rails' page at all. This links to the same page at the section that includes the reproduction scripts with a stronger call to action making it clear that they need a reproduction script.
`codespell` works with a small custom dictionary and seems to find perhaps more spelling mistakes than `misspell` which really only fixes commonly misspelled English words.
Not all spell checkers can check all file types and most spell checkers can't find all the errors.
https://github.com/codespell-project/codespellhttps://pypi.org/project/codespell/
Misspell -> Correct commonly misspelled English words... quickly. A Golang library that runs without a dictionary.
https://github.com/client9/misspell
Can even autofix with '-w'
Since c1e7268c83336777655b20f9e23892d8143c0243 we install the latest
version of RuboCop in our GitHub Actions workflow for speed, but this
sacrifices reproducibility; the results will change whenever RuboCop
publishes a new version. Instead we can add a new group to our Gemfile
that just contains the dependencies necessary to run RuboCop, and skip
installing everything else in CI.
Unfortunately it's not possible to tell Bundler to only install gems
from a single group, so we have to tell it not to install every other
group instead.
When pull requests have RuboCop offenses they need to click
"Build and run RuboCop" section and scroll about 200 lines
to skip `bundle install` output.
This change splits "Build and run RuboCop" into two parts.
then "Run RuboCop" section only shows `bundle exec rubocop --parallel`
output
