git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Arver <linusa@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Linus Arver via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] RFC: add MAINTAINERS file
Date: Sat, 30 Mar 2024 10:59:53 -0700	[thread overview]
Message-ID: <owlyttkn61nq.fsf@fine.c.googlers.com> (raw)
In-Reply-To: <xmqq4jcr6bx2.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

> Linus Arver <linusa@google.com> writes:
>
>> I realize that such an idea is beyond the scope of a simple MAINTAINERS
>> (or similar) file that's checked into the Git code repo, but I think
>> it's worth stating as a thought experiment.
>
> As we already have agreed that neither of us care the exact format
> of the file (yet), regardless of how a contributor, who is about to
> send a patch, will find an area "maintainer" to help the patch along
> the process, it is far more important to discuss and decide what
> responsibilities and authorities are expected of these maintainers.

I'm starting to think that the new responsibility should be as small as
possible, and build from there. So the smallest bit of (initial?)
responsibility expected of the new roster of maintainers could be
"maintainer must respond to CC pings on the list within 7 days".

For those who have more time to spend on the project, the next rung of
responsibility could be "maintainer is available to review patches
outside of their domain of expertise if no one else has reviewed the
series in 7 days".

I haven't thought too much about the "authority" part yet.

> The development community has been fairly loosely organized so far,
> but I'd like to see responsibility and authority spread a bit more
> widely yet still not too thinly to compromise the project integrity.

Agreed.

  reply	other threads:[~2024-03-30 17:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-23  3:27 [PATCH] RFC: add MAINTAINERS file Linus Arver via GitGitGadget
2024-03-23 19:19 ` Junio C Hamano
2024-03-25  2:51   ` Junio C Hamano
2024-03-27  5:33     ` Linus Arver
2024-03-27  7:17     ` Patrick Steinhardt
2024-03-30 18:03       ` Linus Arver
2024-03-30 21:44         ` Junio C Hamano
2024-04-01 21:33       ` Taylor Blau
2024-04-01 22:13         ` Junio C Hamano
2024-04-02  0:22           ` Linus Arver
2024-04-02  5:39           ` Patrick Steinhardt
2024-04-02  5:46             ` Eric Sunshine
2024-04-02  5:59               ` Patrick Steinhardt
2024-03-26 22:24   ` Linus Arver
2024-03-26 23:39   ` Taylor Blau
2024-03-27  0:05     ` Junio C Hamano
2024-03-27  4:32   ` Linus Arver
2024-03-27 13:29     ` Junio C Hamano
2024-03-30 17:59       ` Linus Arver [this message]
2024-04-02  6:22         ` Patrick Steinhardt
2024-04-04  0:47           ` Linus Arver
2024-04-02  7:00       ` Patrick Steinhardt
2024-04-02 17:00         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=owlyttkn61nq.fsf@fine.c.googlers.com \
    --to=linusa@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).