Growing the number of active maintainers

I don’t believe we’ll be able to make significant progress on the issue backlog without some changes to the way the project is run. When I was working to resolve issues, it seemed to me that there was resistance to closing ancient issues (with a “won’t fix” disposition, for example). Maybe that has changed now. If so, that should be made clear to the issue maintainers.

In many cases, there was no active maintainer for a binding. In other cases, even the maintainer or original developer wasn’t able to reproduce or diagnose a problem. Addressing this type of issue actually does require significant technical skills.

Last fall I posted information about bug statistics and my perspectives about to make progress with the issue backlog.

There were no responses. Of course, that data is quite stale now. I think there are about 100 more open issues since then.

2 Likes

It could be a good idea to give a priory on merging PR fixing issues. It will reduce at the same time the volume of open PR and the volume of open issues.

1 Like

I recognize this. Several of the open issues, the original requester either does not respond anymore, or the issue is not reproducible anymore. As no real solution is there, these kind of issues will remain open forever.
Don’t know if we have more labels, but would suggest some other label to close these kind of issues, or indeed use the wontfix label for it.

Would be good to have some clarity how we can trigger it such tatus change, as I don’t think binding maintainer can close an issue.

Seems like there should be some standards set for both how issues are opened and how they get closed.

Issues get logged with inadequate information. This is typical and at least somewhat expected, but such issues should receive a quick kick to the curb, especially in the frequent case where the submitter disappears after filing the ticket.

I’d like to see every issue tagged with the binding it affects (or whatever other part of the system it is).

A new Github feature for issues and pull requests is the ability to use a template file as announced here. Maybe something like that could be implemented.

1 Like

I think at least some of you get me wrong on what I actually ask for. To be clear on the wording first: When I talk about a “maintainer” in this thread I am referring to someone who feels responsible for the overall state of the openhab1-addons repository, i.e. that PRs are reviewed& merged and issues are processed. I am NOT talking about “binding” maintainers, who take care of a specific subset of the code.

In the past, I agreed with @teichsta to do the split that he cares for the openhab1-addons repo, while I deal with ESH, openhab2-addons, openhab-distro, openhab-docker, openhab-deps-repo, openhab-pebble, etc.
Unfortunately, @teichsta seems to have silently phased himself out here and thus we are left with a void in terms that nobody really “cares” about the repo and keeps it healthy. That’s the main reason why I actually opened this topic here in the first place: I’d like to have people step in and take a lead here (and imho it does not have to be a single person).

Let me explain what I understand under “caring” and “taking a lead”:

  • Suggest something (within the group of @maintainer) (e.g. rigorously closing issues) and if nobody vetoes, simply DO IT.
  • If a binding seems to be abandoned, try asking around in the community if there is any other user of it willing to take over the code maintenance for it.
  • Make sure that PRs are processed as we had discussed here. Currently, I still see PRs like this one, where the last comment from @teichsta is from July 2015 “no, i am ‘just a bit’ busy currently” - despite the fact that the contributor still seems to be very active in the community (while many others in the same situation have already abandoned the project).
  • make sure that open issues are assigned to the right people (binding maintainers) so that they are at all aware of them.
  • every other action that makes the repo moving forward

All members of https://github.com/orgs/openhab/teams/openhab-1-add-ons-maintainers have full write access to the repo and thus the full trust in whatever they do. So don’t wait for anybody (especially not me) - live the meritocracy :slight_smile:

1 Like

Guys,

it boils all down to the fact that i as the supposed maintainer of the openhab1-addons repo didn’t do his work properly and continuously which i am very sorry about! I promised a lot and didn’t hold too much of the deadlines which i am also very sorry about! My decreased activity in the last year had reasons but they didn’t excuse to let the project hang for so long.

What i should have done ways earlier is to ask for somebody ‘officially’ taking over the lead of the openhab1-addons (aka openhab) repo what i am officially asking for today. I am simply unable to spend more spare time than now wich obviously isn’t enough to keep the constant contribution flow being answered, reviewed and merged.

Don’t get me wrong i still love the project, the architecture, the technology, the vibrant community and the way it is lead by Kai. Furthermore i am working on ESH and openHAB most of my daytime but i simply didn’t manage to spend more time to actively contribute than now.

So if anybody speaks up to actively take over the active maintenance of the openhab i’d love to help “ramping up” the review process for this repo again.

Unfortunately assigning issues (and thus PRs) only work if the given users accept an invitation to the openHAB organisation which is not always the case. Sometimes the notification simply get’s lost and sometimes the overall notification settings seem to allow to cancel such invitation notifications as well.

Cheers,

Thomas E.-E.

1 Like

@teichsta, I and many others very much appreciate all the work you’ve put into openHAB over the years. Thank you and @Kai (and all contributors) for all you have done and will do.

1 Like

@teichsta I will echo what @watou has said, I have been very appreciative of the time you have spent on this project and on reviewing many of my own PR’s. And I think this just exposes how much work this can be for one person and the risk associated with being single sourced on someone. But speaking selfishly, I certainly hope you stick with the community and find time in the future to participate more, it wouldn’t be openHAB without you.

@teichsta I also appreciate all the work you’ve done. You’ve helped me many times. I definitely understand the challenge you’ve had. Much thanks to both you and @Kai.

Wow - you have closed >10% of the open issues in 24h - that is awesome :slight_smile:
If you keep up that rate, I will have to ask some other people to create new issues in 10 days time :smiley:

1 Like

Incredible, you are even exceeding the rate of the first 24 hours - down to 350 issues now.
If there were such a thing, I would nominate you for the Issue Tracker Cleaning Award, @steve1 :smile: - thanks a million!

2 Likes

well, i didn’t intent to fish for compliments, but nevertheless i appreciate your warm words! @steve1 and @hmerk thanks for taking care of the issue list so thoroughly! If somebody deserved the before mentioned cleaning award you both are my men :wink:

1 Like

All,

I have started with some clean-up on the Github teams regarding active maintainers (see here) - there is now mainly a group for each repo that shows who takes care of it. And we have a global “Maintainers” team that will work on the newly introduced projects on organisation level.

Earlier this year I had added many people to the openHAB 1.x addons maintainer group - more or less everyone that volunteered at that time. After a year has passed, I’d like to check with you the status quo: A few people of this list seem to have dropped out more or less, so it is probably time to remove them for this clean-up - if you feel that you are one of them, please speak up :slight_smile:

As a second topic: I feel very lonely on the list of openHAB 2.x maintainers and the flow of PRs is continuously increasing; so everyone that is familiar with the new ESH binding APIs, has a good sense of code quality and would love to help on this repo, please feel invited to join me!

Cheers,
Kai

Hi @Kai, for most people these links will not be visible. Is this intentionally only visible by the members/maintainers for the organisation? Would it even make sense to have these read-only to the public?

I don’t think that the teams can be made public on Github (I didn’t find any such setting), but it should be accessible to everyone that is a member of any of these teams - and the message was mainly for them :slight_smile:

1 Like

Ok, the Github docs state:

Visible teams can be viewed and @mentioned by every organization member, even if they aren’t organization owners or members of those teams.

So everybody that is in the openHAB “Contributors” team should be able to see all other teams. So everyone that would like to be added as a “Contributor” and has at least one merged PR on any openHAB repo, just ping me with your Github id and I will add you!

@Kai : please add me as contributor (Github lg.hc@free.fr)

@Lolodomo You already received an invite long ago, but never accepted it. Just resent it now!

I receiced nothing… Is it à mail ? Something to do on my Gît account ?