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.