This issue is to continue discussion in the comments of #2178 and #2270 regarding the conventions/etiquette of merging a PR, especially one's own.

I suggest we categorize PRs (either using Github labels or own judgment) into the following types which probably will have different "rules" for merging:

• Obvious bug fix in the code or docs.
• Code refactoring/cleanup or larger restructuring/rewording the docs.
• Changes to the public plugin API
• Small UI change or changing default/original behaviour of something
• Large UI change
• Larger more structural changes to the code

Feel free to edit the description and re-word those or add others which are surely missing.

The criteria for a PR being mergeable might include such this as:

• None
• Waiting at least N days to see if anyone cares/objects.
• At least N people must approve the PR explicitly using Github "review" stuff.
• At least N people must have done a proper code review.
• At least N people must have actually tested it.
• It must be tested on X platforms.

Again, feel free to edit/add to this list.

I guess with the above lists, it's just a matter of attaching the criteria to each type of PR, and then codifying that somewhere like HACKING, the wiki, a new CONTRIBUTING file, or wherever. One way to do this association might be to do some simple polls of the contributors.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.