From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Josh Steadmon <steadmon@google.com>,
git@vger.kernel.org, karthik.188@gmail.com, me@ttaylorr.com,
emrass@google.com, nasamuffin@google.com
Subject: Re: [PATCH v3] doc: describe the project's decision-making process
Date: Fri, 17 May 2024 09:40:02 -0700 [thread overview]
Message-ID: <xmqqy188jst9.fsf@gitster.g> (raw)
In-Reply-To: <Zkb5WeaTOLg9b5p8@tanuki> (Patrick Steinhardt's message of "Fri, 17 May 2024 08:29:45 +0200")
Patrick Steinhardt <ps@pks.im> writes:
>> +This document describes the current decision-making process in the Git
>> +project. It is a descriptive rather than prescriptive doc; that is, we want to
>> +describe how things work in practice rather than explicitly recommending any
>> +particular process or changes to the current process.
>
> Nit: I think we _do_ want to recommend a process, but don't want to cast
> it into stone.
Yup. How would we rephase it? "... rather than recommending an
idealized process that we wish to use (but do not)?"
>> +When consensus is reached that it is a good idea, the original
>> +proposer is expected to coordinate the effort to make it happen,
>> +with help from others who were involved in the discussion, as
>> +needed.
>
> One thing I want to eventually propose is to go further here:
> documenting the outcome of the discussion, regardless of whether we
> decided for or against it, in a low-overhead format. This could for
> example be a small paragraph in a "Documentation/Projects" file that
> points to the on-list discussion together with a small summary of why
> the decision was reached.
Having such a list certainly is handy; the problem is how to keep
them current, though.
> I don't think that this change needs to be part of your patch though, as
> your intent is only to document processes as they work right now. But I
> wanted to bring this up regardless as a foreshadowing.
Yup, I agree that it is probably better left out of the scope for
now.
If we are in the "expressing wish" mode, another thing we might find
it useful, if such a thing existed, is a list of principles for
designing new things. E.g., not changing an established behaviour
to prioritize protecting existing users' muscle memory over whims of
the day by folks who haven't had enough time to familialize with it.
E.g., the plumbing output is sacred but the Porcelain output is
subject to change to improve human-user experience with coloring
and pagination, etc.
next prev parent reply other threads:[~2024-05-17 16:40 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 23:20 [RFC PATCH] doc: describe the project's decision-making process Josh Steadmon
2024-04-16 0:24 ` Junio C Hamano
2024-04-22 21:10 ` Josh Steadmon
2024-04-22 21:30 ` Junio C Hamano
2024-04-23 22:41 ` Junio C Hamano
2024-04-17 16:32 ` Enrico Mrass
2024-04-17 16:58 ` Junio C Hamano
2024-05-03 14:45 ` Junio C Hamano
2024-05-03 15:48 ` Josh Steadmon
2024-05-03 18:08 ` Junio C Hamano
2024-05-03 19:29 ` Taylor Blau
2024-05-06 7:12 ` Patrick Steinhardt
2024-05-06 20:14 ` Taylor Blau
2024-05-06 19:36 ` Josh Steadmon
2024-05-06 20:17 ` Taylor Blau
2024-04-22 18:41 ` Emily Shaffer
2024-04-22 19:18 ` Junio C Hamano
2024-04-22 21:12 ` Emily Shaffer
2024-04-23 1:10 ` Junio C Hamano
2024-05-09 0:01 ` [PATCH v2] " Josh Steadmon
2024-05-09 18:10 ` Junio C Hamano
2024-05-09 19:20 ` Junio C Hamano
2024-05-09 21:13 ` [PATCH 0/2] Describe patch-flow better in SubmittingPatches Junio C Hamano
2024-05-09 21:13 ` [PATCH 1/2] SubmittingPatches: move the patch-flow section earlier Junio C Hamano
2024-05-09 21:13 ` [PATCH 2/2] SubmittingPatches: extend the "flow" section Junio C Hamano
2024-05-10 10:08 ` Karthik Nayak
2024-05-10 15:59 ` Junio C Hamano
2024-05-10 19:09 ` Karthik Nayak
2024-05-10 16:55 ` [PATCH v2 0/2] Describe life cycle of a patch series Junio C Hamano
2024-05-10 16:55 ` [PATCH v2 1/2] SubmittingPatches: move the patch-flow section earlier Junio C Hamano
2024-05-10 16:55 ` [PATCH v2 2/2] SubmittingPatches: extend the "flow" section Junio C Hamano
2024-05-10 16:56 ` [PATCH] decisions: focus on larger scale issues Junio C Hamano
2024-05-15 20:36 ` Josh Steadmon
2024-05-15 20:50 ` Junio C Hamano
2024-05-15 20:35 ` [PATCH v2 0/2] Describe life cycle of a patch series Josh Steadmon
2024-05-16 21:20 ` [PATCH v3] doc: describe the project's decision-making process Josh Steadmon
2024-05-16 22:01 ` Junio C Hamano
2024-05-17 20:18 ` Josh Steadmon
2024-05-17 6:29 ` Patrick Steinhardt
2024-05-17 16:40 ` Junio C Hamano [this message]
2024-05-21 5:56 ` Patrick Steinhardt
2024-05-17 20:35 ` [PATCH v4] " Josh Steadmon
2024-05-17 22:12 ` Junio C Hamano
2024-05-21 5:58 ` Patrick Steinhardt
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=xmqqy188jst9.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=emrass@google.com \
--cc=git@vger.kernel.org \
--cc=karthik.188@gmail.com \
--cc=me@ttaylorr.com \
--cc=nasamuffin@google.com \
--cc=ps@pks.im \
--cc=steadmon@google.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 read-only IMAP folder(s) and NNTP newsgroup(s).