RSS

How to Participate in the Radius Design Process

By Reshma Abdul Rahim |

If you are interested in collaborating with the community to influence, design, and build the newest features in Radius, then you’ve come to the right place. From upvoting roadmap items to authoring and submitting design proposals, this blog post will walk you through all the ways you can participate in the Radius design process. Radius enables developers and platform engineers who support them to collaborate on delivering and managing cloud-native applications that follow corporate best practices for cost, operations, and security by default. You can help realize this vision by providing your input on the Radius roadmap and by engaging in the community design process to improve Radius features.

Help shape the Radius feature roadmap

The Radius roadmap reflects the current feature plan for the project. After every release, the roadmap is refined to reflect the latest input from the Radius community. You can contribute to the roadmap in the following ways:

  • Provide feedback to influence roadmap decisions by commenting on and upvoting existing items

  • Propose a feature for the roadmap. To do so, submit a new feature request. The Radius maintainers regularly review all feature requests and determine which to add to the roadmap.

Bookmark the Radius roadmap to stay up to date.

Influence feature designs

All design proposals, enhancements and architectural decisions for Radius are documented in the design notes repository. By providing this consolidated record of all major decisions and changes, the Radius maintainers hope to bring clarity and transparency to the Radius community. Once a feature is accepted into the Radius roadmap, any contributor can submit a design proposal to the design notes repository.

  • If you are interested in proposing a design:

    • Confirm there is a GitHub Issue describing the feature in the Radius repository. If not, submit a new feature request.

    • Feature Specification proposal: Write a feature specification following this template and submit a PR. This document covers the what and why of a feature. It includes the problem statement, personas, user experience and impact of the feature on the Radius community. For example, the Feature Specification for Gitops support in Radius covers the what and why of Radius integration with GitOps tools. The feature specification document precedes the technical design proposal.

    • Technical Design proposal: Once the feature specification is approved, create a design proposal document following the template and submit a PR. This document covers the how, i.e. the technical design details of the feature, including architecture, design decisions, implementation details, and testing strategy. The technical design proposal precedes implementation. For example, the Technical Design for supporting any Terraform providers covers the in-depth design and implementation details of supporting any Terraform provider in Radius.

  • If you are interested in contributing to existing designs, you can do so by reviewing the in-progress design proposals. You can provide feedback and suggestions by commenting directly on the proposals.

These documents are reviewed by the Radius maintainers and community members within a week of submission. Reviewers provide feedback and suggestions to ensure features are well-designed and meet user requirements. Feature specifications and technical designs must be approved by a Radius maintainer before they can be merged into the design notes repository (and before implementation can begin). If you have questions or need help with a design proposal, reach out in the Designs channel in Discord.

Learn more and contribute

We’re looking for people to join us! To get started with Radius today, please see: