Thanks to the discussion Kai opened some time ago some of you actively started helping to work on issues and PR reviews, thanks a lot for that!
In order to keep the issue list small on the one hand but document and track all bugs on the other hand it could be helpful to actively “invite” contributors to work on the according issue. We could comment with something like:
“Could you please have a look into this one @steve1?”
Since we cannot know all the active contributors it helps to search through the latest closed PRs for this binding. It is likely that either that PR caused issue or at least the contributor knows enough about the certain technology to help out directly or knows somebody else who possibly can help.
I would say that this ought to be “required” – the set of knowledge about a binding, and the ability to properly test them, is spread out all over the world! Past contributors, who almost always feel like they have a stake in the quality of the bundle going forward (and often rely on it themselves), should have a good opportunity (like, say, the length of a two-week holiday plus a day ) to chime in with their views on the issue.
I think the potential for either losing knowledge, accidentally alienating contributors, or introducing regressions from incomplete knowledge is extremely high for this kind of project, and inviting contributors back is essential for further improvements.
I agree. I’ve done this in a number of cases but in other cases it’s not clear whom to invite. For example, some of the developers are not even on GitHub any more. In other cases, the question has already been asked quite some time ago with no response.
I also look at git commit history and the @author tags in the files to identify people that may have knowledge of an issue.
It’s clear that some of the bindings currently have no interested “owner”. It could be useful to categorize bindings according to the development activity and support activity. I’ve seen comments that some of the OH1 binding developers have moved on to OH2 and have no interest in diagnosing or fixing problems in OH1 bindings they developed because they don’t use OH1 any more (very understandable).
That would be fine. It would be good to structure the wiki information in a way that programs could use the data to do things like automatically label issues or to support statistical analysis.
I think I’ve done as much as I can related to resolving the remaining OH1 issues (currentlyabout 380 issues with 150 bugs). I’ll keep an eye on new issues as they arrive, but I’m going to start to focus my efforts elsewhere. @maintainer
Thanks a lot for your efforts. Great to have the list completely reviewed now. We can probably tear this amount (380) if we would consequently close feature-requests and especially being stale for a long while. Or what would you think? Is there any potential to push this even further?
I’d like to push it further, if possible. I agree about closing old feature requests if there hasn’t been any interest, but I’m more concerned about the bugs. The existing bug issues may be open/unresolved for various reasons. It would be useful to label the older bugs to document that reason. For example, the label might be “needs-developer” or “cant-reproduce”. In the cases where we decide to label an bug as “wont-fix”, I think we should close the issue as being resolved (which is a different resolutionthan fixing the bug in this case).
) to chime in with their views on the issue.