# OCI Working Group Draft Proposal

*This document will be put made as PR with an addition to [CHARTER.md](https://github.com/opencontainers/tob/blob/master/CHARTER.md)*

## 7. Working Groups

a. The OCI may establish workings groups ("OCI Working Group") to experiment, validate, and define new specifications or major revisions to existing specifications. The working groups start out with a tightly defined scope of what the working group aims to accomplish. Once the working group has completed its work, the end result will either by a new specification ("OCI Specification"), an update to an existing specification, or a new project.

b. Any member of the OCI community may propose a working group to the TOB for review. Approval of a new working group requires a two-thirds vote of the TOB.

c. OCI Working Group proposals should contain the following information:
- i. a clearly defined objective and scope of what the working groups aims to accomplish; and
- ii. a list of owners who have agreed to participate in the working group, review progress, report progress back to the OCI community, and present the results to the TOB once the working group has completed its objectives; and
- iii. a list of projects or organizations sponsoring the working group and participating in the implementation and use case validation of the work done by the group; and
- iv. a set of project rules which govern how contributions to the working group will be handled and decisions will be made; and
- v. a working agreement for making progress, which may include weekly meetings, dedicated channels for discussions, or a shared repository; and
- vi. a request for OCI resources, which may include recurring meetings in the OCI calendar, OCI hosted repository, or topic specific communication channels.

d. The TOB will maintain a collection of all approved working groups ("OCI Working Groups").

e. Once a working group has achieved its objectives, the working group owners will present to the TOB the draft specification, the validation work which prove real world usability, and the set of maintainers which have agreed to carry the specification forward. There is no requirement that owners or contributors be maintainers for an accepted specification, however, the TOB will consider it a requirement that any project or specification has dedicated and active group of maintainers to continue the work.

f. A draft proposal requires a two-thirds vote of the TOB for approval.

g. Once a draft proposal is approved, the specification may by released as a major versioned release candidate. The new set of maintainers will decide how and when to do releases.

h. Before TOB approval, a working group may only issue releases with a `-draft.<draft number>` suffix.

i. If a working group does not make meaningful progress or becomes inactive, the TOB may vote to disband the working group with a two-thirds majority vote.

----
**Notes not apart of PR**

*Note: Distribution spec could have been done as a working group. Specs are accepted as complete versions, the wg is responsible for publishing it owns drafts. Not all owners are necessarily maintainers after the spec is released, the maintainers are intended to be the stewards of the spec at that major version, not owners of all large changes*