Design v1 of the Plugin Registry site

[zanete]

Why: sub of #633
What: Design for MVP of plugin registry

Scope of work:

• Spike: What's possible to suck from npm (e.g. downloads, stars etc)
• Design and link to figma
• • Place for disclaimer (copy tbc)
• • Header with links to IF and "How to submit a plugin"
• • Search box
• • A plugin card - [Name of the plugin, summary (one sentence), Tags, URLs(npm, repo or website), badge for official plugins, version, stats tbc
• Review and feedback on the design
• Provide a sample json file to show the format in which data should be prepared (for Prepare the initial data for plugin registry #685 )

[zanete]

FYI @osamajandali apparently, according to @narekhovhannisyan , https://github.com/NodeSecure/npm-registry-sdk will give you all the stats. This is in reference to the first AC on this issue.

[zanete]

@jmcook1186 here's a good place for you to let @osamajandali know about the repo you created #614 :)

[jmcook1186]

hi @osamajandali - just to let you know this repo exists and should be the home for plugin registry website source code eventually.
https://github.com/Green-Software-Foundation/if-plugin-website

[zanete]

Capturing the status in the weekly call: this is yet to be started as @osamajandali was delayed in returning from his vacation

[osamajandali]

@zanete Here is the design:
https://www.figma.com/proto/kFxZ110Mo2n5O8kuwAH8nk/GSF---Plugin-Register?page-id=1%3A2076&type=design&node-id=1-2805&viewport=471%2C687%2C0.18&t=GRZ4eMkI4USSiDu0-1&scaling=scale-down-width&mode=design

[zanete]

@osamajandali looking really awesome!! 🙏
@jmcook1186 @pazbardanl @jawache please have a look at the desing and add your thoughts / feedback 🙏

[jawache]

Wow looks great @osamajandali!

[zanete]

@jawache @jmcook1186 (cc @osamajandali ) I love the design, and all is super cool, only unclear if the "official plugin" badge should be as explicitly stating that it's an official plugin or something more subtle to show endorsement that would also allow highlighting external plugins?
Regardless, feels like we're good to go with the next stage that is preparing the json structure so that we can prepare data (and move on with implementation as part of #684)

[jmcook1186]

Love the design - really no criticism of how the page looks at all.

I will have some comments about the content of the cards - we haven't provided any guidance on that so far, but I anticipate each card containing:

• plugin name
• publisher name
• short description of the plugin
• link to npm/github
• link to issue form that was filled out when PR to add plugin was raised
• a badge (which probably will not contain the text GSF official plugin - this might not exist on launch, but we will want to add badges later)

[zanete]

@jmcook1186 noted, we've seen that we are missing publisher name which we'll add and we'll remove the words "official plugin" form the badge and keep it as a tooltip where the copy can be updated to match what it will be.

Can we clarify why we need link to issue form that was filled out when PR to add plugin was raised on this website? is this something that the public should have access to?

[jmcook1186]

Yes- this still needs to be confirmed with @jawache but I'm anticipating that users will be able to raise PRs against the registry repository to add plugins to the site. When they do so, they will have to fill out a simple issue form that asks them some basic questions about their plugin:

• what does your plugin do?
• what are the parameters and return values?
• have you provided a README with usage instructions
• have you provided a working manifest file that invoked your plugin
• have your provided unit tests covering your plugin
• please provide citations or other supporting material that can be used to assess your plugin
  etc

The answers accelerate the core team's ability to judge the PR quickly and do some minimal QA, but we also want visitors to the site to be able to click from the card on the site to the author's responses on the issue form as a shortcut for the community to do their own due diligence before installing the plugins.

[jawache]

Hey so @jmcook1186 I was thinking for this MVP we match the functionality of the gulp registry.

Each card is linked to one place, either the npm or GitHub if there is no npm link.

Its a good idea to insist the plugins report some common info, but I'd argue they have to list that clearly on the plugin landing page in npm/gh, rather than document it in the PR itself. We can just check their npm landing page to make sure it's.there as we expect.

I'm also ok with the process of submitting being that they edit the JSON file that powers the registry, add their info, have PR check boxes like you say but the actual answers should be on their plugin landing page. We review to make sure they match our requirements, then all we have to do is accept the PR and it will be added to the registry.

[jmcook1186]

sure - I just want a user to be able to tell at a glance whether a plugin meets our basic set of requirements. The form can literally just be a set of checkboxes with the actual information being in the GH repo or npm page.

I also anticipated a PR being a new entry to the json file.

[jawache]

In that case not sure if there is a ticket for this, but as well as the plugin registry we'll also need some docs to explain the process and minimum requirements for the plugin (docs/landing page etc...)

To make life easier we can add it to if-docs, or create a page in our Notion wiki, whatever is easiest.

[zanete]

@jawache - we have #634 for documenting etc. In the design there are multiple links supported, so we can add all links that are needed.
@jmcook1186 I get why we would want extra info to accommodate the PR submission internally, I but I'm not sure I follow why that is needed for the wider public. Shouldn't we encourage them to put all publicly relevant info in their readmes?

[zanete]

Json referred to the other task #684