excellent idea. few things feel like they need to be extensions, and this would also make it easy to hack on stuff like the zotero connector and maintain control over random tiny unmaintained extensions.
first things that come to mind: can every extension be converted? what do i lose in terms of usability, if anything? in a simpler time, i would have expected these things to be at the top of the docs if there were docs, or else for the docs to just be a nearly empty readme containing just "# TODO\nwrite readme"
repeat after me: if your readme wasn't worth writing, it isn't worth reading
the readme is the public face of the software that you are posting to this site for the consideration of potential users. why start by disrespecting them with a list of "Key Features" (linking to an equally doubtful-looking architecture document) that's just raw data that you didn't see fit to arrange into an introduction based on your understanding of what a human user might want?
even assuming it's all correct, which it might be if you've proofread it, nowhere in this impersonal wall of token vomit is there consideration for an actual user, because the purpose of these tools is management-brained report generation—and that is not what documentation is
explosion-s•12m ago
You do have a lot of fair points I've been working on the README recently and will work on it a bit more soon, most of my work has gone into the actual code. Currently it's intended for extensions that:
1. Apply to only a few specific sites
2. Their functionality isn't entirely browser API based (this wouldn't make sense even if they're polyfilled)
3. "Could be" userscripts: It's an abstraction layer to make things work, not something to build on top of.
That aside it's pretty powerful and does a really good job on most extensions that meet this criteria. I'll let you know once I'm finished with the README, I'd love to have some feedback on it. It's worth noting there's a draft (totally human written) blog article in docs/article.md
evertedsphere•1h ago
first things that come to mind: can every extension be converted? what do i lose in terms of usability, if anything? in a simpler time, i would have expected these things to be at the top of the docs if there were docs, or else for the docs to just be a nearly empty readme containing just "# TODO\nwrite readme"
repeat after me: if your readme wasn't worth writing, it isn't worth reading
the readme is the public face of the software that you are posting to this site for the consideration of potential users. why start by disrespecting them with a list of "Key Features" (linking to an equally doubtful-looking architecture document) that's just raw data that you didn't see fit to arrange into an introduction based on your understanding of what a human user might want?
even assuming it's all correct, which it might be if you've proofread it, nowhere in this impersonal wall of token vomit is there consideration for an actual user, because the purpose of these tools is management-brained report generation—and that is not what documentation is
explosion-s•12m ago
1. Apply to only a few specific sites 2. Their functionality isn't entirely browser API based (this wouldn't make sense even if they're polyfilled) 3. "Could be" userscripts: It's an abstraction layer to make things work, not something to build on top of.
That aside it's pretty powerful and does a really good job on most extensions that meet this criteria. I'll let you know once I'm finished with the README, I'd love to have some feedback on it. It's worth noting there's a draft (totally human written) blog article in docs/article.md