💬 RFC: Management of community plugins list on microsite

[dragonfleas]

🔖 Need

Currently, there's not a solution in place for vetting whether or not community plugins have been abandoned, and/or are no longer maintained.

🎉 Proposal

Primary Behavior

My initial proposal is something to the effect of a flag button to the side of each plugin in the list on the microsite that does the following:

• Sends an email or notification to the core development team OR opens a GitHub issue
• Allows a user to write in a reasoning for the flag press
• Ensure the user means to submit the flag

Optional Behavior

• Provides a form popover with detailed reasoning
• Vets the user somehow (Probably not possible?)

Reference example image

Relevant issue:

backstage/backstage#25715

〽️ Alternatives

• Explicitly only provide a GitHub issue template for reporting unmaintained/inactive plugins
  • Downsides:
    • Users who are new to backstage who go to the landing page and click "plugins" and see a plugin is dead won't know to go to GitHub to report it.
  • Upsides:
    • Easiest to implement
    • Single source of truth & location for reporting issues
• Create a backstage-plugins.io microsite that's hosted @ the community plugins repository
  • Downsides:
    • Heavy lift
    • Requires new development
    • Breaking change for current microsite
  • Upsides:
    • Better UX due to repositories linking to their own respective sites
    • Better separation of concerns
    • More closely aligns the repositories data with their business context

❌ Risks

As plugin development accelerates, this will scale into an unwieldy list that many people who visit the micro site will see as a graveyard, specifically the plugins page. This will likely cause decrease in conversions when someone visits the backstage website and looks for support for their various technology stacks. It's often the case that users will not adopt software that has no, or unsupported, integrations with whatever technology they are using.

👀 Have you spent some time to check if this RFC has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[benjdlambert]

@dragonfleas wanted to move this to the community-plugins repo to get some feedback on this from @backstage/community-plugins-maintainers as this applies to both plugins in this repo as well as 3rd party published ones too 🙏

[awanlin]

Just wanted to note that the 2nd alternative - "Create a backstage-plugins.io microsite that's hosted @ the community plugins repository" - assumes all the plugins are in the Community Plugins repo this is not correct. Many plugins are hosted by the author, for examples those by Roadie and PagerDuty.

[dragonfleas]

Just wanted to note that the 2nd alternative - "Create a backstage-plugins.io microsite that's hosted @ the community plugins repository" - assumes all the plugins are in the Community Plugins repo this is not correct. Many plugins are hosted by the author, for examples those by Roadie and PagerDuty.

I thought it was implied that this option would come with moving the /data/plugins directory of yaml files there/here. As well as notifying 3rd party repo managed plugin teams that the location for their plugin grid item had changed. The goal in my mind, was more to consolidate all information in the community-plugins repository, instead of fragmenting it across two repositories. As a new user, my first instinct was to assume that the plugin data for the micro site was sourced from the community plugins repository.

[awanlin]

That's fair, I did not infer that these steps were implied. I was just trying to highlight an incorrect assumption and make sure that we consider self hosted plugins as part of this.

I personally like the 2nd alternative as it would open up other possibilities that have been asked for like tagging, better filtering, inline docs, reviews, etc. Trying to have this as part of a Docusaurus site is a bit limiting. BUT we also need to have Contributors who will help make this a reality and keep it maintained and this part has been a bit harder to find.

My personal thoughts on a plan of actions: first we create a GitHub issue template for being able to submit a plugin that's no longer maintained and this can be just linked in the header section of the Plugin Directory. If someone wants to add a button on each card that would link you to the template even better. From there anyone who's motivated can work on something better as proposed in the 2nd alternative.

[Parsifal-M]

Hey! 👋

Nice! I think also key here is what do we consider to be "no longer maintained" could it be "no updates after X period of time?"

I also think we could host something in terms of a plugins page from community-repo as mentioned and I think it would tie in well with a docs site for the plugins which I believe @BethGriggs mentioned in the discord not long ago!

👏

[dragonfleas]

I can say for certain, "Company who maintained the plugin and the platform it integrates with no longer existing" as being representative of at least one criteria, in the case of the plugin in the linked issue. 😛

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.