svelte-society/sveltesociety.dev

Externalize Components/Tooling/Templates storage

MacFJA opened this issue · 2 comments

Right now the process of adding a component/tooling/template is a bit of a hassle:

  • Creator need to fork the project
  • Creator need add the data in one of 3 JSON files
  • Creator have to ensure that all (mandatory) fields are filled
  • Creator have to ensure that fields are correctly set (typos, no unnecessary new tags, categories, etc.)
  • Creator have to open a PR
  • Maintainer+Community have to validate that all (mandatory) fields are filled
  • Maintainer+Community have to validate that all fields are correctly set
  • Maintainer have to merge PR
  • Maintainer have to create a PR from staging to main
  • Maintainer have to merge PR

And not data can be dynamic (mainly repository stars)


Maybe the data should be saved in a "database" ℹ️ (so no more PR) and a form to submit a new component/tooling/template (with data validation during submission).
It would reduce the process to:

  • Creator fill the form (which have validation)
  • Creator submit the form
  • Maintainer review the submission
  • Maintainer validate the submission

It will offer a way to update dynamic data without the need to do a commit. (By running a script that will update the database directly or by fetching the data directly when reading the databaseℹ️)

It can maybe also provided so more advanced search abilities


The drawback is that we lose the community aspect of validation, and the communication between the Creator and Maintainer/Community

We'd also have to code up email notifications to let maintainers know when there's something to review and the contributor to know when there's updates on their submission. Ideally we'd have some way to ask question or leave comments. It would add significant complexity to the application, so while it'd be a nicer workflow, I wonder if it's worth it. Especially with #108 which already addresses the biggest pain points

  • Creator have to ensure that all (mandatory) fields are filled
  • Creator have to ensure that fields are correctly set (typos, no unnecessary new tags, categories, etc.)

Have you seen #108? It addresses this

  • Creator need to fork the project
  • Creator need add the data in one of 3 JSON files
  • Creator have to open a PR

Did you know you can edit files directly in the GitHub UI? It will automatically fork the repo as needed and is pretty user-friendly

  • Maintainer have to create a PR from staging to main
  • Maintainer have to merge PR

Personally I'd drop these steps and just deploy directly to main as I think it just creates extra overhead #12 (comment), but that's sort of a separate discussion

Have you seen #108?

My bad! I didn't do my job correctly and search for similar issue

Did you know you can edit files directly in the GitHub UI? It will automatically fork the repo as needed and is pretty user-friendly

I know, but still I found that the need of forking the project can be somewhat a barrier for some people (and yes, I know, ours users are dev 😅 )


As it's a bit of a duplicate of #108 I will close it for now.
If the idea is still relevant, the issue can be reopen