Re: [RFC PATCH] doc: describe the project's decision-making process

From: Enrico Mrass <emrass@google.com>
Date: Apr 17, 2024, 16:32 UTC
Message-ID: <20240417163244.651791-1-emrass@google.com>
In-Reply-To: <b2ef74c1b0c7482fa880a1519fd6ea1032df7789.1713222673.git.steadmon@google.com>

Josh Steadmon <steadmon@google.com> writes:

> Document these norms so that newcomers to the project can learn what to
> expect.

As a newcomer (first reply to the list), I highly appreciate the effort. Thank you!

> +After a suitable period of time has passed, the maintainer will judge whether or
> +not consensus has been reached. If so, the consensus decision will be
> +implemented. Otherwise, discussion may continue, or the proposal may be
> +abandoned.

I'd be curious to learn about norms or practices applied when no consensus could be reached. It seems worth elaborating on that as part of documenting the decision-making process.

> making bigger-picture decisions (above and beyond individual patches and
> patch series)

I understand how bigger-picture decisions (complex, larger scale architectural decisions, often involving multiple components, likely requiring a design discussion / review) are different from individual patches. However, nothing in the current description strikes me as specific to these larger-scale decisions. Are there norms / practices that specifically address challenges around large-scale changes that are worth documenting here, like encouraging a design for discussion in the first place?