Quality assurance/review process documentation

[DNin01]

I think we should document our pull request review process or some guidelines for pull requests.

While or after we do that, we could also discuss some additional things to add to our review process. For example, I think we should address how assignees should work and make sure every pending review request is completed before merging.

A couple years ago, @WorldLanguages proposed guidelines for potential uses of assignees and reiterating PR merge requirements. We've yet to take those a step further.

What do you think about this, @WorldLanguages?

I can try to write or co-write the guidelines if you want. We can start by documenting our current guidelines as explained on ScratchAddons/ScratchAddons#5238.

Related

• Add quality guidelines page #219 (not the same thing but tackles a similar area)

[WorldLanguages]

Here are some thoughts, in no particular order

• I usually don't have a lot of time for big overhauls, for example splitting the settings page into a separate project.
• When that happens, the settings page project can independently choose their own review processes.
• Similarly, addons with clear owners that have been here for years (for example mxmou and dark modes) could also decide themselves how to handle reviews (including changes proposed by themselves)
• For addons with trusted owners, only basic reviews are strictly needed (security, compatibility with other features, and other basic checks)

So we are left with deciding how to handle all other pull requests, as well as additional guidance for outside contributors. The main point I want to make today, is that having a single pull request review process makes no sense for our project.

About addons maintained by mxmou, garbomuffin, etc. we lack processes to check whether they are still around or if they have decided to take a break, that's also an area worth exploring. Right now if they go inactive, it's not really noticeable for a while.