@maintainer I’m starting a new thread specific to issue management since the “Growing the number of active maintainers” topic is getting quite long.
I have a few questions.
Where can I get the information about developers who maintain each binding, action, etc.?
For features, @kai has suggested not managing those in the issue database unless it is being actively developed (which implies it has been assigned to someone). Until that point they would be discussed in the forum instead of tracked as an “issue”. I’m wondering if that might make it harder for people who want to contribute since it may be harder to identify requested features. Comments?
I’m assuming openHAB 2 issues should be tracked in the openhab2-addons repository (and the esh bug tracker). Is that correct? I’ve seen OH2-related labels in the openhab issue database.
Personally, I’d say that’s a step too far as we’d loose some visibility and it would be hard to track. My personal view would be to add them as an issue after discussing them on the forum first - this way there is some visibility of the issues/enhancements. Maybe we add a statement to the ‘new issue form’ that in order to create an enhancement request, there must be a link to the discussion on the forum. Anything that doesn’t have prior “agreement” on the forum gets closed with a ‘discuss it on the forum first’ statement?
I think this was to track changes that had been made to OH1 code that needed to be ported to OH2 - at least that’s how I have used this tag.
For OH2 issues, they should be in the OH2 tracker.
That makes sense to me. Didn’t one of the other openhab-related repositories have a GitHub ISSUE_TEMPLATE? If so, we could modify that for openhab or otherwise create a new one.
Note that this was my recommendation for the openhab1 issue tracker in order to get the number of issues down (as for many there was a low chance to have them ever implemented). Hence I still think that “feature requests” without anybody committed to working on it should NOT be entered in the openhab1 tracker.
I think the discussion here should concentrate on openhab1 for the moment as there is no real problem on any of the other repos. And for different repos, different strategies can make sense (and it is up to the respective group of maintainers to decide on it).
Chris is right, I used this for all stuff that was related to making some 1.x add-on work on OH2 (like e.g. this one).
Yes, I was asking specifically for feature requests in the openhab1 context. Many of the feature requests might also apply to openhab2 bindings that are inherited from openhab1, right?
I didn’t really come across those yet, but you are right that this can become more and more in future. But usually bindings that already exist in OH2 are no longer supported in OH1, so a feature request will most of the time only in one of the repos.
To be sure I understand, what is the policy for openhab1 addon feature request and bug issues for addons that have a counterpart in the openhab2-addons repository?
I’ll watch for issues that might still apply to the openhab2 addon implementation but in general it will be difficult for me to know without investing significant time in it. Even then, it would be easy for me to miss something.
One possibility is that the openhab2 addon developers could review the openhab1 open issues for their addon and transition those issues to openhab2-addons if they apply.
Well, my suggestion is to not accept any “out of the blue” feature requests for openhab1. If a feature has been discussed in the forum and a developer says that he wants to implement it (whether or not an OH2 version already exists, that does not matter), a feature request can be entered. When rejecting requests in this repo, I would simply add a comment to the requestor that he is free to check whether his idea is applicable on openhab2-addons as well and to enter it there.
In general, issue templates can be a good idea for any repo indeed - if this allows to add according labels automatically, it would help on sorting and filtering a lot.
Where can I get the information about developers who maintain each binding, action, etc.?
On openhab2, I have copied the process that was defined by the Docker project - the folders should have a MAINTAINERS file like this one.
The organisation is documented within the repo. This is also based on what Docker has in place. I think we should have the same kind of process and documentation for the openhab1 repo as well.
I like the MAINTAINERS file approach very much. We really need this to manage openhab1 issues but we also need everyone to pitch in to identify known maintainers (or to identify orphaned bindings). I’ve tried using github history in a few cases but this isn’t ideal. First the original committer may not be maintaining the code any more and in some cases there have been several committers so it’s difficult to know if any of them are considered the binding “maintainer”.
What’s the best way to make progress on this need? Someone could provide me a file with known maintainers for specific bindings and I or others could create MAINTAINERS files for openhab1. We could also start a topic here and review each binding to identify the maintainer, if any, and then add the MAINTAINERS file.
Also, I wouldn’t want my email address exposed in the MAINTAINERS file. I wouldn’t mind my github user ID being there though. Does anyone else have concerns about spam with the email addresses open to crawlers?
About the MAINTAINER file should it not also have a specific field for github-username ?
OpenHAB is so integrated to github and it’s nice to “@” people in relevant issues.
And about maintainers I do not have a list but I know @jarlebh is the main contributor for the Tellstick binding. Personally can I also maintain the tellstick binding to some extent, kind of have know how, how the code works due some bug fixing.
Also Great work (!) with issue smashing @steve1 . I think this is really important for the reputation of the project to don’t have a flooded backlog.
I am ok with putting github id instead of e-mail in there. It will anyhow make it easier to assign issues etc. to the right person.
Does anyone else have concerns about spam with the email addresses open to crawlers?
I had concerns in the beginning, but since on Eclipse it is required to sign-off every commit with an e-mail address and I am doing it this way since more than 2 years now, I got used to it. And luckily, I didn’t notice any kind of spam increase through this. Looks as if spammers aren’t too interested in developers
Thanks. I’m keeping a list and when I have more maintainer information I’ll submit a PR with several MAINTAINERS files. Does anyone have a preference for the format of the github user ids in the MAINTAINERS file? I’m thinking something simple like “github lolodomo” or “lolodomo (lolodomo) · GitHub”. Suggestions are welcome.
@maintainer If anybody knows of maintainers for other addons, you can post it here or send it to me in a PM. Thanks.
I usually dig through a particular addon’s commit history to locate recurring github IDs, and make a judgement call as to whether that person seems to have an ongoing history of having their PRs merged. Not terribly scientific!
Agreed. I do that too sometimes but it would be very time consuming to do that for 140+ addons. However, if several of us did that for a subset of the plugins it wouldn’t be so bad.
what i did so far was scanning through the (open and especially closed) PRs. If somebody had been active in the past he might be willing to be active again.
However, if several of us did that for a subset of the plugins it wouldn’t be so bad.