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 or view it on GitHub: https://github.com/geany/geany/issues/2283
