Simplify plugin and theme contribution process

[PhrozenByte]

See #33 (comment)

Maybe we should think about how we want to manage plugins and themes in the future. Obviously I don't have enough time to actually do a code review for plugins. The idea behind this review process was to ensure a basic level of quality and to prevent malicious plugins. However, I feel like that we can't really achieve this anyway. Developers can update their plugins at any time. Furthermore there's our Wiki with yet another list of themes and plugins. So maybe we should abolish this "review required" process and switch to a much simpler process? The question is: How? I feel like the way we present plugins and themes on picocms.org right now isn't really suitable for this, is it?

Feedback is highly appreciated! ❤️

CC @mayamcdougall

[mayamcdougall]

Sorry, this turned into a bit of a brain dump (cough More HR's make it more readable, right?? cough). 😅

I agree that the current solution isn't really ideal, but I'm not really sure how we'd solve it at present.

I feel like some level of review is always going to be required no mater what.

Even if we over-engineered a submission page that "validated" everything for us, generated perfect YML from some text fields, checked and/or cropped image dimensions, validated code, etc etc, there would still need to be a final review of user submitted content. Otherwise we'll check the themes page some day, realize it's just a bunch of explicit images, and wonder "How long has it been like this? 😨".

And for the plugins page, I guess they'd all inject hidden ads for pills or something. 😂
(On a side note, I had to fix this on an acquaintance's Wordpress a while back. The clever malware only displayed its spam if the Referrer URL was from a search engine, so it went completely unnoticed for months on a low-traffic website. 🤦🏻‍♀️)

While I'd like to think I'm just being paranoid, my faith in people is awful low. It could just take one troll to create an endless stream of junk content, and then moderating it would be more effort than the current submission process.

---

And plugins make me even more nervous about the idea. Like, I agree 100% with your past sentiment that having plugins on the Pico website implies that we're endorsing them.

But what could we do? Put a big red disclaimer on the top of the page that says "These Plugins are User Submitted content and are not independently verified by PicoCMS"? I feel like that would only attract abusers.

I feel like bigger projects or companies would simply solve this by inviting users to "Flag" malicious content, but the Pico community is far too small to work like that. Maybe some day if we get a couple hundred more themes and plugins submitted. 😉

At least with the Wiki, most people hopefully understand that a Wiki is user-generated and that they should proceed with a little caution.

I'm rambling at this point, but I don't really have a good solution for this. 🤔

And to be honest, I don't usually review the theme code at all lately. I used to at least try to run them on a testing instance of Pico to make sure they weren't completely broken, but it got kind of tedious. 😒

And even if I reviewed the relatively safe Twig code, I've got no real way to check that some javascript they're pulling in isn't going to start secretly mining Bitcoin (or indeed, like you said, that they don't just modify it later on to be malicious).

---

Man, this is getting more depressing the more I think about it. 😑

Maybe we should have a warning that not all content is vetted. 😩

I feel like the current submission process does act as a good social barrier though. Not as many people would bother submitting malicious things or spam knowing that someone will look at it. Also, the extra effort of submitting a PR itself is a good barrier. If we see any just-opened GitHub accounts, we've got a good indication that something might need more investigating.

But ultimately, the task of verifying everything in perpetuity (woo! big words!) is definitely impossible, so there needs to be a middle ground.

---

Maybe the solution is to address another issue, the Plugins page itself.

I love the theme gallery, and feel it's absolutely necessary for Pico because it shows users, visually, what Pico can accomplish. I can't count the number of times I've clicked away from a project's website because they couldn't show pictures of their software in action. Pico's gallery could always be better with more themes, but at least it's something...

But the Plugins "Gallery" is just garbage. It should never have used the gallery layout. It's hard to read and impossible to actually get any useful information from. There is exactly one plugin with a thumbnail, and it was there from the start. 🤦🏻‍♀️

So... what if the Plugins page... was the Wiki? Either embedded (yuck 🤮), a link (better), or as a static copy of the Wiki text that is (hopefully) automatically generated on update. 🤔

I feel like this idea has some potential, but I'm not sure exactly how you'd want to accomplish it. Maybe there's a way to hook into the wiki updates and run a script that updates the site text to match? Or maybe it'd be better to have some Javascript fetch the wiki contents when the page loads and avoid the need for automation all together?

What are your thoughts on that idea? This would essentially remove "Plugin Submissions" as a thing altogether and just source them from the wiki. (While of course formatting the text to also look nice on the site).

Also, a small discrepancy I've noticed on the site: The Themes page is clearly titled Community Themes, while the Plugins page says Pico Plugins, not something like Community Plugins which would better emphasize that most of them are not maintained by PicoCMS.

---

Okay, done. Just read the last block, it's the important one. 🤦🏻‍♀️😅

[mayamcdougall]

Rough Idea of how the current Wiki content looks with the site's theme. 😉

[github-actions]

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

[PhrozenByte]

Sorry for the late response... Time's extremely limited lately 😒

I don't think that it's even possible to fully automate the submission process with GitHub Pages. I was rather thinking about simplifying it by limiting the review process to a simple "does it work?" approach (just like you do for themes). I don't think that code reviews are feasible right now; thinking about it I'm not even sure whether they serve any real purpose, since we can't prevent malicious plugins and themes anyway. We shouldn't claim something else. However, our website suggests something else right now. This is bad.

Another thing to keep in mind is that with Wiki + Website users might get a wrong impression about how many plugins and themes we have. There should be a single place to get plugins and themes. This can either be our website, or our Wiki, not both. I like your idea with switching to a simple list for plugins (mostly taken from our Wiki, maybe with some additional grouping). The gallery YAML is way to complex. We might switch to a "mixed" approach for themes, too - having the gallery with screenshots and reviewed themes on top, and a list of additional themes (those currently in our Wiki only) on the bottom.

The problem is: Thinking about it I'm not even sure whether I have enough time to even perform simple "does it work?" tests. Since there's no code review required anymore, I'm pretty sure that any experienced Pico user (like yourself 😉 ) can do this. Can you imagine taking responsibility for any submissions, both plugins and themes?

This would allow us to simply the submission process to something we can actually handle. If we can't even support this, we might remove the pages from our website altogether and add links to the Wiki instead 😒

[github-actions]

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

[github-actions]

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

[PhrozenByte]

So, what do you think @mayamcdougall?

[mayamcdougall]

Sorry, just been a little busy.

The plugin submission process should definitely change, and should probably just go away. I agree that code review is just something that realistically isn't going to happen, for either plugins or themes. And unless we were to somehow recruit a bunch of people overnight, it's probably never going to happen.

I don't really feel confident in reviewing them myself. A lot of the plugins that we get submitted are very niche, and specific to that developer's circumstance (eg, "I made this for myself, and I'm throwing it out there in case others find it useful"). Then there's the fact that plugins, tend not to be "plug-and-play", but require additional setup to make use of. I just don't think it's something I could really commit to. Both for the added complexity and the time.

That being said, with themes, the submission process is easy enough that I don't mind it. It's not hard to fix a few lines of YML for someone when they want to merge it. Even if we didn't make any changes to the current Themes setup, I'd be okay managing it, the way it is now, for the foreseeable future.

Also, as I said in my last comment, I really think having the themes displayed visually is a requirement for the site.

(In fact, if I had a ton of free time, I'd love to port a bunch more simple themes and fill out the gallery. The last one I did, Stellar was pretty fun. 😅 I think I got to "think like a programmer" this time around and really deep-dive on how to best leverage Pico's capabilities. And I still have things I wanted to add to it...)

---

So, I think where I'm at with everything is this:

• For now, Themes can stay a gallery, with a submission process*.
• Plugins should be a list. It just makes more sense that way.
• Plugin "submissions" aren't really viable, so either we:
  • a) Instruct people to just add them to the wiki, then copy the wiki content ourselves** or
  • b) Instruct people to edit the Plugin page itself with their submission and make a PR of that.
• And of course, add a disclaimer to the Plugin page that content is user-submitted and not endorsed by the project.

* If we feel it's necessary, we can also add a disclaimer to the Themes page that content is user-submitted. However, every theme just links to its author's GitHub page, so I feel like it's already somewhat implied that "Hey, these aren't coming from us. Use your own discretion, you've been taken somewhere else on the Internet after all." 😉

** Plugin submissions and wiki edits are so infrequent, that this wouldn't be a huge undertaking even without automation. That being said, the current state of the wiki page is a little... cluttered, to say the least. I wouldn't be sure where to even begin with sorting it out.

I'm sure there's also plenty of out-of-date content that could be removed, but I also wouldn't really feel comfortable doing it. There's a few too many items with strikethroughs and multiple forks that should probably be sorted out. 😩

It would definitely need cleaning up, but it could be the basis for a new plugins page.

(Also, I was thinking of how we could break up the list a little and thought "Oh, alphabetically!"... right, so the entire list will just appear under the letter "P" 🤦🏻‍♀️)

---

If you like these ideas, I can make the changes on the website sometime (the plugins/themes changes, and also changes to the "contributing" stuff). The biggest struggle for me would be the Plugins list itself.

Let me know if you have some ideas of how you'd want it organized, and what should stay or go.

Because I don't think it can all stay... but I also don't want to hurt any feelings by cutting things just because they might look unmaintained. 🤔😔

(And of course, I'll do the work on my own fork that way we can get the final product polished before making the switch for real.)