Merge approvals #14703
kaikreuzer
announced in
Add-on Maintainers Discussions
Merge approvals
#14703
Replies: 2 comments
-
Can the proposed rule modifications be applied? |
Beta Was this translation helpful? Give feedback.
0 replies
-
As nobody vetoed, I'd say yes! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Dear @openhab/add-ons-maintainers,
Many of us (me included) weren't able to spend as much time on PR reviews than in the past - while the number of PRs kept growing and growing with quite a long list of new binding contributions waiting in the queue.
It feels as if @fwolter handles most load right now - this is really impressive and I think he deserves huge kudos for that. I hope we'll be able to support him on that mission in the future better again.
It is clear that we have a lack of review capacity, though, and I guess we will have to think about counter-measures.
As all of us are very experienced reviewers by now, I'd first suggest to waive the "2nd maintainer review" on new add-on PRs. Just like for other PRs, I'd suggest that it is enough that any maintainer can merge right away after a successful review.
Secondly, I think we should try to relax the code style/quality level a little bit. I've seen many complaints of contributors that think that contributing is too hard because of the many iterations during a review. I know from my personal reviews that it is hard not to comment on code parts that can be written more elegantly and that can be improved in some way. But unless something is really wrong or against the general guidelines, we might be more relaxed and let contributions pass quicker than now. This is clearly up to the judgement of the reviewer where it is worth to jump in and what to accept, but if you think that it'll safe yourself time and that it won't have a negative impact on openHAB itself, you might want to decide accordingly. Imho, priority should be on (1) consistency towards the user (e.g. consistent Thing modelling, proper README) and on (2) architecture consistency (correct use of openHAB APIs, use of provided features such as shared HTTP client, system channel types, etc.) and on (3) consistent runtime behavior (like correct Thing status changes, clean shutdown and proper logging).
Wdyt?
Beta Was this translation helpful? Give feedback.
All reactions