Time Limit for AC Issues

[rkoshak]

Looking back we seem to have a number of discussions/issues that are just hanging out without resolution. That doesn't feel right to me. We should either decide yes, no, or decide we cannot reach a consensus (which I guess is no by default) and close the discussion/issue at some point. Otherwise we end up with all these unresolved issues hanging around which promotes uncertainty and doubt.

I'd propose a generous 90 days, extendable on a case by case basis where it makes sense. If no resolution or vote occurs by that point we consider the issue closed. It could be reopened or a new one created if needed after that.

[hmerk]

Thanks @rkoshak for bringing this up. I was going to leave another comment on my discussion/issue, asking when this will come to a decision. Leaving it open for such a long time is not good.
According to your suggestion about decisions, I am not feeling comfortable with a "no" by default.

[rkoshak]

Well, since we need an unanimous "yes" vote to approve an issue I'm not sure what else we could default to. I don't know that there is anything in the rules that prevents the same issue from being raised again so defaulting to "no" doesn't mean no forever. The only other resolution I could see is "unresolved" but that's basically the same as leaving the issue open forever.

[kaikreuzer]

Makes sense to me, @rkoshak. Just noting that there is no technical way in Github to "close" any discussion, so they will stay open and it cannot be prevented that further comments are still made afterwards.

[rkoshak]

I was looking into that but if we document this as the actual policy that is probably sufficient. I'll even volunteer to add a comment to the old threads where a vote didn't happen indicating they are considered closed.

There isn't a lot of traffic and posting here so the lack of tools on GitHub's part shouldn't be too much of a problem.

We should probably have an official vote here to add to the policy this is how it will work (assuming no one objects).

[ghys]

I am definitely in favor of making "official" decisions from discussions in this AC group.
However I'm sharing my concerns already tackled in the earlier discussion:

I am not feeling comfortable with a "no" by default.

Well, since we need an unanimous "yes" vote to approve an issue I'm not sure what else we could default to. I don't know that there is anything in the rules that prevents the same issue from being raised again so defaulting to "no" doesn't mean no forever.

In my interpretation of the current rules: https://www.openhab.org/docs/developer/governance.html#responsibilities-2 an AC member that doesn't respond within a week is in my view effectively a recusal.

When the matter is about resolving disputes, I think any "default" barring a (unanimous) consensus decision would be "the AC abstains" which would mean "this issue has no immediate resolution". I know it seems like a "cop out" decision but in effect IMO that means "status quo for now" - this is not a definite "no and the matter is settled" but a signal that the issue should be discussed further among stakeholders (perhaps with the support of the AC) until a consensus decision is made, or a further decision is required.

[rkoshak]

I know it seems like a "cop out" decision but in effect IMO that means "status quo for now"

Perhaps my understanding is wrong, but isn't a "no" a vote to keep the status quo? We have three types of issues that arise as I see it:

ID	Category	Example
1	Major change to OH architecture or big breaking changes	Removal of the OH 1.x compatibility layer
2	Changes to the AC policies and rules themselves	This thread
3	Disputes between maintainers of one of the repos	I don't think we've actually seen one of these yet

In 1 and 2 it's pretty clear that a "no" vote is the same as "status quo".

For 3, I guess I always assumed that a "no" vote would be the same as the AC saying "we're not going to that the case" which to me would also be "status quo" of letting the maintainers sort it out among themselves. But I can see how that get's murky because this case really isn't a yes/no decision. There is a yes/no decision to determine whether the AC takes the case and then there is a decision among the presented options which one to go forward with.

I've always treated any no vote to mean "for now". Things change, people change, and I don't think we can put away any issue forever so I always assumed any no vote was potentially temporary by definition.

I think we are all probably in agreement here and it's just a matter of wording and semantics to get it stated right.

I've no problem with stating in the policy change that if an issue times out without a vote that it means that the the "AC didn't take up the issue at this time". It could be raised again in the future but for now it's status quo. That's what I originally meant by "no" anyway.

[rkoshak]

@ghys, does my previous reply address your concerns or would you still be a no vote? I've only seen thumbs up from you and Kai but your response makes it unclear if your thumbs up was a vote. I'd like to try to bring this to a close if I can. It's a really bad look if the issue to clarify how to treat issues that don't get a vote itself doesn't get a vote. ;-)

[ghys]

Sorry I failed to reply to your last message, I agree fully with it. So my thumbs up in the OP means a "yes" vote from me.

[rkoshak]

Awesome! In that case, unless someone speaks up with a no vote, I'll add this to the little bit to the policy so it's clear how to interpret these old but not voted upon issues.

Thanks!