Textpattern.org v3.0 project

maverick · 2010-07-12 23:01:38

Bloke wrote:

I’m struggling to categorise rah_chuck_norris…

aw, shucks,

IF

Chuck Norris wants his own category. Chuck Norris gets his own category. ;P

ELSE

Whimsical?

:D

sacripant · 2011-09-29 15:55:58

A personal perspective:

I do not read English, I décypte English. then it is extremely tiring to go through 50 or 200 pages a forum for a plugin to eventually miss important information.

Yes there are the help of plug’in, but for access they must be install …

I would really like helps the Plug’ins have been available to “textpattern.net” to get a better idea of plug’in, without having to install it.
And to have for every plug’in its FAQ page, which allows the creator of plug’in centralize the answers to the questions most frequently posed on the forum thread

Destry · 2011-09-29 16:41:45

sacripant wrote:

I would really like helps the Plug’ins have been available to “textpattern.net” to get a better idea of plug’in, without having to install it.

And to have for every plug’in its FAQ page, which allows the creator of plug’in centralize the answers to the questions most frequently posed on the forum thread

+100

And taking that a step further, which I’ve already spoken to the powers that be about, is a way for collaboration on the plugin docs.

The big gap in plugin help workflow that has always existed is the lack of curation of the 10% of solid content scattered among the 90% of page after page after page of forum noise. With a collaborative doc tied to each plugin in the new repo, people could then maintain a single, concise documentation for each plugin, pulling the juicy pieces out of the forum threads as it goes along, keeping the document relevant and current. Content curation at it’s finest.

Whether or not that’s possible in .net, I can’t say, but if the wiki could serve as a tool for that link between the two sites, it’s available.

ruud · 2011-09-29 17:31:51

-1.

I offer access to plugin help and code through my own website (no need to install the plugin first).
I think TXP.org (v3) could do the same if plugins were hosted (or at least cached) there, but documentation should primarily be done in the plugin help. That’s why it exists.

Destry · 2011-09-29 18:21:45

Fair enough. There’s always degrees. Some devs are great about maintaining docs, others not. And let’s not make light of the ability to write tech information clearly.

Maybe some optional path is appropriate.

It’s not just about the base documentation, though, but other goodies get lost in long threads too, like what others do with the plugin, or useful mods they make, etc. Do you maintain that kind of thing at your site too?

Sacripant makes an interesting case. He’s not just some guy with an opinion like me, he’s a person saying, due to language, he’s unable to use the forum threads because of the noise he has to wade through. (And I know he’s not alone.) We should make the process better. It can always be better.

Bloke · 2011-09-29 21:11:07

I feel sacripant’s pain, to a lesser degree of course. That’s why the core idea behind this is, as Destry says, to bring curated content directly to the plugin’s page. This content is secondary to the documentation, but of equal importance for end users. The idea behind it being collaborative is that it allows anyone to add any of the following (non-exhaustive) items into one location:

A link to a forum post that highlights an important mod required to run on Txp X.Y.Z (think rss_db_admin_manager) or some important info that would otherwise be buried
A link to a known issue on an issue tracker to help deflect unnecessary bug reports
A link to a third party script that might be of value — a jQuery plugin / gallery for example that others can use straight away, knowing it will work with the plugin
A link to a TxpTip that demonstrates the plugin in action
Links to community-hosted Textpack translation files

If that information was available at your fingertips on the plugin page it’s a powerful and useful tool to consolidate key info about the plugin. My initial thought was to have people add such links directly and have them stored as standard Txp links so they can be ordered, etc by the author. But I was struggling to keep spam out and it put unnecessary strain on the plugin author to keep it valid and up-to-date — something that I wanted to avoid as the idea is that the repo is as hassle free as possible for plugin authors to maintain.

Destry threw me a curve ball the other day and suggested using some online central repo like a GoogleDoc (not my first choice, btw, as I’m not a huge fan) or equivalent tool such as our own wiki that allows anyone to edit the contents. The only thing we need to do then is specify a loose template so that people get used to knowing where stuff is in that document. The plugin repo then has a single link to that ‘supplemental info’ and it’s maintained by everyone with a vested interest in that plugin. Perhaps longer term we could suck key points out of this document via XML (or something) and show them directly on the plugin’s page, but that’s a lot further down the line.

To answer Ruud’s point about documentation, when you publish a new version of a plugin to .org (manually in Phase One; optional automation in Phase Two) and it builds the changelog for you, one of the things I hope to do is actually fetch a copy of the plugin .txt file and cache it in a custom field (probably a glz_cf textarea). This serves two important goals:

If someone clicks on a plugin download link and it 404s, the cached “Last Known Good” copy can be served instead (I’d love to be able to do this automatically and seamlessly in one click — perhaps by ‘fetching’ the HTTP header first to check its status and, if valid, continue to the author’s site to grab the .txt file, else serve the cached version. Not sure if that’s possible though: any technical gurus out there who can offer advice here please let me know)
(as ruud says) Having a cached version of the plugin means that documentation is available directly without needing to install the plugin. I do it on my site, ruud, net-carver, Gocom and Adi do it and I know others do too. But to have it on the .org site as well might save people downloading a copy of a plugin that doesn’t fit their needs (and thus makes download counts more accurate!)

I hope that sheds more light on the direction we’re heading and makes sense. Any other thoughts please share them.

I’m going to talk with Destry later about perhaps using the wiki as the central location for plugin curated docs. I’m not sure what’s possible there, nor how to set up templates and stuff. It might be a non-starter, or it might be the start of something beautiful.

uli · 2011-09-29 21:52:52

Gerrit van Aken, a well known German web designer with a huge followership, recently posted (praegnanz.de/weblog/aktuelle-cms-stimmungslage) he’d almost completely turned his back on TXP because there hadn’t been larger progress in the TXP project since 2005.

My first thought was, already in 2008 (new parser, variable/if_variable tags) he didn’t follow the project any longer but that rather underlines the following argument.

My second thought was he didn’t have enough time to look after and for those lots of plugins that have been released since and that do fill many gaps he seems to perceive. With its lean core, TXP heavily(!) depends on plugins if it shall serve the increasing demands of the web. But they are there, they just need to be known more widely and accessed more quickly.

Enter TXP Resources v3 as a central hub for plugins.

Why not reveal in advance which tags and attributes/values a plugin offers, right on the central repository for plugins, in order to offer better decision support? Why not reveal even plugin code for those who can judge the quality of a plugin by browsing its code?

I can’t count the times I was sick and tired of having to install each and every plugin just in order to be able to read if I can use it, if I get the tools together to get the job done. I’m just talking about the quotation stage, not even the real jobs.

Think of tagging: there are tru_tags, smd_tags, cbe_tags and even rss_uc is used for tagging. Do all of them offer image tagging? If not: which one does so?

Think of counter plugins (I have 10 of them on my HD): what are they made for, which tables do they have access to, do they write or can they only read?

Having more plugin information at hand would make our lives easier, no doubt. And would help gathering a larger followership behind TXP instead of migrating along WP-wards with Mr van Aken.

Edited to add: I wouldn’t have written down all this if Stefs post had been there when I began writing.

Last edited by uli (2011-09-30 00:06:36)

Bloke · 2011-09-29 22:06:47

uli wrote:

cbe_tags…

[OT] more tag competition? I’d better step up my game and get mine working better ;-)

uli · 2011-09-29 22:19:38

Bloke wrote:

[OT] more tag competition?

Oh right, cbe_keywords was the name, but it is tagged “tags” on TXP Ressources

Maybe another use case for improving the ressources page selectively. What does this plugin, does it really belong in my list? Can’t find out without installing it.

uli · 2011-09-29 22:29:53

Stef, finally finding the time ;) to thank you for clarifying what TXP Ressources will do. Thanks as well for all the efforts and time you’re putting into it! I’m excited what TXP Res will be, and really looking forward.

Bloke wrote:

A link to a forum post that highlights […] some important info that would otherwise be buried
[…] Any other thoughts please share them.

Only just yesterday I thought about bolting on some task -> solution repository with a wiki approach.

Edited for correct Textile

Last edited by uli (2011-09-29 22:30:55)

Textpattern CMS

Textpattern CMS support forum

#31 2010-07-12 23:01:38

Re: Textpattern.org v3.0 project

#32 2011-09-29 15:55:58

Re: Textpattern.org v3.0 project

#33 2011-09-29 16:41:45

Re: Textpattern.org v3.0 project

#34 2011-09-29 17:31:51

Re: Textpattern.org v3.0 project

#35 2011-09-29 18:21:45

Re: Textpattern.org v3.0 project

#36 2011-09-29 21:11:07

Re: Textpattern.org v3.0 project

#37 2011-09-29 21:52:52

Re: Textpattern.org v3.0 project

#38 2011-09-29 22:06:47

Re: Textpattern.org v3.0 project

#39 2011-09-29 22:19:38

Re: Textpattern.org v3.0 project

#40 2011-09-29 22:29:53

Re: Textpattern.org v3.0 project

Board footer