Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add formal governance system #4864

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
7 participants
@DomT4
Copy link
Contributor

commented Sep 9, 2018

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same change?
  • Have you added an explanation of what your changes do and why you'd like us to include them?

This is an attempt to find a compromise, and is built off of the discussion that happened in #4759.

It goes further than #4846 in formalising the powers and responsibilities of the lead maintainer and I'm sure for that reason it will be considerably controversial, but I also don't think there's anything in here that anyone should fear or feel attacked by, and it doesn't go nearly as far as abolishing the lead maintainer position. Indeed, it provides a mechanism for the lead maintainer position to regularly & formally be affirmed as desirable.

This takes a whack at comprehensively documenting the system of governance that has built up over the years, and clears up some of the powers and responsibilities exercised and expected by each tier. I very much hope to resolve this positively, and I welcome both formal all-maintainer & PLC votes on the contents of these documents if it proves necessary or desirable.

As a consequence of filing this PR I am suspending my request in #4846 (review), and hope to withdraw that request sooner rather than later. That request is not something I enjoyed feeling necessary, and frankly this has all become a bit of a 馃挬-show, which I hope we can now resolve a little less dramatically.

@ghost ghost assigned DomT4 Sep 9, 2018

@ghost ghost added the in progress label Sep 9, 2018

@DomT4 DomT4 referenced this pull request Sep 9, 2018

Merged

docs/Maintainer-Guidelines: add lead maintainer guidelines. #4759

5 of 6 tasks complete

@DomT4 DomT4 requested a review from Homebrew/maintainers Sep 9, 2018

@scpeters
Copy link
Member

left a comment

I appreciate that you have responded with a formal proposal, but this document has some big changes that are concerning to me.

Show resolved Hide resolved docs/Governance.md Outdated

The lead maintainer is expected to largely direct the priorities & aims of the
project, and consequently has significant influence over whether a suggested
feature/change gains traction or whether a pull request is merged. It is the

This comment has been minimized.

Copy link
@scpeters

scpeters Sep 9, 2018

Member

This sounds very different and less democratic than the section deleted from the Maintainer-Guidlines: "Decisions are determined by a consensus of the maintainers".

This comment has been minimized.

Copy link
@DomT4

DomT4 Sep 9, 2018

Author Contributor

Hopefully addressed this in #4864 (comment).


The lead maintainer has broad authority over the direction of the project and
acceptability of suggested features or changes, as discussed earlier. This
authority should be respected and overridden rarely. Every reasonable effort

This comment has been minimized.

Copy link
@scpeters

scpeters Sep 9, 2018

Member

This is also quite a reversal from the deleted section in the Maintainer-Guidelines: "Decisions are determined by a consensus of the maintainers. When a consensus is not reached, the lead maintainer has the final say in determining the outcome of any decision (though this power should be used sparingly)."

This comment has been minimized.

Copy link
@DomT4

DomT4 Sep 9, 2018

Author Contributor

Partially addressed in #4864 (comment) as well, hopefully, but this section is more designed to address #4759 (comment) and the concerns people (including myself) had around that.

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Sep 9, 2018

I appreciate that you have responded with a formal proposal, but this document has some big changes that are concerning to me.

Thanks for being the first to review! I'm unsure whether to sit back and let the reviews flood in & then try to handle the inevitable flood, or whether to try and more proactively handle them. For now I'll try replying as rapidly as I can and take a step back if it becomes too real-time to handle, heh.

I think it's perhaps worth me saying that I've written this document from more of a "de facto" viewpoint than a "de jure" one. For example, since I believe Mike used it in his first PR (Apologies if I'm misremembering that!), in Homebrew/homebrew-core#31445 there were seemingly two maintainers in favour of the PR being merged & one against, but Mike's vote instead of equalising things at 2-2 made it more like 3-2 & simultaneously immediately fast-forwarded to the end of overtime 馃張.

Additionally, in Homebrew/homebrew-core#30229 there were two, potentially three, maintainers leaning in favour before Mike's comment but the chances of it being merged after dropped hugely. His concerns/hesitations were justified and in further discussion proven correct, but for better or worse I think if I hadn't mentioned it in Slack and asked for opinions we'd have a libclang formula today. So in reality, even if not in writing, the lead maintainer carries an outsized influence on the final outcome of a pull request.

Some of this is also guided by Mike's public comments in the prior PR, especially this one. That comment runs counter to what we have documented previously, so I think it's better to try and run with things as they are and work with that. To vaguely attempt to avoid overly-punchy blowback, I'll note none of this is beefing with anyone, just an attempt to look at the words/decisions said/taken and work with that reality.

@vitorgalvao

This comment has been minimized.

Copy link
Member

commented Sep 9, 2018

I'm unsure whether to sit back and let the reviews flood in & then try to handle the inevitable flood, or whether to try and more proactively handle them.

The latter. If a maintainer disagrees with the premise of the proposal early on and skips on a review, they might find later iterations more reasonable and decide to engage then.

@vitorgalvao

This comment has been minimized.

Copy link
Member

commented Sep 9, 2018

The system to pick the holder of the position looks like a potential source of stress. Voting on a specific day to keep the role and decide who stays there is essentially a yearly election. It鈥檚 not unreasonable to think the lead maintainer will, even if subconsciously, start to opt for only non-controversial decisions as election day creeps in.

The lead maintainer has tough choices to make, and one of their duties is to make them for the good of the organisation. With the prospect of a nearing election, those decisions might change and not be the best for the project. Yes, ideally that should not happen, but both the lead maintainer and the voters are human; even if the lead maintainer has done a stellar work all year, decisions most recent in memory will carry a greater weight.

From what I understood, one of your concerns with the current system is people not voicing their opinion, as they may feel it鈥檚 futile when there鈥榮 a lead maintainer that disagrees. I feel like this system will lead to the same problem, only replacing the people who experience it.

How would the process of replacing a lead maintainer go today, with the current system? I鈥檓 guessing someone would raise a concern, independently of what day it is, and discuss it within the PLC, including the lead maintainer, to try to solve the problem. If it were decided the problem was the lead maintainer themselves, then you鈥檇 go through the process of picking a new one, and so on. Seems like a fairly organised process that could be triggered on demand, rather than making it a yearly obligation. Now if the rule were 鈥渢his can not happen more than once a year鈥, to prevent abuses to the system by a person that wanted to remove the lead maintainer, that鈥檇 make sense for me.


For context, I鈥檒l say I鈥檓 fine with the system as is, with a lead maintainer and Mike in that position. But even if I don鈥檛 agree with that part of the proposal (haven鈥檛 yet finished reading the whole thing), my comments are made in the sense of trying to make the suggestions in this PR the best they can be for the health of Homebrew.

Maintainers may not close other maintainer's Pull Requests or Issues without
the consent of the maintainer in question. The two exceptions of this rule are:

_Inactivity_: If a Pull Request or Issue is inactive for 28 days, any maintainer

This comment has been minimized.

Copy link
@vitorgalvao

vitorgalvao Sep 9, 2018

Member

Doesn鈥檛 the stale-bot do this already?

This comment has been minimized.

Copy link
@DomT4

DomT4 Sep 9, 2018

Author Contributor

No, not in some cases. In brew for example there's a bot that automatically tags brew PRs with the in progress label, which stops stale-bot doing its thing.

tweak to `homebrew/brew` or a simple version bump to `homebrew/core` any
maintainer is welcome to merge that in without waiting for the original
maintainer to do so. If maintainers object to this they should add the
`do not merge` label to the PR/Issue. That label may be ignored if the issue

This comment has been minimized.

Copy link
@vitorgalvao

vitorgalvao Sep 9, 2018

Member

If the PR is 鈥渁n urgent security fix or critical to the continued function of Homebrew's CI鈥, than it鈥檚 probably a bad idea to ignore do not merge. If the label is there, presumably the PR is not yet up to snuff and may break something else.

This comment has been minimized.

Copy link
@DomT4

DomT4 Sep 9, 2018

Author Contributor

My train of thought was something along the lines of:

  1. Dave files a PR containing a critical security update for, say, openssl.
  2. Dave tags this do not merge because they'd like to merge it in themselves, perhaps because they like to have all their merged commits GPG signed with their own key.
  3. The CI build takes 5 hours to complete, in which time Dave has given up glaring at the build log & vanished offline. They don't return within an hour or so of the CI build finishing, and Sally decides to merge Dave's PR based on the CI result looking okay & the scale of changes being relatively minor.

I think Sally's actions would be justifiable there.

wish to, and so they're aware of the revert without having to go fishing in the
commit log.

### Maintainer Conduct

This comment has been minimized.

Copy link
@vitorgalvao

vitorgalvao Sep 9, 2018

Member

This whole section uses & instead of and. Is that intentional?

This comment has been minimized.

Copy link
@DomT4

DomT4 Sep 9, 2018

Author Contributor

Not a conscious choice. I can change it it people prefer and throughout; I just tend to lean on & to condense things a little.

This comment has been minimized.

Copy link
@sjackman

sjackman Sep 9, 2018

Member

I prefer and

This comment has been minimized.

Copy link
@DomT4

DomT4 Sep 9, 2018

Author Contributor

Will change 馃憤.

affirm or withhold its consent for the lead maintainer role to exist in its
current form as a distinct entity. The lead maintainer may vote on this issue.
In the event of a tie regular maintainers are asked to vote on the issue and
collectively act as the sole tie-breaking vote.

This comment has been minimized.

Copy link
@fxcoudert

fxcoudert Sep 9, 2018

Member

I'm not sure voting once a year on this specific item is of particular interest. Maybe a more open question is: how does the governance system described here evolve over time? This includes the lead maintainer position, but it's not restricted to that, there are more aspects that could change over time, as is seen necessary.

This comment has been minimized.

Copy link
@DomT4

DomT4 Sep 9, 2018

Author Contributor

there are more aspects that could change over time, as is seen necessary.

I note near the top this document can be modified by any simple-majority PLC vote, which allows for it to be a kind of living document rather than something that always has to be the way that it is now. It would be a case of someone simply suggesting something to the PLC, the PLC voting on it & making any necessary changes according to that vote.

I'm not sure if that answers your question or whether I'm misunderstanding slightly?

@DomT4

This comment has been minimized.

Copy link
Contributor Author

commented Sep 9, 2018

Voting on a specific day to keep the role and decide who stays there is essentially a yearly election.

Aye, the intention there is that the role be reaffirmed once a year. I went for a specific day as a way of A) establishing that the system frowns upon people forcing votes on the role 3/4/5/6/7/8 times a year, but also B) minimises the ability of anyone (including the lead maintainer) to pick a time/date that suits them.

If Bob thinks or knows that "Lead Maintainer A" is going to have to push through something deeply controversial in July for example, and Bob thinks its time for a change of leadership, Bob could wait till the height of the controversy & then move a leadership challenge.

With elections one side always has some built-in immediate advantage, and it largely comes down to trying to minimise that or make that built-in advantage more transparent, and at least by setting a date I think it lets people be aware that if the lead maintainer suddenly starts sending everyone chocolate in the weeks leading up to the vote there's an obvious enough reason for it, whereas in the moment people may not consider Bob's thought process as much.

How would the process of replacing a lead maintainer go today, with the current system? I鈥檓 guessing someone would raise a concern, independently of what day it is, and discuss it within the PLC, including the lead maintainer, to try to solve the problem.

Yes, a PLC member can trigger a vote. I can't get into specifics, but the current system doesn't work as well as it should or could in terms of either generating discussion or achieving any kind of outcome.

It's also quite a personal thing. You essentially have to trigger a vote of no confidence, and because this is an extraordinary event rather than a scheduled event I think there's an opening for it to be taken rather personally. I think by making it a perfectly ordinary event you make discussion easier, without it becoming such a mess, at least... I hope that makes discussion easier, because it's hard to imagine it making discussion harder. That's about as much as I can say, at this point.

Now if the rule were 鈥渢his can not happen more than once a year鈥, to prevent abuses to the system by a person that wanted to remove the lead maintainer, that鈥檇 make sense for me.

I thought about this, and I don't have an objection to this, but at the same time I also think it wise to have some kind of safety net.

If the election isn't till September and in January the lead maintainer pushes through a system where we start charging people per bottle download despite the team being considerably against this and it inevitably impacting project users in a significantly negative way, and the lead maintainer does not accept an override vote, there has to be some method of enforcement.

The above scenario is a completely made up one, for clarity. The intention there is to provide a last resort to the team that isn't either A) resigning in protest, B) sitting on their hands unhappily for 8 months until they can take remedial steps. It is intended to be an absolute last resort, and heavily frowned upon if people invoke it outside of the regular timetable, but the aim is to provide that safety net in the event one day Homebrew gets McAfee'd.

my comments are made in the sense of trying to make the suggestions in this PR the best they can be for the health of Homebrew.

I appreciate your review! Thanks for taking the time 馃檱.

DomT4 added some commits Sep 9, 2018

@jonchang
Copy link
Member

left a comment

I don't see why some of the content was moved from Maintainer Guidelines to Governance. In my mind, "governance" are basically the bylaws of the Homebrew organization, like any other nonprofit or community organization. The lead maintainer is the president/chair, the PLC is the board comprised of members-at-large, and the regular maintainers are the membership body. You may want to consider writing the Governance document more in that style, but I'm agnostic about it.

Specifically, Governance should include:

The composition and duties of lead maintainer, PLC, and regular maintainers, and how those positions are obtained and how people may be removed from those positions. Currently, there is no provision for:

  • How PLC members and regular maintainers may be removed.
  • Who is eligible to serve on the PLC or as lead maintainer.
  • What constitutes a quorum of PLC members for the purposes of executing their duties and electing new PLC members (simple majority = majority of those voting, or majority of the committee?)
  • Who may raise issues before the PLC in case of personal or technical disagreements and what the process is for doing such a thing
  • How does the membership fill emergency vacancies in the lead maintainer or PLC roles.
  • Any confidentiality issues that maintainers, PLC, or lead maintainers are bound by
  • Terms of service for lead maintainers and PLC members. It appears that the lead maintainer has a 1 year term with no term limits, but this is not formalized nor is it specified for PLC members.

I'm trying to mentally compare this to nonprofit bylaws that I'm familiar with and these are just off the top of my head. I'm kind of sick so I'm sure I'll think of other holes later.

With respect to the concerns about yearly elections: I think it's fine, most nonprofit boards do that regularly for officer positions so it's not super surprising for me.

@fxcoudert

This comment has been minimized.

Copy link
Member

commented Sep 10, 2018

A few points I'd like to add to this discussion, from the point of view of someone who has been contributing to volunteer organisations and charities (and sometimes running/managing them) for 20 years now. In my opinion:

  • Having an experienced "person in charge", with final say in lack of consensus on big issues or long-term projects is important.
  • Barring that, there needs to be a strong PLC or steering committee, which intervenes in both governance and strategic discussions. These discussions may be public or private, but there needs to be an active governing body, with active discussion of key points. I am not sure how active the PLC currently is (and do not know who its members are), but clearly I do not feel it has guided this debate.
  • All of us are merely, day after day, dealing with Homebrew's issues as best we can, some in a limited area and some in a more comprehensive front. Some of the hypotheticals that have been thrown around are not very interesting, and I believe we should focus on helping things go better in our everyday interactions. Building strawmen is not worth the time, and if someone really wanted to screw the project, they probably could do it whatever guidelines we can write!
  • I am a saddened by the fact that the situation has turned relatively personal (or, maybe not "personal", but accusatory) in a relatively short time. Some of the behaviour displayed has not been professional, and the atmosphere is made heavier by it.
  • Pull requests like this one, where people comment mostly on small items, may lead the discussion to miss the broader picture.

My preferred suggestion to move forward would be to focus on making the PLC a more efficient place for debate and strategic discussion (unless it already is, but the rest of the community has no idea about it). I believe this is the most important part of this discussion, to cool down and simply find a way that we can work forward.

Finally, I'll say that in my philosophy, the role of a leader is not primarily to make rules or decisions, but to deal with all the crappy stuff that is preventing the rest of the team to work efficiently (whether it be politics, finances, communication, ops, or whatever). I also believe the current holder of the position has been doing that quite efficiently 鈥 and thanklessly.

@vitorgalvao

This comment has been minimized.

Copy link
Member

commented Sep 10, 2018

I also believe the current holder of the position has been doing that quite efficiently 鈥 and thanklessly.

I wanted to touch on that point in my previous comment but forgot. Adding yet another possible source of stress to the lead maintainer is something I鈥檇 rather avoid. Whoever holds the position, I want them to enjoy working on Homebrew on some level, not add so many worries they eventually burn out and think 鈥渨hy am I even bothering?鈥. If it鈥檚 the lead maintainer鈥檚 job to ensure things run smoothly for the other maintainers, to some extent it鈥檚 said maintainers鈥 job to make it easy being managed. In the end, we鈥檙e all giving the same to the project 鈥 our time 鈥 and doing it for no pay, so having the most responsibility and putting in the most work translates to more trouble but not more reward.

@sjackman

This comment has been minimized.

Copy link
Member

commented Sep 10, 2018

I'm in favour of having a lead maintainer position. I feel the current lead maintainer has been doing a good job.

I like both @jonchang and @fxcoudert comparison of Homebrew's governance to the governance of a not-for-profit; I serve on the board of a not-for-profit theatre company. The Project Leadership Committee (PLC) is effectively the board of Homebrew. I think of the of Lead Maintainer as the Artistic Director of an arts organization, or in more general terms, the executive director of the organization, which is a separate role with different duties than the president of the board.

Debian's governance model and roles of Debian-Project-Leader (DPL) and the technical committee may be a good model.
https://www.debian.org/devel/leader
https://www.debian.org/devel/tech-ctte

@sjackman

This comment has been minimized.

Copy link
Member

commented Sep 10, 2018

The governance model described by the bylaws of the organization ought to be a concise document. Further elaboration describing the roles can be in a separate document. For example鈥

The membership (maintainers) elects the board (PLC) at the annual general meeting (AGM).
The board appoints the executive director (lead maintainer) by resolution.
New members are admitted by the board, or possibly a membership committee.
New members of the board are typically nominated by the current board, but ultimately the membership elects the board.
The bylaws define how votes are conducted, including requirements for quorum.

Determining who comprise the membership, the board, and the executive of Homebrew are a separate topic from the technical topic of how the code base evolves. It may help the discussion to separate the two topics.

@mistydemeo

This comment has been minimized.

Copy link
Member

commented Sep 11, 2018

The governance model described by the bylaws of the organization ought to be a concise document. Further elaboration describing the roles can be in a separate document.

I think this is a good call; the overarching structure of an organization and the day-to-day processes are very different concerns, and it's worth having those in different places.

My preferred suggestion to move forward would be to focus on making the PLC a more efficient place for debate and strategic discussion

Also agreed - I think this is important, and your point that "the rest of the community has no idea about it" is also important. Accountability from the PLC is just as important as accountability from the lead maintainer.

The Debian documents @sjackman linked do a good job of outlining their appointment model, and it sounds like one that could work us given some time to transition into it. A few takeaways for me from the Debian documents specifically:

  • Debian doesn't just outline the election process, it also outlines the timeline. It sounds like they've put a good amount of thought into helping the process avoid entering a "constant election" mode, where the leader has to spend more time worrying about reelection than doing day-to-day work. Given the substantially smaller size of Homebrew as a project, Debian's campaigning process would be overkill for us, but it's useful to learn from.
  • Debian's Technical Committee's decisions are outlined on the page that also defines their membership. It looks like this helps them remain accountable - if their major votes are published in this way, it becomes clear what they do.
  • I love point six on the technical committee's "how to refer a question" list.
@scpeters

This comment has been minimized.

Copy link
Member

commented Sep 12, 2018

I appreciate that you have responded with a formal proposal, but this document has some big changes that are concerning to me.

I think it's perhaps worth me saying that I've written this document from more of a "de facto" viewpoint than a "de jure" one.

Yeah, it was a bit confusing to read this document, which seems in conflict with one of your other comments, but "de facto" vs. "de jure" helps explain the difference.

There is some value in "de facto" assessment of where we are and where we have been and being honest about it, but I would hope that a governance model could include more "de jure", or how we would like the project to be run.

@scpeters

This comment has been minimized.

Copy link
Member

commented Sep 12, 2018

@fxcoudert wrote:

  • Having an experienced "person in charge", with final say in lack of consensus on big issues or long-term projects is important.
  • Barring that, there needs to be a strong PLC or steering committee, which intervenes in both governance and strategic discussions. These discussions may be public or private, but there needs to be an active governing body, with active discussion of key points. I am not sure how active the PLC currently is (and do not know who its members are), but clearly I do not feel it has guided this debate.

I agree with both of these points. I made some comments above where I perceived a devaluing of maintainer consensus from the changes in this PR, but we can't always reach consensus, and a leader who listens and helps guide a path forward is immensely valuable.

@DomT4 DomT4 closed this Sep 12, 2018

@ghost ghost removed the in progress label Sep 12, 2018

@DomT4 DomT4 deleted the DomT4:governance branch Sep 12, 2018

@Homebrew Homebrew locked and limited conversation to collaborators Sep 12, 2018

@Homebrew Homebrew unlocked this conversation Sep 12, 2018

@lock lock bot added the outdated label Oct 12, 2018

@lock lock bot locked as resolved and limited conversation to collaborators Oct 12, 2018

@Homebrew Homebrew unlocked this conversation Feb 15, 2019

@Homebrew Homebrew deleted a comment from DomT4 Feb 15, 2019

@Homebrew Homebrew locked as resolved and limited conversation to collaborators Feb 15, 2019

@Homebrew Homebrew unlocked this conversation May 6, 2019

@Homebrew Homebrew locked and limited conversation to collaborators May 6, 2019

@fxcoudert

This comment has been minimized.

Copy link
Member

commented May 6, 2019

Posting this here on behalf of @MikeMcQuaid, for reasons explained below


Hi 馃憢 ! Mike McQuaid, current, elected, Homebrew Project Leader.

DomT4's last comment on this thread was:

You are welcome to use this PR as a basis for future discussion, but the issue has been forced and my resignation has been mandated by Mike, which will be delivered immediately.

I had edited this, with consultation with other Homebrew maintainers, to:

You are welcome to use this PR as a basis for future discussion and my resignation will be delivered immediately.

This was not the right decision for me to make. I had attempted to revert the edit but by that point I had been blocked by DomT4 which prevented me from editing his post or posting on this thread. As a result, I deleted the comment as I felt that was more fair to DomT4 than maintaining an inaccurate comment.

This was also not the right decision to make. I am unable to undo either of the above actions or post on this thread (hence this being posted by another user) due to GitHub鈥檚 moderation system.

I would like to publicly apologise to DomT4 and the Homebrew community for my mistakes in this thread and I will do better in future.

On DomT4's resignation specifically, he said he was already leaving the project, changed his mind and, after consultation and agreement from other maintainers, I removed him from the project. Several maintainers had said they would leave the Homebrew project if he did not. There was other, personal factors that were involved in this decision which I鈥檓 unwilling to disclose as it would violate the privacy of the individuals involved. Regardless, DomT4 did feel he was forced out of the project and his comments to that effect should have remained here.

Since this pull request was closed, I announced a date and stood down as Lead Maintainer and the Homebrew maintainers met in person and came up with a public governance document. This resulted in me being elected unanimously-bar-one as Project Leader, PLC and TSC members being elected. I am the current, 2019-2020 Project Leader, on the PLC and TSC but this time next year I will be able to be in a maximum of two roles and will have had to stand for election again.

In summary, this PR was part of a conversation that resulted in meaningful changes to my role and Homebrew鈥檚 current and future governance. Unfortunately, the way the conversation was handled was not ideal and mistakes were made but I and Homebrew will (as we always try to do) learn, iterate and improve in future.

Thanks for using Homebrew!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can鈥檛 perform that action at this time.