there’s probably a 3.) see - this meetup thread
I just would like to publicly thank @hakan for the enormous amount of job he is doing and for the great commitment
3 Likes
So there are many open PR’s with the newbinding label. How can those be integrated faster?
Maybe the review process could be split into multiple phases so that it could be done by multiple people, for example:
- stage 1: check for code cleanliness, correctness, documentation -> could be done by ‘junior’ reviewers
- stage 2: architectural review -> could be done by ‘senior’ reviewers
- stage 3: operational quality review -> one or two beta users confirm the binding really works
Having a staged approach would create a ‘reviewer career path’ were people could start reviewing the basics and grow into becoming a senior reviewer…
Maybe Sonar with some custom rules could also offload some of the work.
And last but not least, what can I do to help?
2 Likes
I very much like the idea!
So any “newbie maintainer” could pick any PR and review it (it is probably enough to leave a comment on it, so that nobody else picks it). Once he feels he is ready for step 2, he can apply for becoming a @maintainer and show his “proof of records” as a qualification.
I like that idea. From my side I’m very willing to support but I feel I lack the skills to be reviewing others bindings in a full way. In the proposed way indeed it would be easier to contribute
FTR: The stage 1 could be simply checking that the coding guidelines are fullfilled. Senior maintainers should actually help to improve those guidelines, whenever they come across common problems that are not covered by them.
So we should make it easier for people to get started. I can also imagine it could be done by two people working together in a mentor/mentee approach.
simply checking that the coding guidelines are fullfilled
Let’s try to automate what can be automated.
Why does this remind me of Lemmy Kelmister’s funeral, and the whole motorbike culture? 
All joking apart, you will have people that are more comfortable in either stage, indep. of “seniority”. Me for example, after cranking out all these bindings, would like to spend more time on adding features to the core (Notification for example), knowing that I am also sometimes a lazy bum that fails at stage1 for my own work.
K
Why does this remind me of Lemmy Kelmister’s funeral, and the whole motorbike culture?
Honestly, I have no idea. Is there a movie I should see?
you will have people that are more comfortable in either stage, indep. of “seniority”.
Seniority may not have been the best word to use. Of course some people will feel more comfortable in stage 2 or 1 depending on their personal preference. But I do believe people need to go through the different stages. If someone doesn’t understand the value of of code cleanliness, simplicity and documentation, it will be impossible for them to do a good job on an architectural review.
knowing that I am also sometimes a lazy bum that fails at stage1 for my own work
I still have to meet the person who has never ever taken a short cut…
I back davy’s idea and it’s something we do at my work place that works well.
However from experience you can still end up with a bottle neck, inevitably we have more junior reviewers than senior reviewers, and by the nature of seniority they usually have other commitments and/or problems to solve but we ask that they endeavor to find the time to keep the system moving.
As I mentioned to Kai I’d like to help out a bit, so if this is the system agreed upon I’ll try and start looking at open issues or un-reviewed PRs over the coming weeks.
[off-topic on]
Never seen a documentary on how motorbike clubs function? it is remarkably very similar. Lemmy, of Motorhead fame, just happen to pass away.
[off-topic off]
@Kai, how can we move forward with this? Should we document a formal process? Or can people just start reviewing a PR after adding a comment ‘Stage 1 review started’ to the PR?
For a quick start, I think we can agree on this for now.
Then, we should update the maintainer manual accordingly.
I have to admit that my call-out for help didn’t really solve the issue. Looking at the recent activities on openHAB 1 PRs (58 open) and issues (476 open), it is now merely @chris taking care of all Z-Wave stuff and @watou doing the best he can on all the rest.
I would actually assume that it is fairly easy to get the numbers down on openHAB 1, since the activity there clearly slows down as more and more developers have moved over to openHAB 2, which has created a major issue for myself there now: The number of new bindings is huge and I am the only one doing code review and development support on them.
So I am torn between asking @maintainer to help out on openHAB 2, but I feel that it is more important to first make sure that the long standing PRs on openHAB 1 are processed and merged. Is there any realistic chance that we get things going again?
I’d be glad to help out on openHAB 1 where possible. There are a vast number of ancient issues there that haven’t seen activity in ages and should probably just go away.
Issues 3891 and 3995 should be closed.
done
I expect so as well, so it should be just some routine work to go through it, see if can be closed etc - no profound technical skills required 
Most issues are relative to bindings. Each binding author should take time to analyze and close issues relative to their work.
Have you a list of active binding maintener?