Simplify plugin and theme contribution process #45
Comments
|
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. 😂 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 Okay, done. Just read the last block, it's the important one. 🤦🏻♀️😅 |
|
Rough Idea of how the current Wiki content looks with the site's theme. 😉
|
This comment has been minimized.
This comment has been minimized.
|
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 😒 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
So, what do you think @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:
* 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 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.) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
This is probably to most long drawn-out dicussion I've ever had 🙈 My bad, sorry! 😒
Full ACK. Plugins: A "merge without any checks" approach for plugins is the only really viable solution then I guess. I totally agree that a big disclaimer about plugins being user-submitted and non-curated is a requirement then. Personally I'd rather go for the "pull request" approach than copying the wiki (basically I'd prefer to see the wiki vanish). I don't think that a plain list of plugins is a good idea, this might get a bit overwhelming (just look at the wiki right now 🙈). We should at least group plugins by some basic (!) categories. Some short description (just a few words one grasps by just looking at the plugin's About duplicate and deprecated plugins: Since checking all plugins isn't realistic, we might simply append duplicate plugins to the recommended ones, just as an alternative. This won't require us to actually test the plugins... They all worked at some point, otherwise they wouldn't be in the wiki I guess. Most old plugins should still work due to Themes: Agreed. I also agree that a gallery is very reasonable for themes. However, does this mean that you want to create a gallery entry for every single theme in the wiki? This looks like a lot of work to me. Don't get me wrong, I'd definitely love to see this happen 👍 Just to make sure we don't talk at cross-purposes here.
Awesome! ❤️ I promise to answer faster now 🙈 |
|
No worries. I know how it gets. I've been spending all my free time lately working on my home media server, and barely any time on the app I'm supposed to be programming. 😒 Yeah, I liked the PR idea best too. And, I mean, if people are already expected to read about a somewhat complicated Submission process for the current gallery, things can only get easier for them. I agree that a plain text list of plugins might be overwhelming or get out of hand like the current wiki. I'm not set that it needs to be just plain text on a page, just that it should be overall text-based. There's definitely room to have decent formatting and/or framework around the idea. Some kind of a list, perhaps with categories and/or the ability to filter the list to show less entries. I'll think about it a little and see if I can come up with a UX that would work well for it. Also, if your end goal is to get rid of the wiki, I could probably bring myself to make gallery entries for each theme. 😉 I know you were pointing that out as being an off-topic thing... but it's totally doable. Anyway, I'll look around and see if I can find any good ideas for a fancier list. |
|
Great, looking forward to your ideas 👍 😃 |
This comment has been minimized.
This comment has been minimized.
|
Since you seem to be online right now... Here's a progress update: Regular Hover Currently trying to dial in the position of the "Learn more" button (technically not a button, but it's styled like one). Perfectly centered on the thumbnail feels too high (pictured), and centered on the whole tile (thumbnail and label) is too low. I'm thinking I'm just going to have to pick a happy medium that isn't actually "centered". P= |
|
The Pico "Seal of Approval" and the Pico "Ribbon of Approval".
No actual plans to use either of these for anything, just brainstorming. In the end, it'll probably be something like a recommended star ⭐, because I don't want them to feel officially "endorsed" by Pico. I'm also having trouble deciding on a criteria for something being either |
|
Looks great so far! ❤️
As far as I understood @gelavat right, he was referring to a theme's usage resp. setup, i.e. whether one can simply copy it to the themes folder and regular content files work as expected. Some themes require plugins, some themes use multiple templates and require one to specify a |
|
Sounds like a pretty good criteria. I think for the most part it's just going to have to be a judgement call on each theme. I think some setup should be allowed as long as its basic. Config options or YAML parameters seem like they'd be okay as long as the ReadMe's are good. I mean, at the very least you have to select a theme in your config, so there's always some setup. What I've got in mind when I'm thinking about either Where as I've seen some themes that have options A, B, and C in their YAML, but in order to change X, Y, and Z you have to edit the Twig template. Those would definitely not qualify. (However, there could be some that would maybe meet the criteria with just a simple commit or two 🤔😉). |
|
Not nearly as flashy, but perhaps a more practical approach. 😉
Would probably want some kind of info button/hover next to the legend to better explain it... but considering it's all just hacked into the code inspector, I haven't done that yet, lol. |
|
Alright, so, a little bit of a status update here. The styles for the above design are just about done. Take a look here. Due to the way the original design was done, there were a lot of extra size-specific styles I had to implement. I've tested at the various resolutions, and everything seems good. The most complicated effect I implemented was a fade out gradient on the titles. If a title runs a little too long for the space available (either because it hits the edge of the tile or it hits the
This was a little overkill, but it was fun to implement (except for having to make it work at all resolutions). I've also added the rounded corners to all of the Fancybox image viewers. I had to use a slightly hacky workaround for images with a text blurb underneath them.
When I rounded the corners of the image viewer, it made any images with text blocks underneath them also rounded on bottom, which didn't look great. But I had no way in CSS to know if this text block followed the image. So, after working at it a bit and not finding a good solution, I simply moved the text block up 5px so it overlaps the rounded corners. 😅 I'm not happy about it, but it looks fine and is a lot simpler of a solution than, for example, modifying Fancybox to indicate with a class whether or not there will be a text block following it. So, the styles are done, but the big issue remaining is deciding what Themes should be tagged as either Here's more or less where I'm at with it. Looking for any input @PhrozenByte, and @gelavat if you're still interested in helping with this. Ready-to-go
Other Concerns
Code Free
Other Concerns
Any other thoughts on this project? I'd love to get it merged, but it's not quite there yet. I might separate and merge just the style bits if we don't get this finalized for a bit, since I think they're worth the update on their own. What you see right now in my personal fork above has everything tagged as I saw fit. I have some notes on why I didn't label some, so we could work with the ones that just barely didn't make it to get them fixed. You'll notice though, that everything tagged is tagged as both So that's some food for thought. (Separating this into one final block because it's kind of its own side rant) A A theme would have to meet a very high bar for this criteria, and as such, it would probably only be applied to my own themes right now. 🤦🏻♀️ And even then, I wouldn't feel confident doing that without some extra testing on them and some small updates. A I know I think a bit highly of myself here: I think my themes have some of the best documentation on ANY of them. And yet I'm still guilty of the "submit it and forget it" mindset. This wouldn't cut it for a If anyone else comes along in the meantime with some submissions they'd want to put that extra level of commitment into, I'd welcome the idea of labeling their work as I think we could really use it, and I think that would be the best fit for @gelavat's concerns as well. But it's just not something we have in the gallery at the moment. 🤷🏻♀️ |
|
At the moment, I'm leaning toward getting rid of |
|
Just wanna let you know that I'm currently on vacation and will answer immediately after my return. What I can say from a quick look: The styles look amazing, I love it! ❤️ |
|
Thanks, lol. No worries, and no rush. Enjoy your vacation. Talk to you about it soon. 😉 |
|
Here we go, sorry for the delay ✌️ As I said earlier, I really love the new design ❤️
I agree. They are just too similar. I furthermore assume that users won't really understand the difference. Users must understand flags at first glance.
It depends. Basically all more feature-rich themes require A very simple test for this is a "sample contents" test: If a theme shows Pico's sample contents (i.e. basic websites with just static content) without additional config, without plugins and without any issues in general, it's very likely a R2G theme (e.g. Clean Blog will fail this test).
R2G themes shouldn't require any additional config to work - except for Considering
Advanced features which require additional config (like contact forms) should be hidden by default and the theme should still pass the "sample contents" test if advanced features weren't enabled. See above. The same is true if a theme requires plugins to work: For the R2G flag the theme must pass the "sample contents" test without any of the required plugins installed. For example, some themes require a pagination plugin to work, otherwise they don't show any contents. Such a theme is no R2G theme.
What exactly do you mean by "went the extra mile"? A good documentation?
For a R2G flag we definitely need a quick "install & try" test, otherwise it would be impossible to flag themes. However, we won't test any of the advanced feature, nor check a theme's source code. This is still a huge diff effort-wise.
As soon as you think it's ready for merge we'll merge it 👍
I agree. This would be great to have (as suggested by @gelavat). However, I'm afraid that this isn't possible right now, because flagging just a single theme as featured feels a bit odd.
Some input from @gelavat would be great here 👍 |
|
I feel like by the end of your comment, you've accidentally made a good case for why The By "went the extra mile", I mean a theme who's developer has taken a lot of time to provide a good experience to the user. Good documentation would be a part of this, but also avoiding any other paper-cut like issues. They should really have looked at things from the user's perspective and tried to make things as user-friendly as possible. (So, the opposite of most of our "I made a thing and threw it over the wall into open source land in case someone finds it useful" themes 😂) In the end, this concept might apply more to a future, So, I think that's the direction I'm going to take. I'll combine your In general (with Most of the more design heavy themes are niche, one-page designs though. I guess in the future I'll have to go porting some more "pretty, but basic" designs that'll support Pico's |
I still believe that users won't really understand the difference. Can you estimate how many themes would be flagged with one flag only?
Hmm... Maybe we could lower this to a "shows the sample content's
I agree.
True.
I'd love to see this 👍 |
I've actually been thinking I should look into making some kind of "modal" pop-up that explains it. This would also help if we had more tags (
Not without going through them all again. 😅 I can say that it'll probably be a lot less than I have tagged right now.
I don't think that would help at all. It's usually more all-or-nothing. For the most part, a theme either completely conforms to Pico's "typical" implementation or it does its own thing. And in those cases, even if it technically "displayed" the contents of index.md, it would probably be amongst a broken mess of missing strings and other values that their own index.md should have provided. I actually think that the
Me too. If only I could find the time. 😣 😂 |
|
I merged the style changes for now. We can work out the tagging stuff going forward. I kind of want to sarcastically rename this issue something like "Redesign Galleries and tag themes with some sort of consistency... I guess." The original point of "Simplify plugin and theme contribution process" seems like it got forgotten pretty early on. 🤔😂 |
|
Since the Plugins have titles underneath them now too, I got curious about what the would happen if I just started jamming some more text into the Isotope items.
I'm not suggesting we do it this way... but I honestly expected it to break a lot more. I mean, these styles are horrible and hacky... but... it's not awful... Maybe 2x2? I wanted to find a new javascript bit for this, but for the time being... I might actually be able to make a "list" out of Isotope. 🤔 At least as a temporary measure, would something like this be an improvement? I could make a serious attempt at it if you're interested. Maybe add in a little flair... |
Ok, so maybe for a later
Ok, then let's do it this way 👍
❤️
Go ahead 👍
Definitely an improvement (a rather big one tbh 🙈)! 👍 I really like the direction you're going here, looking forward to it |
|
Hi all. I appreciate your comments and concerns about all this subject! First I will answer some questions:
Personally I think yes. The main thing for me that has to be correct is the readme.md file. It can be as complicated as it wants for that theme, no problems as long as by following the "Installation" section of the readme.md, we come up with a working theme. So basically I would say that a theme is R2G as soon as someone has tested it successfully, and that all images and everything works fine.
Personally I think that having the CF and R2G is too much of details. I would stick with just R2G, it is enough I think. It is really what the user wants in my opinion.
I also agree that the theme needs to be ready with config.yml to be R2G flagged. That is really important because new users will always get the latest Pico version, which is using this. So config.php style themes would not be R2G as it wouldn't be possible to install them with the current version.
I think that as long as the documentation, hence the "Customization" section of the readme.md file, is well done and explains how to set your own POST or whatever information to be able to set it up properly, then it is fine and R2G. The aim is that this form needs to be usable by the user. If it is there, then it means that he can set it up properly, even though it needs some more technical knowledge, this doesn't matter, he will be able to figure this out through the doc.
On this I do not totally agree. Personally I would see that this is still an R2G theme, as long as in the doc it is written what plugin to install and in the right order of the "Installation" section of the readme.md file. E.g.:
-- Regarding the "Featured" flag, I think that Maya is probably right, it is maybe not really needed. It would discriminate the other themes, and hence it is not so fair. I am not absolutely willing to have this flag, but the best looking ones could still be having this "Featured" flag if it seems convenient. For me it doesn't matter in the end if it doesn't exist. But Maya's idea of the R2G flag seems very good to me, congratulations Maya! I like this idea. It will really do what I need I think. So to summarize, for me the R2G flag should be assigned to any theme that has the "Installation" section and "Customization" section fully described in the readme.md file, in a good and clear manner, whatever complexity it takes to install it or customize it., and tested successfully. Question for me: what is the "sample-contents", I didn't get what it is really? Thanks. |
The sample contents that display when you load Pico without a
@PhrozenByte, what are your thoughts on this? Personally, I think labeling them is good enough and that they don't need to be brought to the top of the list. Maybe if "Featured" themes became a thing, they could be at the top, but even then I think I'm leaning toward keeping it alphabetical for "fairness". If you also think they belong at the top, I could probably make it happen by iterating over the gallery items twice (once for My current plan is just to have a "Ready-to-go" category along the top that you could filter by. |
Maybe an "either or"? It's either as simple as changing the @gelavat: We might need some help here, since we both kinda suffer from tunnel vision here 😉
Just to make this clear: One can still install themes written for Pico 0.X and Pico 1.0 (i.e. with
What Maya said. Plus: Check Pico's
I'm fine with both solutions. Your choice 👍 If you rather prefer not to change the order, how about making the "Ready-to-go"-category more visible? Another thing: Maybe we should also add a "Pico CMS for Nextcloud" tag for themes that work with Nextcloud. A lot of themes have issues due to Nextcloud's stricter handling of external resources... |
|
Surprise merge! #50 (lol) Haven't done anything toward getting themes tagged yet. That's still on my todo list. We do now have tagging support on Plugins as well though. Are there any that should be tagged? (Perhaps "Official" if there are any you think you'd want to endorse). (Edit: I forgot there's already an "Official" category, so I guess I meant, would you like to see them tagged as well?) The Wiki plugins will still need to be sifted through and sorted out, since they're a mess. But at least this is one (big, overdue) step in the right direction. 😉 Edit2: Also, I think some changes are needed on the information popup box, when you click on them, but that wasn't really in the scope of what I was doing for this mini-project. |
It seems to me that even if it is as simple as changing the theme in Pico's config.yml file, this instruction still needs to be shown in the "Installation" instructions of the readme.md file.
And also: regarding the "content-sample", the installation instruction should always state to backup the current "content" directory and remove all files in it and replace the directory with the "content-sample". This way, people can directly work on their files to pass to the customization section of the readme.md file. They can then merge the files if they need it, but at least they will have a working and stable theme. And when they do this process, they are able to merge files properly (or just replace the ones needed) because they have already seen a working version on their side. Basically, the readme.md file needs to indicate everything for a basic user so that he can see his new theme working.
That's good to know. This way, they would all be ready to go, if at least the rest of the readme.md installation and customization sections are well and thouroughly documented for a working installation of the theme. More generally, the idea I had about the 'featured' or 'supported' tags, that now becomes the 'Ready-to-go' tag, was this: Also, we still have a problem: So I think going back to 'verified' would be better, and a hover over it would show what version it was verified for. This also means that there would need to be a database telling what theme has what pico version tested. It is quite a lot of work I know. But this is why this little list of endorsed themes would be necessary, so that you would do that just for this list of themes, which is much much shorter to do than all themes. I would call this list with and 'endorsed' tag, which would be the very first ones shown on the themes list. It is very important so that people know which one is certain to be working, because you endorse it and they find them at the very top. And if one of your endorsed themes has its creators not answering due to an issue, you would engage to do a fork of it and fixing yourself, or simply remove it from the list and take another. I think that this is the way to go if we want to have satisfied new comers, and minimizing the impact of pico team's load, it would be the best trade off. It is basically my initial suggestion, even though I might have described it wrongly, I am sorry for that. |
|
Okay, so, here's the thing. There's a bit of a disconnect between what you want to see here, and what's actually within our resources to accomplish and sustain. I've tried to convey this already, but our resources are very limited and any time spent on Pico is time we've volunteered, time that we've effectively donated to Pico instead of spending it on other things. The original point of this thread was a discussion on how to make this more sustainable, as things were falling behind and not getting addressed in a timely fashion. Obviously, this discussion has tangented a lot from that original discussion, which is fine(!), I just want you to keep that in mind when I seem a little unsympathetic to ideas that would require a very large commitment. I feel bad that I keep shooting down ideas, I do, but unfortunately they're just not realistic in our current situation. Without several additional, regular contributors committed to testing and tagging themes (and plugins), it's just not something sustainable. Sure, I could make the effort to do it right now. It would take a good number of hours to test everything, but I could probably do it over the course of a few days... But I can't commit to that as an ongoing process. I can't promise having that extra time to volunteer in the future on it. So, when I'm trying to decide how to proceed with this, that's the mindset I'm looking at it from. What can I do now that will be beneficial, but won't require an ongoing, endless commitment. I really hope you don't take this personally. We do appreciate the ideas. And I hate to be such a "downer" about them, but I also don't like making hollow commitments that I know I can't follow through with in the long-term. I've mentioned before, but the idea of ongoing testing of themes is a little unnecessary. Pico is stable and there are no plans at present to introduce any breaking changes. In fact, @PhrozenByte has made it a point to never break things, by including backwards-compatibility for literally every change he's made over the years (like that comment above about adding a I do think that some work should be done to update the documentation of themes, especially those with older install instructions. As I've said before, I can't make any promises about them, since it's someone else's content, but I do think it's probably worth limiting the "Ready-to-Go" themes as only those with modern instructions. I might even try to work with some developers, down the line, to get their themes updated a bit. This might just amount to me forking and updating it for them, but either way it would be nice to see it happen. If we ever have any officially "endorsed" themes though... It's probably going to be a matter of me writing and maintaining them specifically so that Pico can have some "Official" themes. We just do not have much contribution these days, and I don't see too many old authors being on board with extra maintenance of their long forgotten contributions. That being said, maybe in the future we can suggest to new contributors that if they'd be willing to commit to ongoing maintenance, we'd tag their theme in our gallery. Maybe even come up with a set of guidelines specifically for featured themes. Overall though, that's going to be a project for later on. |
|
But it seems to me that my proposal is wrongly understood: So not a work overload, a work reduction is suggested here. And at the same time, a benefit of 3 themes that the user will be sure they work out of the box, on top of other "R2G" or "verified" tagged ones if one has time to do so, but it is less important in my opinion even though it is also very good to have. |
Your proposal is being understood just fine. What you don't seem to be getting here is that I'm not comparing what you suggested before with what you're suggesting now, I'm comparing what you've suggested at any point to how things are now. Right now, there is no testing of themes. It's unfortunate, but that's how it is. Someone makes a submission, I check to make sure their Markdown isn't going to break the website and that their images are the right size. I glance at their GitHub repo to make sure there's nothing crazy going on there. I say "tyvm for your contribution" and merge their submission. Anything beyond that is extra. The work I plan to do this week sorting out and tagging the themes, that's extra work that I wouldn't otherwise be doing. But, I think it's a good idea, so I'm going to put in the time to make it happen. The difference is, it's extra one time work. Once I do it, it'll be done. It won't need maintenance or ongoing attention. Your proposal involves ongoing work. A small amount, sure, but still ongoing work. The person who will be stuck doing that work would be me. Whether it's 3 themes I'm checking for compatibility or 20 themes, it's still an extra commitment over what I'm doing right now. And I've explained, again and again, that there isn't a need to verify themes against Pico versions. You seem to be ignoring this for some reason. You've been very very focused on your idea. No, "Ready-to-Go" is not the same thing as your idea. It's a compromise that better matches something I'd already wanted to do. It is something that sounds more manageable to me, the person who would be responsible for doing the work. Also, my "Featured" idea for the future does match your idea a bit more closely. It's another compromise though, with the main difference being that the responsibility of ensuring compatibility would be on the theme author and not us. And even if I end up being the theme author in this hypothetical scenario, it would be a commitment made by choice about my own code, and not being responsible for the work of others. I've said above that I do think it would be good for Pico to have some dedicated, "Featured" themes that offer a great experience for new users. This is probably something that I'll work on in the future. But if and when that happens, it'll be my own code that I'll be dedicating myself to supporting. And I'd still welcome others to do the same with their themes. I'm sorry that I don't like your idea. That's my opinion. As I've said, it's not a bad idea, and it's certainly valid feedback! I just don't feel like it fits the reality of our current situation. No matter how many times you ignore my explanation on this and explain your idea again, it's not going to make me like it any more, and I've already told you why. I don't like that this situation feels more confrontational after every comment. I try to keep things as friendly and professional as I can, but it seems like no matter how many times I say "No", you just repeat the same suggestion. And yes, I know you're suggesting fewer themes this time, but the fact that you're suggesting it at all feels like you've pretty much ignored any of my own feedback on the idea. 😔 I've given my reasons for disagreeing with it, and I'm getting tired of going in circles about it. 👎🏻 Later this week, I should have the themes tagged and I'll be looking for feedback on them. You're welcome to provide feedback on what you think should or shouldn't make the cut, etc. |
|
Well, I am still happy that I could provide my idea on this, I think in most details possible and with most described arguments, this was important for me as a user of this nice Pico CMS. |
|
First of all, I'm very sure we're all here to improve things, so even though we don't have to agree on every topic, please all keep in mind that we're here for a good purpose. All of us (*all*) are participating in their spare time. Spare time is very precious, so I'd like to thank all of you for your work, improvements, suggestions and given opinions on this topic ❤️ I really love to see where we're getting in the course of this long-running discussion. In my opinion it's a huge improvement, even though not every suggestion is viable right now.
I like the idea having a "Official" tag. Since you're planning to add a "Ready-to-go" category for themes, I'd say we could do the same for plugins (just with "Official" instead of "Ready-to-go")?
❤️
❤️ ❤️
I agree. However, since it's the same for all themes, it should be in Pico's docs, too. It's already mentioned there, but the docs need improvement in general. But this is different topic...
As discussed earlier, some themes don't really work with Pico's sample contents, including single-page portfolio themes. For these themes one must follow the install instructions and/or use the sample contents provided by the theme.
Since we preserve backwards compatibility in usually all matter this shouldn't be a real problem. If a theme was a R2G theme for Pico 2.1, it will be for Pico 3.0, too. A theme developer can still provide "tested with" information in the theme's Besides, as explained by Maya, we simply don't have the necessary workpower for a "Featured" (or endorsed, or "Tested with", etc.) tag.
As said earlier, thank you very much for your input! ❤️ It's very appreciated. |
|
@gelavat, I want to apologize, again. My previous reply was too hot-headed, and although I tried to rein it in by the end, it was still a bit more aggressive than it should have been. 😔 I guess my main complaint here is that it feels like @PhrozenByte and I are having one discussion in this thread while you're having another. We go back and forth a bit on ideas... and it feels like you've just been jumping in where you left off instead of following the larger discussion. Not necessarily the case, I know, it's just felt like that to me. To me, your messages have been coming off in a bit of a presumptuous tone. A sort of "You should do this because I said so", self-important tone. I realize this is probably all in my head, and just part of the shortcomings of communicating over text. You seem well meaning, but for some reason your messages feel more arrogant to me than perhaps they should. I'm going to try to do a little better about this going forward. I'm not very good at social interactions to begin with, and the last year-and-a-half in the real world haven't exactly done much to help with that. 😓 Please don't take any of my feedback too personally. 😒 |
|
Hello @mayamcdougall . Thank you for that it's nice. I am sorry if I entered the discussion with an off-topic discussion. I have read the previous threads at least. For the "should", maybe this is just because I was asked to provide my thoughts about it. So maybe it seemed a bit presumptuous due to that. But maybe I triggered some control behaviour thought with this, I cannot tell if this is real or not, I would have to introspect myself about that. Sometimes I might mix up roles, because I am also a project manager for some projects so I have to tell people the "you should", which is in fact an order. Here the same term might not fully express what it is really like behind, either just a "it would be good" or "it is really something missing" or an order. So that is probably a bit confusing anyways in the language used.
I think this is very satisfactory for me and in any case the current improvement with the R2G is arealdy big step, thanks for that Maya 👍 @PhrozenByte you are welcome for the input. |
|
I just noticed that the rounded corners on Fullview images in the gallery disappear while the carousel rotates between images. 🤦🏻♀️ 😖 Hopefully I remember to fix that sometime. |
See #33 (comment)
Feedback is highly appreciated! ❤️
CC @mayamcdougall
The text was updated successfully, but these errors were encountered: