Contributor Checklist suggestions

Development
1

Hello! I had a few suggestions for improvements to the Contributor Checklist to make it more friendly to new contributors and hopefully reduce the amount of failed checks:

  1. In the first bullet point about linting and formatting, add a mention about make lint / make fmt / make fmt-ui, or at least mention that various linting and formatting commands can be found in the Commands section of the Development page. The way that bullet point is currently worded, gofmt is the only formatter that is specifically called-out, so I didn’t realize that a specific formatter needed to be run for non-Go code. I had forgotten about the formatting commands on the Development page, so I manually ran a formatter for CSS, which apparently had different rules than make fmt-ui. A reminder about these provided linting/formatting commands in the checklist would have helped me.
  2. Add make validate as a step in the checklist. Maybe as the last step on the list?

I think these two updates would quickly teach new contributors how to ensure they do not submit a PR that wastes the moderators’ time. If these updates are desired, I would be happy to write a new draft of the checklist for review.

2 Likes
2

I agree. I ran into these exact issues the first time I submitted a PR.

1 Like
3

Alright, I wrote a draft with my proposed updates. I also reordered the steps so that searching PRs & issues comes before any other work, and so that comments are added before formatting.

(Btw, I replaced the mention of gofmt with make fmt because I believe that’s just another way to run gofmt but without any ambiguity about which parameters should be used. I think.)

Contributor Checklist

Please make sure that you’ve considered the following before you submit your Pull Requests as ready for merging:

  • I have read through formerly submitted Pull Requests and Issues to make sure that this contribution is required and isn’t a duplicate. Also, so that I can manage to close any Issues needing closed relating to this feature submission.
  • I have adequately commented my code with the expectation in mind that anyone else should be able to look at this code I’ve submitted and know exactly what’s happening and what the expectations are.
  • I have run code linters and formatters to make sure that my code is well-written and readable.
    • Commands for Backend: make lint and make fmt
    • Commands for Frontend/UI: make fmt-ui
  • I have run make validate to make sure that my code will pass all checks after my Pull Request is submitted.