This is a proposed process for approval of new releases of
specifications and projects from the OCI.

The creation of this process is designed to clarify how a release gets
created and who needs to sign off.

I got some feedback from folks that some motivation early in the
document might be helpful for why the process encourages regular
communication.

Requiring applications wait 1 week to get feedback before making a release,
removing "business day" wording @cyphar, @stevvooe, and @wking were in the
discussion.[1]

[1] opencontainers#15 (comment)

Requiring the _minimum_ process for a major release to be 3 rcs and a
final release. This will establish a _minimum_ timeline of 1 month to
get to a release assuming zero required changes.  @stevvooe, @wking were
in this discussion.

opencontainers#15 (comment)

Changing the release goal for projects to a "SHOULD monthly release"
from the original bi-weekly. @diogomonica, @stevvooe, @mrunalp,
@RobDolinMS were in that discussion

opencontainers#15 (comment)

Fix up the language around REJECTs so it is easier to understand. The
basic premise is that a release may continue with REJECTs if 2/3 of the
maintainers vote to make the release. But, the maintainers SHOULD
discuss and allow time for any REJECTs to become LGTMs. Spread over two
discussions:

[1](https://github.com/opencontainers/tob/pull/15/files/bdfa70d70f093146bc730be2576586ec8ed57cca#r66519789)
and
[2](https://github.com/opencontainers/tob/pull/15/files/bdfa70d70f093146bc730be2576586ec8ed57cca#r66668148)

Based on discussion with @wking and @stevvooe

https://github.com/opencontainers/tob/pull/15/files/bdfa70d70f093146bc730be2576586ec8ed57cca#r66543381

The intention of the voting members language is to ensure that releases
can proceed even if people are unresponsive, on vacation, etc without
ambiguity. This is similar to how the TOB operates.

Identified by @wking here: opencontainers#15 (comment)

Based on discussion with wking and mrunalp participating and Stephen Day
acking in IRC: opencontainers#15 (comment)

This addresses @stevvooe's concern about GitHub issues being the only
medium for discussion of a reject. @wking and @philips were involved in
this discussion:

opencontainers#15 (comment)

Projects have a happy path and a slow path. The happy path is a release
with maintainers agreeing and a timeout. The slow path has rejects and
quorums. Based on discussion with @wking

opencontainers#15 (comment)

Instead of being prescriptive provide suggestions instead for how to
provide release REJECTS feedback. Based on feedback from Stephen Day and
@wking.

Fixup qourum typos based on feedback from @wking.

Avoid duplication by collecting common ideas (e.g. list-based voting)
in their own sections.  After this reshuffling, it became apparent
that there were no special application restrictions, so I added
additional language to motivate the specification-specific additions.

Signed-off-by: W. Trevor King <wking@tremily.us>

#1 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

Reported by Tianon
opencontainers#15 (comment)

Expand a bit more information about the security@ alias and who is
involved in a security sensitive release.