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

[Enrico Mrass <emrass@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?