Plugin Speedrun

[Keyrxng]

Recently it's came to light that setting up the kernel and running plugins is not straightforward and new contributors even core team are having issues with it so I'm suggesting we do more than just improve docs or #171. Both will help but not as much as my suggestions below in my opinion and I'll explain why.

Building a UbiquityOS plugin in 60 mins or less

Someone records themselves speedrunning the creation of a very simple plugin, maybe even just the current hello-world that exists in plugin-template that I wrote before.

• From making the app
• To having the kernel respond to the plugin and vice versa

Bonus:

• these go down better if we actually hear the dev as they are speedrunning
• even better if we can see the dev but obv not necessary at all

"SpeedRun UbiquityOS"

https://speedrunethereum.com/

We make a set of "challenges" that ease a contributor into the eco-system piece-by-piece.

• For the XP system, this is a great way to enforce a promotion from Level 0 to Level 1. We guarantee they have the basics down. A lot of projects do this, cartesi is one that comes to mind I'm sure does it.
• Contributions then we'd expect to be of higher quality immediately and us as reviewers spend less time educating re: infra, processes, expectations, standards, etc.

Why?

I never spent a huge amount of time in "tutorial-hell" but I've watched a few things like this and it works wonders to be able to see it live as it happens. It's even better to understand the developer' intentions so if we can hear them tell us why they are doing x, y and z as they do it the viewer gets a much better idea of when/why/where they'd also need to do the same thing.

---

Maybe creating two of these videos (if chosen), one for the simple single plugin and the second with multiple plugins running in parallel locally or something? Something a little more advanced anyway so that we can get further into the quirks

[0x4007]

I don't like this media forward approach because this will quickly get out of date. Similar to readmes.

It's an easy and nice to have asset but I would not like to invest much in this direction.

We should have a solution that self improves.

[Keyrxng]

We should have a solution that self improves.

Should we go hard on creating automated docs via a workflow then and annotate everything in sight and host it on gitpages or gitbooks or something?

That's the only thing I can think of that can stay up to date in real-time with our codebases

[0x4007]

Chat bot and it updating readme.md on every merged pull is enough I think.

[Keyrxng]

Oh right I thought when you said docs you meant real docs with their own page a contributor can visit like https://supabase.com/docs but for UbiquityOS, why aren't we doing that out of curiosity, the sync issue?

updating readme.md on every merged pull is enough I think

Is this an AI task or are we enforcing this as a rule for PRs?

[0x4007]

Docs page might be appropriate only on finalized products. Lots of unnecessary busywork otherwise.

AI task

[gentlementlegen]

With the SDK it takes 5 minutes to set up + you can run locally without needed the Kernel, at least that's what I do to dev right now. Problem is that very few plugins use the SDK at the moment.

[zugdev]

Ideally one day running the kernel will be as easy as yarn start.

[ubiquity-os-beta[bot]]

! Error: HttpError: Resource not accessible by integration - https://docs.github.com/rest/issues/comments#create-an-issue-comment

[zugdev]

test comment

[ubiquity-os-beta[bot]]

! Error: HttpError: Resource not accessible by integration - https://docs.github.com/rest/issues/comments#create-an-issue-comment

[zugdev]

interesting...

[gentlementlegen]

Should be fixed by https://github.com/ubiquity-os-marketplace/daemon-disqualifier/pull/42

[ubiquity-os-beta[bot]]

! Error: HttpError: Resource not accessible by integration - https://docs.github.com/rest/issues/comments#create-an-issue-comment