Change request for maintainer guidelines

[hmerk]

Dear members of the AC,

I would like to bring the following to your attention to get a decision about a change to the maintainer guidelines.
First of all, I do not want the autonomy of the maintainers to be restricted !

As you all know, we only have a limited number of mainainers in various groups, for the core it is just 3.
We have seen some discussions in the past about core changes, where non core-maintainer members had concerns or gave a veto.
The higlighted concerns unfortunately have not been discussed briefly, instead at least one discussion was ended by telling a non-core-maintainer that he has no veto right, because of not being a member of the core-maintainer group.
In my perspective, this is a no go, as all concerns and vetos should be handled serious. Otherwise one could get the impression, that three maintainers can make decisions completely on their own.
Therefore I would like to add the following to the maintainer guidelines:
Concerns about codechanges or vetos against from other maintainers or affected code-owners must be taken serious and briefly discussed. If there is no common sense, either side should bring this to the AC to find a solution suitable for all.

Thanks!

[rkoshak]

This seems reasonable to me and seems to fit with what the AC is here for. However, what's the overlap between maintainers and the members of the AC? If the same people are on one side of the argument are also on the AC that presents a potential conflict of interest. Should we also have a corresponding policy for the AC to deal with this, perhaps rules for when to recuse ones self or the like?

It doesn't help if the maintainers say "no" and the we appeal to the AC and the same people say "no" again.

[hmerk]

Indeed Rich, there might be a potential conflict of interest, but where els could such a topic be discussed and decided ? I don‘t know, so I hope that our AC members decide wise….

[rkoshak]

Oh, I'm not arguing that the AC can't be where these conflicts come, but maybe we can set up some sort of policy so the AC doesn't have the appearance of bias.

I could see members of the AC who are actively involved with the conflict could be asked to recuse themselves from the AC for that one issue. But that would require a change to how the AC itself works since I think we have no provision for that right now and we require unanimous votes from all members to make a decision.

[hmerk]

Wow, 8 days now and only one member of the AC (Thanks @rkoshak) seems to have an opinion on this.
Guys, this is shamefull.

[ghys]

Sorry for not following up on this, I somehow missed this...

This question is about changes in the core, I'm not a core maintainer so I can't speak for them how their take their decisions, but I have always been implicitly assuming that a difference of opinion between co-maintainers (that is, at least for now, maintaining the same repo) can be "escalated" to the AC to try and defuse the situation.

However due to dependencies between components (i.e. notably openhab-addons depend on openhab-core) it seems reasonable to apply this principle to the maintainer community as a whole. i.e. an add-on maintainer is free to take a dispute about something in openhab-core to the AC.
The occurrences of this happening has to be limited and not become an habit every time a decision is contested or misunderstood (maintainers of a component remain authoritative over their repo).

Obviously, if a member of the AC is also involved in a particular issue, they would be expected to recuse themselves. As @rkoshak pointed out according to https://www.openhab.org/docs/developer/governance.html#architecture-council decisions have to be unanimous. We could also in theory change this to a simple majority, but this could lead to ties if we end up being an even number.
In any case maybe the paragraph linked above have to be clarified to explain the conflict-resolution role of the AC.

[digitaldan]

Guys, this is shamefull.

Like @ghys i simply did not see this, AC messages seem to get buried in my email and not stand out.

Concerns about codechanges or vetos against from other maintainers or affected code-owners must be taken serious and briefly discussed. If there is no common sense, either side should bring this to the AC to find a solution suitable for all.

Do we have a "rubric" or do we need one for ? So a set of principals that are used to justify a veto, rather then just personal preference. In the end , i think less rules and process probably works better for us otherwise this starts smelling like a bureaucracy. I do think if a maintainer and contributor can not resolve their differences, this group can make the final call, although it would be a pity if this starts happening frequently.

[hmerk]

Do we have a "rubric" or do we need one for ? So a set of principals that are used to justify a veto, rather then just personal preference.

I did not find any rules, even governance says they need to be published
https://www.openhab.org/docs/developer/governance.html#responsibilities
So I would say yes, we need one.

[kaikreuzer]

Note that the governance rules that I chose when giving up my BDFL status were based on the very successful rules of the Eclipse Foundation that very strongly ensure the principle of meritocracy. Imho, these rules are very clear, easy to understand and to follow and have served us very well. There should be very good reasons for doing changes to them; I would want to avoid doing experiments with them.

Concerns about codechanges or vetos against from other maintainers or affected code-owners must be taken serious and briefly discussed.

I think concerns and also any comment from other maintainers (and also from any other person) is always considered and discussed, this is simply a matter of how collaboration in open source works and I don't think that there needs to be any additional rules written down for this.
A veto in contrast is a right to stop a decision or change. This is clearly something that should only be allowed to members of the repo's maintainer group. Otherwise, it would break the logic of any decision making over all of our project.
I think any maintainer group deserves the trust to do the right decisions for the codebase that they maintain and remember that their decisions are to be taken unanimously.

Wrt the statement that decisions also influence others: Yes, but this is in general true for any dependency. openhab-core e.g. heavily depends on Equinox, Karaf, slf4j, etc., but I wouldn't dare to ask for a veto right in their project, just because I don't like any of their decisions. I would comment, yes, and try to bring in my arguments, but in the end it's a decision of the resp. maintainers. If I want to have decision rights, I'd have to go the path of meritocracy and try to become a maintainer (with many further obligations that come with it).
And I don't think that openhab-core is anything different to openhab-addons than what OSGi/Equinox is to openhab-core: It provides a clean set of APIs that is rather conservatively controlled, since it is used by hundreds of consumers (here add-ons) that all have diverse requirements and wishes. Backward compatibility, stability and measures against featurism are the major goals here that the team always needs to have in mind.

[hmerk]

A veto in contrast is a right to stop a decision or change. This is clearly something that should only be allowed to members of the repo's maintainer group. Otherwise, it would break the logic of any decision making over all of our project.

Sorry Kai, but I disagree. I don‘t dare maintainers try to make the right decisions, but as they are just humans like we all, wrong decision can be made. It was by intention to just give a veto right to other openHAB maintainers or affected contributors. Giving a veto must have a strong reason behind.

[hmerk]

Note that the governance rules that I chose when giving up my BDFL status were based on the very successful rules of the Eclipse Foundation that very strongly ensure the principle of meritocracy. Imho, these rules are very clear, easy to understand

BTW, were are those rules YOU have chosen published?

[ghys]

It was by intention to just give a veto right to other openHAB maintainers or affected contributors.

I would disagree with this - this would mean that maintainers have only a secretary role and not much more if any decision they make can be reversed. What's the appeal in becoming a maintainer if the only responsibility you have is clicking the big green button no matter how you disagree?

Currently a maintainer's decisions are effectively final, and I'm not contesting that this could indeed become a problem. What I proposed above is to make them "appealable", in that the AC could be act as an "appeal court" of sorts and try to have an external and unbiased look.
They could advise that a decision was indeed a bad call and should be reversed, or confirm the maintainer's POV, in which case the matter would be settled once and for all.

[hmerk]

this would mean that maintainers have only a secretary role and not much more if any decision they make can be reversed.

No, you got me wrong. If there is a veto arising, the case shall be briefly discussed to find a common sense, otherwise it shall be brought up to the AC. It is not about simply reversing decisions made by the maintainers. There must be a strong reason for giving a veto. Perhaps we should not name it a veto at all.

[ghys]

the case shall be briefly discussed to find a common sense

In that case, well, sure, although IMO that should be (and is) already the case. I don't recall any maintainer flexing authority and saying "I don't have to justify myself" when a decision is contested.

Perhaps we should not name it a veto at all.

Yes because it suggests that a decision shouldn't cause any inconvenience otherwise it has no chance of passing.
In principle yes it shouldn't, but sometimes it does, and that doesn't make it automatically a wrong decision.

(Side note, it's never easy to accept being said "no", but often it's as difficult to say "no", which is part of a maintainer's duties.)

However if it appears that a decision has been made without having been vindicated or discussed enough, then of course we should provide a process to appeal it.

[rkoshak]

This issue has kind of split into two separate ones.

1. Defining some sort of policy for recusal so there is a documented way to address conflicts of interest.
2. How to address conflicts between maintainers and contributors? Should the AC be a place where a contributor can appeal a decision by a maintainer?

Let's ignore 1 for now since that's probably most properly handled through it's own thread here (which I'll create if deemed necessary).

What's the status here on 2? @ghys, are you still a no vote or still open for discussion. It seems like you are open to the proposal in certain circumstances (i.e. a maintainer doesn't justify why they said "no").

Does anyone else have a comment or concern? Are we ready for a vote? Has this idea simply expired?

[ghys]

What's the status here on 2? @ghys, are you still a no vote or still open for discussion. It seems like you are open to the proposal in certain circumstances (i.e. a maintainer doesn't justify why they said "no").

Definitely not a hard no vote.
My view is that in the event of a conflict it should be:

• Neither "the maintainer is always right", while we can expect most maintainer decisions to be for the common good as they've been entrusted to do that as part of their responsibilities, they remain fallible
• Nor "the 'plaintiff' is always right", as I had concerns about the "veto" terminology, which I interpreted perhaps wrongly as "any decision contested by a contributor even if not part of the project's governance apparatus, will ultimately be blocked or reversed"

I would vote for putting these disputes to the neutral (i.e. non-involved) members of the AC to provide an external view. If the repo in question has other maintainers that are also considered neutral/non-involved they should be able to step in too, I think.

[rkoshak]

That seems reasonable. @hmerk, does that address your initial concerns?

[hmerk]

@rkoshak Not completely, but it is a step forward.
I still have not seen the maintainer rules for the core repo.
But I also think, with the newly started discussion of openess, the according issue in the core repo and your just opened AC case, many things seem to need to be discussed and maybe redefined.

[kaikreuzer]

I still have not seen the maintainer rules for the core repo.

They are here: https://github.com/orgs/openhab/teams/maintainers/discussions/1 - there are no exceptional rules defined that only apply to the core.

[hmerk]

Ok, those are the general rules, but there is no clear statement that, for example, an addons-maintainer cannot „veto“ against a core change….

[kaikreuzer]

This is already specified in the definition of a repo maintainer in https://www.openhab.org/docs/developer/governance.html#responsibilities.