This issue captures key discussion points from the BackstageCon panel on the plugins ecosystem along with potential next steps and ongoing work, and aims to consolidate the feedback from the panel into a single place before breaking out more concrete follow-up issues if needed.
Standardized plugin/repo templates
This was brought up a couple of times during the panel and there was agreement that this would greatly benefit plugin developers with their internal plugin development. More discussions around this in #1512. Next steps could include breaking this effort into smaller, more actionable tasks.
Dedicated documentation/discovery experience for community plugins
Many plugins only expose information via README files. A dedicated documentation site for community plugins featuring supported Backstage versions, health/maintenance status, ownership metadata
and usage examples was suggested.
This previous PoC may be a useful starting point: #3491
First-time contributor experience
Plugin Architecture and knowing "where things go" was identified as a major barrier for first time contributors.
A next step could be to explore skills as a way of guiding new time contributors to build plugins, similar to the bui-to-mui migration skill.
Plugin Handoff and Archival Process
We already have an archival process in place: https://github.com/backstage/community-plugins/blob/main/docs/plugin-maintainers-guide.md#archiving-a-plugin as well as a process for plugin owners to step down if they are unable to continue maintaining their plugins.
The process for identifying unmaintained plugins and communicating that to the plugin owners is being discussed here: #8982.
This issue captures key discussion points from the BackstageCon panel on the plugins ecosystem along with potential next steps and ongoing work, and aims to consolidate the feedback from the panel into a single place before breaking out more concrete follow-up issues if needed.
Standardized plugin/repo templates
This was brought up a couple of times during the panel and there was agreement that this would greatly benefit plugin developers with their internal plugin development. More discussions around this in #1512. Next steps could include breaking this effort into smaller, more actionable tasks.
Dedicated documentation/discovery experience for community plugins
Many plugins only expose information via README files. A dedicated documentation site for community plugins featuring supported Backstage versions, health/maintenance status, ownership metadata
and usage examples was suggested.
This previous PoC may be a useful starting point: #3491
First-time contributor experience
Plugin Architecture and knowing "where things go" was identified as a major barrier for first time contributors.
A next step could be to explore skills as a way of guiding new time contributors to build plugins, similar to the bui-to-mui migration skill.
Plugin Handoff and Archival Process
We already have an archival process in place: https://github.com/backstage/community-plugins/blob/main/docs/plugin-maintainers-guide.md#archiving-a-plugin as well as a process for plugin owners to step down if they are unable to continue maintaining their plugins.
The process for identifying unmaintained plugins and communicating that to the plugin owners is being discussed here: #8982.