My main point about the post Future of openHAB was that I wish we could grow the number of people helping maintaining the project.
Since my post nothing actually happened: We still have 450 (!!!) open issues and 70 open pull requests on openHAB 1.
In this topic I would like to discuss how we can manage to get these numbers down - we need definitions on how people can qualify for becoming a maintainer, we need some clear rules written down and most importantly, we need the people willing to do it!
Hello Kai. It is definitely a challenge. I looked through the open PRs after your initial post and many of them were related to bindings for hardware that I don’t have and so I didn’t feel I could review them properly. I’m guessing that others may be in the same situation. I did review and comment on other PRs that were related to hardware I use or were core changes. I’ll take a look at open issues next.
I’ve started look for issues where I can provide assistance. I know it must be a big job for @teichsta to keep the labels up to date. Is it possible for maintainers to have permission to set or update issue labels? There are many issues, but it’s not clear how many are feature requests or bugs. It would also be useful for me if the issues had a label specific to the binding (or core functionality).
Hi, I’m brand new to openHAB but have been a software developer by profession for about 11 years. A quick search in the PRs and issues for the word “binding” show that a large percentage of the items are binding related. It also seems that (as Steve said above) a lot of people simply can’t help if they can’t test the specific hardware the binding is for.
So would it make sense to restructure the project in such a way that the bindings are more of plugins which are individually developed and maintained, separate from the main repo of openHAB? That way those who are interested will naturally take over and create / maintain the bindings they’re interested in and the core developers can concentrate on the core software.
Please take my comments with a huge grain of salt in that I haven’t delved too deeply into the software (yet) and just thought an “outsider” perspective might help. I look forward to getting my system going and thanks for all those who have contributed!
yes, that would indeed be helpful, but Github simply separates between READ and WRITE permission for a repository. Since labels require WRITE permissions this would require WRITE permissions to the whole repo which i am not sure we are willing to give so many people.
When using a separat (sub)module per binding this would be feasible easily.
I understand it wouldn’t be desirable for issue maintainers to have full repo authorizations.
Maybe there some other creative workaround. For example, we could create a simple web app for managing issue labels using the GitHub application API. I don’t know if it’s possible, but maybe the app could use the GitHub OAuth api for authentication but manage its own authorizations? Just brainstorming…
Maybe I should clarify what I expect from a “maintainer”:
Code review of contributions: This is NOT at all about doing functional tests - so no hardware needed. In fact, from the bindings that I reviewed in the past, I only had the hardware at hand for a small percentage of them. Code reviews are rather about checking code style, architecture, legal issues, etc. I have listed such things here, nothing of it is related to having the hardware.
Actively managing the repository: Keeping track of incoming issues and PRs, making sure that they are tagged correctly and assigned to the right person or rejected immediately. This is manual work that cannot be automated and no restructuring can really reduce this work. The only solution is coming up with ways to distribute this work among more maintainers. The discussion on the best repo structures and access rights is here.
Thanks for your offer to help!
I have tried to document how to best get involved here: openhab-addons/CONTRIBUTING.md at main · openhab/openhab-addons · GitHub
So becoming a maintainer means showing that one has some track record of active involvement in discussions, contributions etc. You can start with that right away by helping on questions in this community or commenting on issues at Issues · openhab/openhab1-addons · GitHub - finding once that are clearly outdated or do not make sense and suggesting to close them, would already be helpful.
I understand. I don’t know if I’m considered a “maintainer”, but I do currently participate frequently in the forums, answering questions and writing tutorials. I’ve submitted PRs for bug fixes and new features and have commented on other PRs and issues.
I should also clarify my motivations. As an active user of openHAB I have an interest in its continued development and in a stable runtime. Like most people, I have limited time resources to invest. I’m sure you understand this better than most given the amazing efforts you’ve made to create openHAB (thanks!). That said, I’m less interested in spending that limited time doing code style reviews versus ensuring the code is working correctly. Most (not all) of the list you referenced can be automated using static code analysis tools.
Correct me if I’m wrong, but my understanding is this is not currently practical until there’s a major repository restructuring. I’d definitely be willing to help organize issues and PRs if I had the authorizations.
I see much discussion and I see people volunteering and trying to find ways to help. That’s something. Those hundreds of issues and PRs are not going to be resolved quickly. It seems to me that the focus should be on removing the blocks to wider participation.
Not sure if I agree with “most”, but at least some, yes. So if anybody wants to give this a try, it would be wonderful to have a Maven plugin that does a lot of these checks fully automatically - I am all for it. Nonetheless, from my experience many things come up during a review that automatic tooling cannot detect.
Ok, I correct you: As you mentioned above, you have a proven track record of being an active and valuable community member, so I just added you to the openHAB Github repository as a maintainer - so you are now free to assign issues, add labels etc. Thanks for your willingness to help!
Those hundreds of issues and PRs are not going to be resolved quickly.
No, but I think it would already be a huge improvement, if everything that isn’t an issue (e.g. already fixed, a feature request without anyone working on it, etc.) is closed, and the rest being assigned to the the authors of the code in question. I think that many authors actually do not know about certain issues, because they do not track the whole list actively themselves and since they do not get it assigned, it simply stays unnoticed.
Thanks, Kai! I’ve started labeling issues and asking some questions in comments for issues that look like they should probably be closed (e.g., the related PR was merged).
@teichsta, let me know if you have any related guidelines for me.
I think the Linux Foundation is great example both for the organisational setup and the source code maintenance.
I didn’t yet look into the details of how the Kernel is maintained. The only news I heard recently from LinuxCon is that they wish to have more Kernel maintainers. Do you have any good reference on how they organize the work?
Like @steve1 mentioned, I also have limited time to help, but would be willing. I’ve made a few small contributions to insteon and zwave bindings related to my unsupported-at-the-time hardware, but I haven’t been able to do anything major.
I’m a software developer by trade and I’d be happy to lend my skills as well. After reading your other post, I looked at some of the open PRs. Maybe I made a mistake starting at the oldest, but I looked at ones that caught my eye every one I looked at had messages from @teichsta to the PR requester asking if they made any progress since the last interaction. I wanted to try and review at least one, but then that whole “limited time to help” thing caught up to me.
Not sure I have much else to add at this point, but wanted to share my experience and let @Kai know that I at least noticed his original post and attempted to do something.
some basic tech know-how with mainstream technologies (e.g. setting up a windows machine, installing software, configuring parameters, adapting registry entries, etc.)
but no real developer (maybe “some” (bad?) experiences with various programming languages (VBA, Java, C#, SQL)) but more a kind of “experimentals” no real code writing
using open source software only if it is strongly recommended by friends or it is the last alternative
being part of an open source developer community is like being the exot and without any experience in that environment I prefer to stay on the “reader-side” instead of the “(code)writer side”
becoming familiar with openhab due to running from one issue to the next one but always willing to accept the challenge to resolve the current and the next problem (thank you forum) AND
willing to support but have no clue how and where we can support (just donating money is someting between boring, not transparent where the money is really needed and used, no real hans-on help, no real “resolving” a technical issue (either a bug or a change request)
I’m pretty sure that there are hundreds of users who would love to support the further development if the issues could be adapted to the above described skill set. What I see today is that the break down of the backlog could be improved significantly. At least parts like “enhance/update documentation”, “providing examples”, testing and giving feedback, management tasks, etc. could be done by users like me (us). But this needs tasks which says something more than “enhance *%ç/&/( with ?=)()/ç%&” - such issues make it not clear to me what I can do there.
One more thing (no, I’m not an Apple fan):
I know that there are a lot of software engineering companies (mid-size 100-500 FTE) who are searching for NGO projects that they can support - either for participating in the success of the projects (marketing) or educating their staff (say No to more “Hello World” projects!) or for donating reasons. Since IoT is the “the next big thing” but no one has really good ideas (a smart watch is no good idea!) an automated home is not only cool - it fulfills a “need” and this is the argument how to win (money-/developer-)sponsors from the private sector.
Last but not least: thank you to all developers who have invested their private time in this project.
Right, those people are very valuable and they build the community - they are what I consider the contributors. What I am looking for through this thread are people organizing the work, i.e. maintaining the backlog, keeping it clean, easy to understand and up to date (besides many other things). So far Thomas was the one doing this for openHAB 1, but he couldn’t cope with it anymore. I am already taking care of openHAB 2 and Eclipse SmartHome while doing major core development work there, so there is simply no chance that I could step in. Luckily, we have already found two great maintainers with @hakan and @steve1 who are both doing a tremendous job here - within a few days, we went below 400 open issues, which is a huge step forward already; thanks!
But since you were asking for “simple” jobs that people could help with, I actually asked for some of those things with not too much feedback so far, so possibly it is a good time to repeat them now:
I would love if people could test openHAB 1 add-ons on openHAB 2 and give feedback, see this thread
We need a wikipedia entry! Native english speakers are very much invited to help, see here.
It would be great, if we had dedicated people who would look out for such fund raising and winning sponsors for sure! This is also a very important reason for me wanting to found the charity organisation, because this is the legal entity which could then be sponsored by those companies.
This is where I have been trying as time permits, and helping those folks that I can as I learn the bindings. My latest one is here, though it may not have been seen. Enphase Energy binding works .
also many, many thanks from my side! I didn’t manage to keep the list small but you (as representatives of all the others being active) helped to gain traction in this area again.
