the latter half of october, the maintainer goes offline

the latter half of october, the maintainer goes offline

[Junio C Hamano]

I plan to go offline for the latter half of this month (I may
sporadically pop up but may not be engaging deeply in the
discussions or picking up patches).

This time, can we try a fire drill that I do not nominate or ask
anybody to be an interim maintainer and see how well community
manages the discussion and patch flow during these two weeks?

It can be somebody stepping up and say "ok, I'll self nominate and
run the project as the interim maintainer, just like it was done in
the past years", or "let's do something differently, how about
everybody throws a merge request to this mob repository, use this
(possibly different) review procedure, and give back the tip of
'master' when Junio returns", or "OK, we'll discuss and exchange
patches for these two weeks among ourselves and we can cope without
a central meeting place".

IOW, I am interested to see if the community comes up with a
day-to-day project structure that may be better for the contributors
than what I have dictated in the past during my vacation time.

Thanks.

Re: the latter half of october, the maintainer goes offline

[Taylor Blau]

On Thu, Oct 03, 2024 at 10:26:19AM -0700, Junio C Hamano wrote:
> It can be somebody stepping up and say "ok, I'll self nominate and
> run the project as the interim maintainer, just like it was done in
> the past years", or "let's do something differently, how about
> everybody throws a merge request to this mob repository, use this
> (possibly different) review procedure, and give back the tip of
> 'master' when Junio returns", or "OK, we'll discuss and exchange
> patches for these two weeks among ourselves and we can cope without
> a central meeting place".
>
> IOW, I am interested to see if the community comes up with a
> day-to-day project structure that may be better for the contributors
> than what I have dictated in the past during my vacation time.

Interesting. If list participants would prefer to use the same structure
as when you're not on vacation, I'm happy to shuffle the patches and
send regular "What's cooking" reports for those couple of weeks.

I guess that amounts to the "I'll self nominate and run the project as
interim maintainer" option you mentioned above :-).

Thanks,
Taylor

Re: the latter half of october, the maintainer goes offline

[Patrick Steinhardt]

On Thu, Oct 03, 2024 at 01:53:49PM -0400, Taylor Blau wrote:
> On Thu, Oct 03, 2024 at 10:26:19AM -0700, Junio C Hamano wrote:
> > It can be somebody stepping up and say "ok, I'll self nominate and
> > run the project as the interim maintainer, just like it was done in
> > the past years", or "let's do something differently, how about
> > everybody throws a merge request to this mob repository, use this
> > (possibly different) review procedure, and give back the tip of
> > 'master' when Junio returns", or "OK, we'll discuss and exchange
> > patches for these two weeks among ourselves and we can cope without
> > a central meeting place".
> >
> > IOW, I am interested to see if the community comes up with a
> > day-to-day project structure that may be better for the contributors
> > than what I have dictated in the past during my vacation time.
> 
> Interesting. If list participants would prefer to use the same structure
> as when you're not on vacation, I'm happy to shuffle the patches and
> send regular "What's cooking" reports for those couple of weeks.
> 
> I guess that amounts to the "I'll self nominate and run the project as
> interim maintainer" option you mentioned above :-).

First things first: I wouldn't mind you doing it again.

But I'd also like to take this opportunity to think a bit about the
bigger picture: what do we all do when Junio stops working on Git at
some point in time? Right now we don't really have a plan for that at
all, to the best of my knowledge. I know this is going a bit further
than what Junio has hinted at with this "fire drill", but thinking about
such a potential future is certainly important. And if we can come up
with good ideas, then we might as well try them out and experiment a bit
while Junio is out.

First, let's talk about the requirements that come to my mind for any
replacement:

  - Doing Junio's work certainly is a full-time job, whether that
    full-time job is handled by a single person or split up across a
    team.

  - As far as I can see, doing the maintainer job doesn't allow for a
    ton of hacking. So whoever is taking over likely wouldn't be able to
    land much code anymore.

  - Junio is doing a great job of being independent from any kind of
    company agenda as far as I can tell. A replacement would have to be
    just that, either because that person is being independently funded
    or because it is a team set up similar to the PLC.

  - It goes without saying that the person would need to have deep
    knowledge of Git and the codebase such that they can make informed
    decisions.

There are two maintainership models I can think of: either a single
individual or a group of people would take over.

  - A single individual needs funding. The ideal situation would be if
    that funding came independent of any of the large forges. Or
    alternatively, the big players in this context come together to all
    pay into the same pot to fund that person. In theory, the role could
    be elected and serve for a limited amount of time so that overall,
    the community is in control.

  - A group of individuals could take over, sharing the responsibility.
    There would be a ton of different questions in this context: how to
    form the group, how to balance its interests, how to distribute the
    work across its members, how to resolve disputes, etc.

So... that's just me dumping a bunch of thoughts. I'd be quite curious
to learn about everyone else's thoughts.

Patrick

Re: the latter half of october, the maintainer goes offline

[shejialuo]

On Fri, Oct 04, 2024 at 05:22:27PM +0200, Patrick Steinhardt wrote:

[snip]

> There are two maintainership models I can think of: either a single
> individual or a group of people would take over.
> 
>   - A single individual needs funding. The ideal situation would be if
>     that funding came independent of any of the large forges. Or
>     alternatively, the big players in this context come together to all
>     pay into the same pot to fund that person. In theory, the role could
>     be elected and serve for a limited amount of time so that overall,
>     the community is in control.

Well, I think we cannot easily fund a single individual. It it is a
full-time job, we have to also pay for the insurances. I don't know
how to hire an individual in an open source project. But intuitively I
think there would be a lot of trouble here due to the laws. As far as I
know, Junio is working at Google.

So, the biggest problem here is that most of us either work at other
companies for full-time job which are not unrelated to Git or work at
companies which are related to Git(upstream). Although it is an honor to
be hired by an open source project, there are still many concerns for an
individual.

>   - A group of individuals could take over, sharing the responsibility.
>     There would be a ton of different questions in this context: how to
>     form the group, how to balance its interests, how to distribute the
>     work across its members, how to resolve disputes, etc.

From my perspective, we already did this. Junio will rely on the reviews
from other contributors. This is what I got from the Git Contributor's
Summit, 2024: [TOPIC 10/11] Project Tracking.

  https://lore.kernel.org/git/xmqqployf6z5.fsf@gitster.g/

> So... that's just me dumping a bunch of thoughts. I'd be quite curious
> to learn about everyone else's thoughts.
> 

Like Patrick, I just give some my thoughts here. Because I am a newcomer
in the community. I may lose some context. So, there may be some
incorrect expressions.

Thanks,
Jialuo

Re: the latter half of october, the maintainer goes offline

[shejialuo]

> Well, I think we cannot easily fund a single individual. It it is a
> full-time job, we have to also pay for the insurances. I don't know
> how to hire an individual in an open source project. But intuitively I
> think there would be a lot of trouble here due to the laws. As far as I
> know, Junio is working at Google.
> 
> So, the biggest problem here is that most of us either work at other
> companies for full-time job which are not unrelated to Git or work at
> companies which are related to Git(upstream). Although it is an honor to
> be hired by an open source project, there are still many concerns for an
> individual.
> 

"which are not unrelated to Git" should be "which are unrelated to Git".
Sorry for typos here.

> From my perspective, we already did this. Junio will rely on the reviews
> from other contributors. This is what I got from the Git Contributor's
> Summit, 2024: [TOPIC 10/11] Project Tracking.
> 
>   https://lore.kernel.org/git/xmqqployf6z5.fsf@gitster.g/
> 

I forgot to show my intention here. I do not think we need to really
distinguish these two modes. Even if we hire an individual, the
individual still needs the help from the community about the unfamiliar
fields.

Re: the latter half of october, the maintainer goes offline

[Junio C Hamano]

shejialuo <shejialuo@gmail.com> writes:

> On Fri, Oct 04, 2024 at 05:22:27PM +0200, Patrick Steinhardt wrote:
>
> [snip]
>
>> There are two maintainership models I can think of: either a single
>> individual or a group of people would take over.
>> 
>>   - A single individual needs funding. The ideal situation would be if
>>     that funding came independent of any of the large forges. Or
>>     alternatively, the big players in this context come together to all
>>     pay into the same pot to fund that person. In theory, the role could
>>     be elected and serve for a limited amount of time so that overall,
>>     the community is in control.
>
> Well, I think we cannot easily fund a single individual. It it is a
> full-time job, we have to also pay for the insurances. I don't know
> how to hire an individual in an open source project. But intuitively I
> think there would be a lot of trouble here due to the laws.

I think the model Patrick has in mind for the above is like how
Linux Foundation hires Linus Torvalds to work full time on Linux,
while the Foundation is funded by large industry players.

Git has become important enough that such a model may be workable,
and that may make it easier to maintain appearance of impartiality
by whoever is being funded.

Re: the latter half of october, the maintainer goes offline

[Taylor Blau]

On Fri, Oct 04, 2024 at 09:58:52AM -0700, Junio C Hamano wrote:
> shejialuo <shejialuo@gmail.com> writes:
>
> > On Fri, Oct 04, 2024 at 05:22:27PM +0200, Patrick Steinhardt wrote:
> >
> > [snip]
> >
> >> There are two maintainership models I can think of: either a single
> >> individual or a group of people would take over.
> >>
> >>   - A single individual needs funding. The ideal situation would be if
> >>     that funding came independent of any of the large forges. Or
> >>     alternatively, the big players in this context come together to all
> >>     pay into the same pot to fund that person. In theory, the role could
> >>     be elected and serve for a limited amount of time so that overall,
> >>     the community is in control.
> >
> > Well, I think we cannot easily fund a single individual. It it is a
> > full-time job, we have to also pay for the insurances. I don't know
> > how to hire an individual in an open source project. But intuitively I
> > think there would be a lot of trouble here due to the laws.

It is definitely true that the Git project alone could not fund a full
year of the maintainer's salary [1].

> I think the model Patrick has in mind for the above is like how
> Linux Foundation hires Linus Torvalds to work full time on Linux,
> while the Foundation is funded by large industry players.
>
> Git has become important enough that such a model may be workable,
> and that may make it easier to maintain appearance of impartiality
> by whoever is being funded.

Sure, though I would add that my personal feeling is that it is a
possibility, not a requirement, that the maintainer's funding come from
either an independent entity (like the Linux Foundation) or from a pool
funded by industry leaders.

I say that only to point out that while Junio is employed by Google, I
don't think any of us would doubt his impartiality with regard to the
project.

I think as long as the maintainer's employer does not unfairly influence
the maintainer's decisions on their behalf, then it is OK.

Thanks,
Taylor

[1]: https://lore.kernel.org/git/Zusxcweod1O88h7j@nand.local/

Re: the latter half of october, the maintainer goes offline

[Taylor Blau]

On Fri, Oct 04, 2024 at 05:22:27PM +0200, Patrick Steinhardt wrote:
> There are two maintainership models I can think of: either a single
> individual or a group of people would take over.
>
>   - A single individual needs funding. The ideal situation would be if
>     that funding came independent of any of the large forges. Or
>     alternatively, the big players in this context come together to all
>     pay into the same pot to fund that person. In theory, the role could
>     be elected and serve for a limited amount of time so that overall,
>     the community is in control.
>
>   - A group of individuals could take over, sharing the responsibility.
>     There would be a ton of different questions in this context: how to
>     form the group, how to balance its interests, how to distribute the
>     work across its members, how to resolve disputes, etc.

I do think there is a need to have a single individual who is ultimately
responsible for ensuring that the patches are reviewed and merged in a
timely fashion, that releases are cut on time and are high-quality, etc.

But I also think that the project benefits from having trusted
individuals who are knowledgeable about specific areas of the codebase.
The maintainer can lean and rely on those individuals to get a sanity
check of whether or not some patches are good or not. For instance, I
would imagine that Junio relies on you to help review patches in the
reftable implementation.

I think that's more or less the status-quo, and IMHO it works well from
a contributor's perspective. I would be curious if the maintainer feels
the same or not ;-).

I know that we have discussed in the past a more formalized version of
the above where individual sub-systems maintainers are listed in a
MAINTAINERS file with specific roles and responsibilities. I don't think
the project is large enough or has enough active participants to warrant
that formal of a process, but perhaps I am in the minority here.

Thanks,
Taylor

Re: the latter half of october, the maintainer goes offline

[Patrick Steinhardt]

On Fri, Oct 04, 2024 at 06:35:44PM -0400, Taylor Blau wrote:
> On Fri, Oct 04, 2024 at 09:58:52AM -0700, Junio C Hamano wrote:
> > shejialuo <shejialuo@gmail.com> writes:
> >
> > > On Fri, Oct 04, 2024 at 05:22:27PM +0200, Patrick Steinhardt wrote:
> > >
> > > [snip]
> > >
> > >> There are two maintainership models I can think of: either a single
> > >> individual or a group of people would take over.
> > >>
> > >>   - A single individual needs funding. The ideal situation would be if
> > >>     that funding came independent of any of the large forges. Or
> > >>     alternatively, the big players in this context come together to all
> > >>     pay into the same pot to fund that person. In theory, the role could
> > >>     be elected and serve for a limited amount of time so that overall,
> > >>     the community is in control.
> > >
> > > Well, I think we cannot easily fund a single individual. It it is a
> > > full-time job, we have to also pay for the insurances. I don't know
> > > how to hire an individual in an open source project. But intuitively I
> > > think there would be a lot of trouble here due to the laws.
> 
> It is definitely true that the Git project alone could not fund a full
> year of the maintainer's salary [1].

Yes. As Junio said, ...

> > I think the model Patrick has in mind for the above is like how
> > Linux Foundation hires Linus Torvalds to work full time on Linux,
> > while the Foundation is funded by large industry players.

... something like this is what I have in mind here.

> > Git has become important enough that such a model may be workable,
> > and that may make it easier to maintain appearance of impartiality
> > by whoever is being funded.

Indeed. There's at least two large companies that care very deeply about
Git being healthy in the long term. So securing funding from those
companies should be a no-brainer for them.

> Sure, though I would add that my personal feeling is that it is a
> possibility, not a requirement, that the maintainer's funding come from
> either an independent entity (like the Linux Foundation) or from a pool
> funded by industry leaders.
> 
> I say that only to point out that while Junio is employed by Google, I
> don't think any of us would doubt his impartiality with regard to the
> project.

Oh, yes, and I've explicitly mentioned that Junio is doing an awesome
job of that indeed. But I see the employment by Google as kind of an
outlier here, because Google itself is not really competing in the Git
ecosystem. They do not sell a Git-based product directly to customers as
both GitHub and GitLab do, to the best of my knowledge.

> I think as long as the maintainer's employer does not unfairly influence
> the maintainer's decisions on their behalf, then it is OK.

So yes, I would probably be okay with a maintainer that is employed by a
company which I don't see as competing in this space. But I would
strongly disagree with this statement if the intent were to ever have a
GitHub or GitLab employee become the single maintainer.

Impartiality is only one part of the picture here. The other part is
that Git would start to feel like a project owned by that company. There
simply is too much political tension for this to work out in the long
term, in my opinion.

So if we do not have an individual at the ready that is independent,
then I would strongly favor a model where the maintainer role is shared
across a group of people.

Patrick

> Thanks,
> Taylor
> 
> [1]: https://lore.kernel.org/git/Zusxcweod1O88h7j@nand.local/

Re: the latter half of october, the maintainer goes offline

[Taylor Blau]

On Mon, Oct 07, 2024 at 07:47:07AM +0200, Patrick Steinhardt wrote:
> > Sure, though I would add that my personal feeling is that it is a
> > possibility, not a requirement, that the maintainer's funding come from
> > either an independent entity (like the Linux Foundation) or from a pool
> > funded by industry leaders.
> >
> > I say that only to point out that while Junio is employed by Google, I
> > don't think any of us would doubt his impartiality with regard to the
> > project.
>
> Oh, yes, and I've explicitly mentioned that Junio is doing an awesome
> job of that indeed. But I see the employment by Google as kind of an
> outlier here, because Google itself is not really competing in the Git
> ecosystem. They do not sell a Git-based product directly to customers as
> both GitHub and GitLab do, to the best of my knowledge.

I think your argument looses some subtlety here. Indeed, Google does not
sell a SaaS product based on Git like GitHub and GitLab do. But they
most certainly use Git extensively within Google. And I imagine that the
engineering team working on Git at Google has certain things that they
would like the project to do that would benefit Google's use of Git.

But what I don't see is Google benefiting unfairly by employing the
maintainer. So as long as Junio continues to maintain that impartiality,
I don't see any problem with him being employed by Google.

The other aspect of this is that it is Junio's personal choice where
they would like to work. Is it possible to organize some kind of shared
funding model? Perhaps (though I am personally not convinced). But I
think that imposing that model on Junio is not fair to him. Junio may
wish to work at Google for other reasons (e.g., perhaps he likes the
benefits, his work environment, benefits from his tenure there, etc.).

As long as Junio remains impartial, I do not see why the project should
dictate his choice of employer. Or IOW, if Junio woke up tomorrow with a
job offer from GitLab or GitHub (or any other company), I do not think
the project should dictate that he turn it down, or mandate that he be
replaced as maintainer for exercising his personal choice.

IOW, I think that the maintainer's impartiality is the most important
aspect of this. So long as the maintainer is impartial, I don't see why
they can't work at any company they choose.

> > I think as long as the maintainer's employer does not unfairly influence
> > the maintainer's decisions on their behalf, then it is OK.
>
> So yes, I would probably be okay with a maintainer that is employed by a
> company which I don't see as competing in this space. But I would
> strongly disagree with this statement if the intent were to ever have a
> GitHub or GitLab employee become the single maintainer.
>
> Impartiality is only one part of the picture here. The other part is
> that Git would start to feel like a project owned by that company. There
> simply is too much political tension for this to work out in the long
> term, in my opinion.

Again, I don't really see how this is the case. Git does not feel like a
Google project to me, even though Junio is employed by Google. I think
as long as the maintainer is impartial with respect to their employer,
then their individual choice of employer should not matter.

> So if we do not have an individual at the ready that is independent,
> then I would strongly favor a model where the maintainer role is shared
> across a group of people.

Like I mentioned earlier in this thread, I don't really see how this
model would work.

Thanks,
Taylor

Re: the latter half of october, the maintainer goes offline

[Patrick Steinhardt]

On Mon, Oct 07, 2024 at 10:56:06AM -0400, Taylor Blau wrote:
> On Mon, Oct 07, 2024 at 07:47:07AM +0200, Patrick Steinhardt wrote:
> > > Sure, though I would add that my personal feeling is that it is a
> > > possibility, not a requirement, that the maintainer's funding come from
> > > either an independent entity (like the Linux Foundation) or from a pool
> > > funded by industry leaders.
> > >
> > > I say that only to point out that while Junio is employed by Google, I
> > > don't think any of us would doubt his impartiality with regard to the
> > > project.
> >
> > Oh, yes, and I've explicitly mentioned that Junio is doing an awesome
> > job of that indeed. But I see the employment by Google as kind of an
> > outlier here, because Google itself is not really competing in the Git
> > ecosystem. They do not sell a Git-based product directly to customers as
> > both GitHub and GitLab do, to the best of my knowledge.
> 
> I think your argument looses some subtlety here. Indeed, Google does not
> sell a SaaS product based on Git like GitHub and GitLab do. But they
> most certainly use Git extensively within Google. And I imagine that the
> engineering team working on Git at Google has certain things that they
> would like the project to do that would benefit Google's use of Git.

Using Git internally is kind of a different thing compared to selling
Git directly to customers though. Google also isn't (to the best of my
knowledge) benefitting directly from being able to say that one of its
employees is the head of Git.

And I think that is where things start to fall apart, because I think
that it would give a certain advantage to whichever large forge hosts.
For one part that may be because of being able to push through things
that the other forge cannot. But the more likely scenario is that this
is a huge boon to that company's marketing department. So even if the
maintainer would be impartial, I doubt that the company as a whole would
be.

> But what I don't see is Google benefiting unfairly by employing the
> maintainer. So as long as Junio continues to maintain that impartiality,
> I don't see any problem with him being employed by Google.
> 
> The other aspect of this is that it is Junio's personal choice where
> they would like to work. Is it possible to organize some kind of shared
> funding model? Perhaps (though I am personally not convinced). But I
> think that imposing that model on Junio is not fair to him. Junio may
> wish to work at Google for other reasons (e.g., perhaps he likes the
> benefits, his work environment, benefits from his tenure there, etc.).
> 
> As long as Junio remains impartial, I do not see why the project should
> dictate his choice of employer. Or IOW, if Junio woke up tomorrow with a
> job offer from GitLab or GitHub (or any other company), I do not think
> the project should dictate that he turn it down, or mandate that he be
> replaced as maintainer for exercising his personal choice.

But I haven't ever been talking about changing the _current_ model, and
I do not intend to change the way Junio is employed. As you rightfully
say, this would certainly cross a line. I am talking about a potential
future where Junio may not be maintaining Git anymore, due to whatever
reason.

> IOW, I think that the maintainer's impartiality is the most important
> aspect of this. So long as the maintainer is impartial, I don't see why
> they can't work at any company they choose.

Exactly, that is my own take, as well. And I personally do not believe
that this is compatible with being employed by any of the large forges.

> > > I think as long as the maintainer's employer does not unfairly influence
> > > the maintainer's decisions on their behalf, then it is OK.
> >
> > So yes, I would probably be okay with a maintainer that is employed by a
> > company which I don't see as competing in this space. But I would
> > strongly disagree with this statement if the intent were to ever have a
> > GitHub or GitLab employee become the single maintainer.
> >
> > Impartiality is only one part of the picture here. The other part is
> > that Git would start to feel like a project owned by that company. There
> > simply is too much political tension for this to work out in the long
> > term, in my opinion.
> 
> Again, I don't really see how this is the case. Git does not feel like a
> Google project to me, even though Junio is employed by Google. I think
> as long as the maintainer is impartial with respect to their employer,
> then their individual choice of employer should not matter.

As I said: Google is a bit of a special case. Another big part here is
also history given that Junio has been maintaing Git _before_ he has
joined Google, to the best of my knowledge.

> > So if we do not have an individual at the ready that is independent,
> > then I would strongly favor a model where the maintainer role is shared
> > across a group of people.
> 
> Like I mentioned earlier in this thread, I don't really see how this
> model would work.

Well, it certainly would be a bigger remodeling of how things work right
now, and I do not have an answer right now.

Patrick

Re: the latter half of october, the maintainer goes offline

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> On Fri, Oct 04, 2024 at 05:22:27PM +0200, Patrick Steinhardt wrote:
>> There are two maintainership models I can think of: either a single
>> individual or a group of people would take over.
>> ...
> I do think there is a need to have a single individual who is ultimately
> responsible for ensuring that the patches are reviewed and merged in a
> timely fashion, that releases are cut on time and are high-quality, etc.
>
> But I also think that the project benefits from having trusted
> individuals who are knowledgeable about specific areas of the codebase.
> The maintainer can lean and rely on those individuals to get a sanity
> check of whether or not some patches are good or not. For instance, I
> would imagine that Junio relies on you to help review patches in the
> reftable implementation.
>
> I think that's more or less the status-quo, and IMHO it works well from
> a contributor's perspective. I would be curious if the maintainer feels
> the same or not ;-).

This turned my "explore how you folks want to manage yourselves
while I am away" into "how would we want to run the project after
Gitster retires (or moves on)".  While I find that the rumor of my
retirement is greatly exaggerated, I think that is a discussion
worth having.

It is a tricky topic how we want open source funding to work.

The "benevolent dictator" model, even if the day-to-day operation is
delegated to various area experts (aka lieutenants), cannot work if
such a dictator simply does not exist (due to various reasons,
ranging from "nobody wants to become one" to "community cannot agree
on whom to make one").  The community has to go with some other
model that does not require a dedicated full-time maintainer, even
if it prefers to have one (and the community can choose to follow a
different model even if it can afford one, of course).

I think the status-quo, which was nurtured over the years, is the
best this community can have, *if* we want to keep the "benevolent
dictator" model.  I would not claim that we perfected the model, but
I would say we are close enough.

What I hoped to see happen here was that the community is prepared
when the community has to (or wants to)choose another model.  And I
am happy to see the recent trend to document and codify how we make
decisions and move the project forward, because these efforts help
us whether we have the "benevolent dictator" or not.

Re: the latter half of october, the maintainer goes offline

[Patrick Steinhardt]

On Tue, Oct 08, 2024 at 09:56:36AM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
> 
> > On Fri, Oct 04, 2024 at 05:22:27PM +0200, Patrick Steinhardt wrote:
> >> There are two maintainership models I can think of: either a single
> >> individual or a group of people would take over.
> >> ...
> > I do think there is a need to have a single individual who is ultimately
> > responsible for ensuring that the patches are reviewed and merged in a
> > timely fashion, that releases are cut on time and are high-quality, etc.
> >
> > But I also think that the project benefits from having trusted
> > individuals who are knowledgeable about specific areas of the codebase.
> > The maintainer can lean and rely on those individuals to get a sanity
> > check of whether or not some patches are good or not. For instance, I
> > would imagine that Junio relies on you to help review patches in the
> > reftable implementation.
> >
> > I think that's more or less the status-quo, and IMHO it works well from
> > a contributor's perspective. I would be curious if the maintainer feels
> > the same or not ;-).
> 
> This turned my "explore how you folks want to manage yourselves
> while I am away" into "how would we want to run the project after
> Gitster retires (or moves on)".  While I find that the rumor of my
> retirement is greatly exaggerated, I think that is a discussion
> worth having.

Just to make things clear: I didn't think that you're going to retire
anytime soon. As you say, I rather wanted to use this situation to think
a bit about the bigger picture and think way ahead into the future.

We do not have any kind of contingency plan if you ever did retire, to
the best of my knowledge. And while I hope we won't need such a plan
anytime soon, having some kind of common understanding of how that
situation would be handled in the community would be nice. I could
imagine that this discussion would be rather heated, so my hope was that
it is less heated by having it in a situation without an immediate
need.

> It is a tricky topic how we want open source funding to work.
> 
> The "benevolent dictator" model, even if the day-to-day operation is
> delegated to various area experts (aka lieutenants), cannot work if
> such a dictator simply does not exist (due to various reasons,
> ranging from "nobody wants to become one" to "community cannot agree
> on whom to make one").  The community has to go with some other
> model that does not require a dedicated full-time maintainer, even
> if it prefers to have one (and the community can choose to follow a
> different model even if it can afford one, of course).
> 
> I think the status-quo, which was nurtured over the years, is the
> best this community can have, *if* we want to keep the "benevolent
> dictator" model.  I would not claim that we perfected the model, but
> I would say we are close enough.

I do not really see a strong reason to change the current model while
you are happy to fill in the role. If the model _has_ to change I think
it strongly depends on exactly what you say, whether the community can
agree on a new maintainer or not.

The Linux kernel partially uses group maintainership models for some of
its subsystems, see e.g. [1]. Python uses something a steering council,
which is a 5-person committee [2]. Other large projects like Debian also
use a technical committee to resolve conflicts [3]. So there are some
projects out there where maintainership is handled by a group of people.

Now all of these projects are way bigger than Git, and they of course
have different requirements than we do. So the mere fact that they seem
to use these models successfully doesn't necessarily translate into it
working well for us.

In any case, if we ever wanted to change the model, we'd have to think
quite hard about how to do it.

[1]: https://lwn.net/Articles/705228/
[2]: https://peps.python.org/pep-0013/
[3]: https://www.debian.org/devel/tech-ctte

> What I hoped to see happen here was that the community is prepared
> when the community has to (or wants to)choose another model.  And I
> am happy to see the recent trend to document and codify how we make
> decisions and move the project forward, because these efforts help
> us whether we have the "benevolent dictator" or not.

True. We could also do the same for our maintainership model: lay out
requirements and the different models that fulfill these requirements.
That would allow us to discuss things in detail and capture the results
in a single document.

The intent here wouldn't be to change the current model (at least that
would not be my intent), but to document it and maybe have alternatives
ready if we ever got to the situation where the current model doesn't
work anymore due to whatever reason.

Patrick