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.

Tracking proposals

Proposals are tracked as GitHub Issues, using the following labels

• type: proposal for all proposals
• tsc for proposals desiring TSC consideration

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.

Receive feedback

The project maintainers (or the TSC, if you applied the tsc label) will discuss the proposal and make comments on the Issue. One of four outcomes will be communicated via labels

• status: accepted proposal was accepted
• status: rejected proposal was rejected
• status: withdrawn proposal was withdrawn by the author
• status: needs design doc proposal needs a design document

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.

• Example design doc: Scaling Orc8r Subscribers Codepath
• Example design doc PR: APN Refactoring