Backstage Community

The Framework Special Interest Group (SIG) is an open forum for discussing community-proposed enhancements to the Backstage core framework.

Scope of discussion includes:

• Frontend system
• Backend system
• Build tooling
• Software Catalog
• System Entity Model

The following Special Interest Groups are currently active in the Backstage community:

• sig-adoption
• sig-community-plugins
• sig-docs
• sig-framework
• sig-scaffolder

Real-world implementations and technical deep-dives are available through case studies and community blogs.

Case Studies

Learn how organizations have deployed Backstage:

• American Airlines: Exploring the 'Runway' developer experience.
• Expedia Group: Defining vision, success metrics, and building an MVP.
• Lunar Bank: Adopting Backstage within engineering teams.

Technical Blogs

Community members share technical guides and experiences, including:

• Implementation Guides: Writing plugins, building catalog providers, and implementing search collators.
• Organizational Insights: How companies like Brex, DAZN, and QuintoAndar integrate Backstage into their workflows.
• Best Practices: Lessons learned from open source, managing cloud costs, and maintaining documentation as code (TechDocs).

The Scaffolder Special Interest Group (SIG) focuses on the systems and components related to the Backstage Scaffolder. This includes:

• Backend Services: The core backend service and its related packages.
• Frontend: The user interface and related packages.
• APIs & Extensions: All relevant APIs and extension points.
• Template Kind: The Template resource kind used for scaffolding.
• Customizations: Community-driven Custom Field Extensions and Custom Actions.

The Adoption Special Interest Group (SIG) focuses on improving the entire Backstage adoption journey. This includes:

• Product Features: Enhancements to the Backstage software itself.
• Content & Education: Improving documentation, tutorials, and general content.
• The Adoption Lifecycle: Covering discovery, awareness, Proof of Concepts (PoCs), evaluation, deployment, and internal evangelization.

The SIG is an open space for discussing community-proposed enhancements to make it easier for organizations to adopt Backstage.

A 'Goalie' is a rotating role assigned to a team member (typically on a weekly basis) responsible for triaging, responding to, or assigning issues.

Pros:

• Provides a clear owner for the triage process.
• Ensures all team members are involved in the work.
• Allows the rest of the team to focus on deep work without triage interruptions.

Cons:

• Can be a daunting amount of work for the individual.
• May reduce spontaneous collaboration during the triage process.

Issues in the project are organized into project areas using GitHub labels with the format area:<name>.

• Multi-area issues: If an issue spans multiple areas, apply multiple area labels (e.g., area:catalog and area:auth).
• Preventing stale closure: A stale bot is used to prune inactive issues. To prevent an issue from being marked as stale and closed, add the will-fix label.
• Assignment: While not strictly required, assigning issues to specific maintainers can help track responsiveness.

For complicated pull requests, instead of asynchronous review, use a pair or mob review strategy. This involves a scheduled or ad-hoc meeting where the team walks through the code together.

• Internal PRs: The author typically explains the changes to the group.
• External PRs: Anyone can drive the walkthrough.

This method is often a time-saver for complex logic compared to traditional asynchronous review cycles.

Project areas are permanent organizational structures within Backstage. When determining if a component should be a project area, consider the following guidelines:

• Scope: An area should not be trivially small, but it should also not be so large that it exceeds the capacity of a single team to manage.
• Permanence: Project areas are intended to be permanent. Temporary working groups or task forces do not constitute project areas.
• Ownership: A project area requires active leadership. If no one is driving the area, it will not be established as a project area.