1.7.0

Proposals Process

This document describes the process by which interested parties may propose changes to the Magma project. Proposals can be any size and cover any topic, e.g. process updates or architectural changes.

To start, consider skimming the existing Magma project proposals.

Overview

Acceptance

To be accepted, proposals must receive a majority vote from the TSC.

Tracking

Proposals are tracked as GitHub Issues, using the type: proposal label.

The #proposals Slack channel receives notifications when new proposals are created.

Submit a proposal

Submit an Issue

Submit a GitHub Issue following the "Proposal" template. The proposal contents should be clear and concise. Aim for a "one-pager" style.

In many cases, the TSC will delegate their decision to one of the approvers teams. To expedite this process, you can label your proposal with the applicable component, which will help the TSC identify domain experts.

Receive feedback

The TSC, and relevant project maintainers, will discuss the proposal and make comments on the Issue. One of four outcomes will be communicated via labels

If your proposal is accepted, ensure actionable next-steps have been outlined and initiated.

Optional: needs design doc

If your proposal is labeled as needing a design doc, this means your proposal is nominally accepted, but needs to progress from the one-pager GitHub Issue into a fleshed-out design.

This design doc can start as e.g. a Google Doc or Quip Doc, but needs to eventually make its way into a pull request to add it to the project's Docusaurus.

When writing your design doc, consider following this standardized design doc template.

Resolution

A proposal Issue will be closed when no further discussion is needed. This occurs after one of the following

  • Acceptance, rejection, or withdrawal of the Issue
  • Acceptance of a requested design doc

Conclusion

Please direct process-related questions to the #governance-tsc Slack channel.

← PreviousCodeowners Workflow →