docs/Maintainer-Guidelines: add lead maintainer guidelines. #4759
Conversation
ghost
assigned 
|
Perhaps there should be something in there about fundraising or where does that fit in ? |
The difference being that in the former case the majority of the maintainers have the ultimate say. In the latter case the lead has the ultimate say in every decision, and their decision is (strongly) informed by the maintainers. |
@javian Yeh, I think building partnerships and getting sponsorships should be part of the role 👍 @sjackman Good questions; I'm not quite sure. They way I see it in theory at least the lead could overrule literally all the other maintainers. Obviously that wouldn't be practical or sensible, though, so isn't something I'd plan on doing. I don't think any sort of formal vote or consensus works for technical/product/design changes because the consequences aren't shared equally amongst the maintainers. Thoughts? |
|
This should do nothing positive for my popularity, but on the record as (I believe) the only maintainer in this thread thus far who was present when the lead maintainer system was formalised, I think over time it has proven to be a mistake and I have regrets around lending it my indifference/tepid support back when it was being discussed initially. It's not like before the system was introduced anyone was in any doubt about who was essentially the "face" of the project or who should be consulted on changes to the I think formalising the role has made it feel at times like it is pointless trying to push back against the lead maintainer, and it has also undermined a contribution-based "power structure" because it lets people pull the lead maintainer into conversations as a weapon against ideas they support/do not support and suspect or know the lead maintainer feels the same way, even where that idea is driven by a maintainer with more experience or knowledge of a subject than those who object. I tend to keep my mouth shut about lead maintainer stuff because I view it as being a sailed ship, and there's little point trying to convince a ship to return to harbour months or years after the fact, but since feedback was requested, this is me. I know through experience & conversation the formalisation of the lead maintainer role has played a not insignificant part in maintainers becoming mentally/emotionally exhausted and stepping away from the project, or thinking about stepping away from the project, and whilst it wasn't the primary reason I certainly don't exclude myself from that when I left for a chunky period of time in late 2016. It remains the case that on subjects where we disagree I question the value of me investing time into discussing those disagreements. I also note here in closing that I think the issues with the system would persist whoever occupied the role; I'm not attempting to poop in your dog basket here, you know the level of respect I have for you and the level of gratitude I have for the time you've invested in me, but nonetheless I think the formalisation of this "lead maintainer" role has been problematic and I regret my part in it becoming a thing. Since we're stuck with it though, this PR in itself is fine. |
|
I have to agree with @DomT4's sentiment here. Especially this doesn't seem right:
This should not be possible even in theory. |
To be clear: I opened this PR to solicit opinions on this so it's not going to make anyone more or less popular because they criticise my current or past decisions. I'm a big boy and I can handle criticism without taking it personally or disliking the person who expresses it.
I don't agree, actually; it's the difference between explicit and implicit hierarchy. Some random but related history: when @mxcl left the Homebrew project he told me that I was in charge now. In response, I told him that it would be a bad idea and I was going to make sure it was run as a democracy. Similarly, when I joined GitHub around a similar time it was a "no management culture" where there were hundreds of employees but only the e.g. CEO/CTO above them. Both approaches were abandoned because they didn't work; it wasn't clear to either newcomers or people external to a project who had the responsibility or ability to make final decisions so decisions often weren't made at all. With a flat structure or democracy in an open source project you end up with a situation where the loudest (or, sadly, most willing to be nasty) voices "win" and I don't think that's more healthy than having someone in a formal position of leadership. We're not a corporation, for sure, but we should aspire to be creating great software with a degree of professionalism and that requires leadership. Hell, we're all using Apple products here: do any of us think a completely democratic, non-hierarchical approach would have produced the Apple products we like using?
I'm going to assume this isn't about me specifically but I'd like you or others to dig in more specifically on what is stopping maintainers from expressing disagreement with each other or with me. You don't have to spend long looking on PRs in here before you'll find my disagreements with people where they successfully convince me to change my mind and I do.
This applied and applies even without the lead maintainer position but what ended up happening was a bunch of issues and PRs descending into "well, we can't see to agree on a decision so we'll do nothing" which seem worse to me than making a decision, even if it's not the preferred one for everyone.
Again, to be explicit, it was supported by a majority of maintainers when it happened. I would not like to be lead maintainer of the project forever. Much as I've enjoyed automating myself out of the job in the past I would like to pass on the baton one day to someone else who shows leadership and ownership not just for the Homebrew/brew codebase or Homebrew/homebrew-core formulae but the entire Homebrew organisation, community and ecosystem. If that's a group of people or someone who decides to product some flattened structure and convinces me that they can do as good or a better job: great, I'll happily hand it over. |
@sjackman Agreed, I've pushed an edit accordingly.
It has to be possible in theory; whatever you cement as being impossible in theory slims the window of what's acceptably possible in practice. This is the same as in an organisation the lead of a team has the authority to overrule the entire team; this would be a failure in leadership and something to be regretted but if it's made impossible the lead of the team does not actually have any concrete authority. I feel the same way; it's not something I'm aware of ever doing or would ever plan on doing and it would be a failure if I did so. |
|
As a new/first time maintainer, I don’t understand the mechanics/process of how one becomes the lead maintainer. The thought of ANY generic lead maintainer having ultimate power does trouble me. I also agree with @DomT4 that there will be a potential chilling effect if it seems like decisions can be unilaterally overruled (especially if done so in a seemingly arbitrary or capricious manner) by a lead maintainer. Whether or not it is a bad idea, the right person in the right environment can quickly discard norms and the usual sense of decorum, unless there is some codification of the limits of their power as well. I do agree with Mike, that, at the same time, we do need someone with some central and meaningful authority to make decisions, and have additional ownership and leadership. I’m not sure what the best balance of power between one central, and hopefully wise/experienced executive authority and a larger governing body is, but it probably lies somewhere between unilateral ultimate authority and a simple majority. The codification and implementation of rules and bylaws is good to do before you need them whenever possible. When a conflict arises, if the extent and also the bounds of an executive's authority are not codified and well defined, it could result in inaction/stalemate if insufficient authority is invested in them or, conversely, if excessive and/or poorly defined powers are granted them, they could throw decorum to the wind and act to consolidate additional powers or abuse the limits of their power because those were poorly defined. I am not concerned (at least overtly, but then again I'm new here 😜) with Mike's potential for abusing his executive powers, but who knows what the next lead maintainer's personality/motives will be. Having well codified by-laws or governing procedures with the right balance of power (maybe require a supermajority needed to overrule the lead maintainer?) and the right degree of formalization may be important, if not under Mike's reign, then at least in the future. (Software people have been known to go off the rails from time to time after all. C.F. John McAfee and Hans Reiser for example) TL;DR: My preference is probably for requiring a substantial supermajority to overrule the lead maintainer, and additional formalism on governance, primarily as a means to mitigate/resolve conflicts in the future in a clear & fair way. But I may be ignorant of existing formalism/by-laws etc. |
I think we're overstating the power dynamics here; as far as I see it the lead maintainer has dramatically less power than a manager in most companies: they can't tell anyone what to work on and when, they can't affect you economically and you always have the power to create a fork were it to come to that. Without wanting to get too meta: are we all equally disturbed that the management and CEOs of the organisations we work for have dramatically more power than a lead maintainer could ever have?
Create Homebrew or be the longest running maintainer who has remained the most actively involved with the project.
I agree here. Perhaps a good starting point would be for me/us to start documenting whenever I make more controversial decisions? For example, Homebrew/homebrew-core#31445 came up recently and could be documented such that we don't delete formula that non-trivial numbers of people are relying on if they aren't a) broken, b) vulnerable or c) causing us grief in some other fashion.
I'd be favour of this in a future where I know if I create a PR it will be reviewed by another maintainer within 48 hours and similarly in Homebrew/homebrew-core we have required PR reviews where maintainers are reviewing each other's work. Until then my concern is we give an equal vote to someone who spends 1 hour a month working on Homebrew to someone who spends 1 hour a day on Homebrew. If folks have a way of resolving this inherent conflict: again, I'm all ears. |
|
Since it hasn't been brought up yet the project has a code of conduct that has been established for a while which is based on being open, respectful and considerate which would of course apply to whomever held the flag. I haven't been around long enough (or involved in the right places) to personally have noticed that the way its working is an issue. |
There was a problem hiding this comment.
As this seems to be a contentious issue - I believe any decisions which lead to (established) precedent, especially where there is not a general consensus, should be clearly documented somewhere. Perhaps you could set this in writing?
I also second @javian - if there is a code of conduct in force, it would be great to bind the guidelines to it.
I thought this was implicit but I can make it explicit to all maintainers.
I'm not sure I understand this. Can you provide an example of what you'd like documented? |
Of course. I (now) know that Cask's policy is not to include all possible languages, only those that are requested on a case-by-case basis. But where/how/why was this decided? It should not be necessary, especially for first time contributors, to dig through old issues to figure out precedent. |
So any decision made by the lead maintainer should be documented after the fact or just decisions that e.g. may come up in future/affect contributors? |
The latter. |
|
I didn't necessarily intend to start a huge debate but since I did I guess I shouldn't vanish into the ether.
I think there's automatically a degree of leadership in active maintainership though, and a system where there is one overarching leader for everything doesn't really make sense. On core stuff for example I'd argue it makes little sense for you to be the final decision maker there, because you're quite divorced from having to maintain core on a daily basis (which is something I think you'd freely admit yourself). Equally I'm not about to tell anyone how to implement Cask changes, and FX (by FX's own admission) isn't about to tell anyone how to configure Jenkins, etc etc. Nobody is "in touch" with absolutely every element of Homebrew on a daily basis because nobody has that much time in life, and consequently I don't think it's logical to have a system where one maintainer has ultimate & untouchable authority over every aspect of Homebrew. I also think it's dangerous on some level, because (for example) major Jenkins/CI operations almost always fall on you, and that has been the case for years now. Nobody else has proactively stepped up to a significant degree there because nobody has needed to, but if you get whacked by a bus tomorrow (please don't, I add) suddenly there's this gaping hole in the project that would be immensely difficult to fill. That's not a healthy position for Homebrew to be in.
FOSS contribution, and maintainership, should be a consistently enjoyable experience though, to the largest extent possible. As much as I admire Steve Jobs, Tim Cook, etc and as much as I'd have willingly subjected myself to being tossed into that lake of fire the Book of Revelation is super fond of mentioning if it meant being able to work with either of them or others like them, I'm not sure it helps our cause to aspire to emulate work environments that are likely extremely stressful.
Correct. My intention in using the title rather than your name was to make it clear the concerns were not personal.
Mostly for me it's the idea of pointless effort. If I talk about an idea with FX, Com, Misty, Jan, etc etc and everyone loves the idea and I pour a small mountain of effort into implementing said idea knowing there's team support behind that idea you retain this ultimate power to flatly reject it, regardless of how many others are in favour. Even the concept of that happening is quite demoralising in some ways. The other way around is a concern as well. You could presumably, by your own admission, implement changes nobody else supported and are in no way obligated to discuss those changes with the team or revert those changes even in the face of overwhelming opposition. Again, not personal, I don't expect such actions from you, but nonetheless that you have the capacity to do so leaves a door open that should probably not be open. Precedent is important and however benevolent you are as you've said you may not always occupy the role and the next person may end up being less so. == I think in terms of actionable items, some of which have already been mentioned, I would like to see the aforementioned door closed and formalise some way for the lead maintainer to be overruled in necessary circumstances. I guess technically it's possible the PLC serves as such a mechanism today but I consider it more sustainable if there's a way for maintainers who don't sit on the PLC to overrule the lead maintainer. I don't think it's a power that should be invoked frequently but I think it should formally exist. I also think it should at least become the norm that maintainers do not close other maintainer's PRs without the consent of that maintainer or other reasonable grounds. If a discussion reaches an absolute deadlock or is running itself around in circles I think that allows the lead maintainer to step in but if a discussion is ongoing I feel like it's an overreach of authority for the lead maintainer to essentially terminate that discussion. |
|
I'm not going to address every point but there's a few things here that I think are important.
I've still maintained core for a long enough time and read enough going on there to have context there. I still have more commits in there than any other active maintainer (although you're close 😉). I don't think that becomes meaningless because I've delegated more of the day-to-day on that tap to others.
I'm not saying anyone should be in touch with all of Homebrew on a daily basis but I am saying if we want to do away with a lead maintainer we need to have people who are going to step up and take responsibility for following the majority of repositories in the Homebrew org and making sure things that the community rely on like Homebrew/homebrew-bundle and Homebrew/formulae.brew.sh keep running.
You're missing my point here; literally almost every single organisation in the entire world and entirety of human history is hierarchical and has a "buck stops here" leader at the top. This includes most democratic institutions!
The PLC is literally the "project leadership committee". There's a clear criteria for joining it (partly because of the amount of work for me personally in adding and removing people constantly) and if there's anything that replaces the lead maintainer position it will be that. To be clear, though, I'm the one who did all the work to get us to join the SFC, I'm the one who arranged with them to setup the PLC, I'm the one who nagged people to submit the necessary paperwork to join it and have documented them taking responsibility for appointing new maintainers rather than it being just up to me.
That's a fair ask. What I'm going to ask you specifically @DomT4 and other maintainers in this thread who don't like the status quo is to submit a PR with a documentation change for discussion. Anyone who is not willing or able to make a concrete proposal of what should change doesn't really have the right to complain about it. I don't think it's reasonable to expect me to put in a bunch of frankly boring and time consuming work to do this when I know what can of worms will be opened by my doing so. Slightly off topic here I'm a bit disappointed by some of the tone and comments here. As I have mentioned before, many of you wouldn't be maintainers at all were it not for me overruling other maintainers which have since left to have you join the project. Multiple of you have benefitted materially or financially in your personal lives from where I've reached out to help you with things. Most of you have at some point asked me to join in and help out in a discussion where you wanted my input. Any time you do your work as a maintainer you're relying on tooling I personally built to make maintaining Homebrew easier for you to do so (again, often overruling other maintainers in doing so). In short, it feels like people are happy to have me do what I do in practice but not in theory; as long as it helps you accomplish your current goal you'd like to have me use my position to help but as soon as I disagree you want to constrain my ability to do that in future. It's a pretty shitty feeling, honestly, and I'm disappointed to be made to feel that way in a thread where I've been trying to document what I do in order to be held more accountable to be repeatedly accused of being unaccountable. |
|
I'm unsure what more I could have done to depersonalise my concerns here. I tried very very hard to strip away anything that could be considered an attack on you personally and highlight that my concerns predate the creation of the role even. The intent was not & will never be to go after you personally, and I regret that you feel we have. You have the rest of my response privately. I welcome the idea of a PR being filed on codifying the powers of the lead maintainer & limit of those powers and I'm happy to help draft such a document. If we've reached a point where we need to get all "constitutional convention" about things, that's regrettable, but so be it. |
At some point if you're going to criticise a position that's held by a person: that person is going to take some of what you say as a personal critique.
That's literally what this PR is and I've addressed everything actionable that was proposed. No-one has commented on the individual lines that I've written here.
I'm not sure I understand why from your perspective that would be regrettable? If this is a problem: should there not be an attempt at addressing and discussing it? If it's not a problem: why bring it up in the first place? |
|
I don't think it's helpful for us to have two active, inevitably quite heavy & emotionally-taxing discussions running concurrently so I will refrain from further comment in this one. From the private discussion I will work on whatever steps I wish to take next, and of course, other people are welcome to leap over me with whatever steps they feel are necessary or desirable. That's where I'm leaving my part in this thread. |
|
😕
Unrelated:
|
|
@maxim-belkin Thanks for lifting the spirits! Locking the thread. Important things were said but the PR is now merged. |
I've tried to write up a description of what I think the lead maintainer of Homebrew should (and should not) do.
@Homebrew/maintainers I'd love your feedback on this; what do you think of what's written and is there anything else you'd like me to be doing (or think I should be doing) that I'm not?
brew stylewith your changes locally?brew testswith your changes locally?