[feedback] How to bring txp back on track ? Let's debate !

davidm · 2006-02-24 07:00:13

andjules wrote:Whatever the outcome of this discussion (and I think this discussion is great), please, let’s keep it light, streamlined, not another open source, everything-including-the-kitchen-sink project. The world already has Mambo/Joomla, for better or worse. It already has Drupal – a good thing, if you want to get neck deep.

I couldn’t agree more with you on this, you summed it up quite well (and I too said Elements was a great prospect !)

So that everyone is clear about it though : we never talked about changing development’s orientation or pace, but talked everything outside dev itself and the fact that some task would be better handed over to other people to lighten the burden of the dev team and allow willing (and hopefully able ;p) contributors to involve themselves in an extended (more organized and communicative) team…

Last edited by davidm (2006-02-24 07:01:13)

Skubidu · 2006-02-24 08:24:01

I couldn’t write earlier, because I was sick over the last 2 days. But as I am one of the three initiators of this thread, I like to comment on a few things I’ve now read in this thread. Please forgive me if some things have been said before…

First of all and again: We didn’t start this thread neither to fork textpattern nor to make Textpattern a commercial product. I think it’s very important, that Textpattern’s source code stays free. And all this discussion is not about complaining about the devs working to slow. It’s about not knowing the plans for the future.

In my oppinion, Textpattern is a very design orientated CMS: The concept of sections, pages and forms with all the tiny tags are really easy to use if you like to build a website. For me this is one of the biggest advantages – you can build very complex websites without getting in trouble of having to handle dozens of external files. I think that’s why many people here in the forums don’t know much about PHP coding but about doing HTML websites. If I think of an admin side face lift: I think it’s important, because Textpattern has to keep up to date and because other comparable systems have made big improvements in this area. I know that there are other thing having to be done before this and that’s why – again – I think there is a need of some kind of a roadmap or coordination: A list saying, that we (the people caring about Textpattern) like to do this and that in this order. This list may change often, but it would give an overview about what is planned. There has to be a possibility for non coders to contribute ideas, therefor they have to know what is planned.

I hope that at the end of this discussion, we will have more people who are officially taking care of Textpattern. For example, you don’t need to be a PHP coder to write the FAQ, you don’t need to be a coder to take care of a kind of Textpattern portal (a new textpattern.com) with an official plugin repository and (hopefully) localized areas (like fr.textpattern.com, de.textpattern.com etc).

We have so many people here having great ideas and who are willing to spend their free time here. So if we spread the responsibilities and getting more people in the core team Textpattern will move on quicker. I’m convinced we don’t have the problem that there are too less people having time to contribute things. It just has not yet been communicated properly how to contribute, if your not a PHP programer.

Last edited by Skubidu (2006-02-24 08:24:27)

tranquillo · 2006-02-24 12:27:25

“The plugin approach, and the soon-to-come ‘elements’ approach help keep TXP’s core light.”

It’s all in this statement by andjules, you just have to read, what’s really written there:

The elements will give the possibility to add modules to txp (more individual features!!!!).
With this, developers (in groups or one by one) can help the core team develop txp by coding modules (no need to increase the number of the core devs).
The core team can stay as it is and keep developing the core.
Plugins will consist of one file to install, larger plugins will become elements (a subject from the mailinglist).

Hence, the roadmap of the core team is far better, than it might appear.

On the other hand, I totally agree with some ideas in this thread to improve communication, plugin repository etc. I suggest, that everybody, who’s willing to spend his time to improve these things, signs up on a list (the textbook list is to narrow, imho: everyone should be able to point out, what specific task he is willing and able to do (not just admin, mod and forum tech)) and further steps are then discussed and realized within this group of people. I think, that there are enough ideas in this thread to get started doing them.

Last edited by tranquillo (2006-02-26 10:38:29)

Jeremie · 2006-02-24 14:23:42

tranquillo wrote:
I suggest, that everybody, who’s willing to spend his time to improve these things, signs up on a list (the textbook list is to narrow, imho: everyone should be able to point out, what specific task he is willing and able to do (not just admin, mod and forum tech)) and further steps are then discussed and realized within this group of people.

It’s a wiki page, if you have a better idea of doing it, wiki your way in and make it better :)

davidm · 2006-02-24 15:38:40

Jeremie wrote: It’s a wiki page, if you have a better idea of doing it, wiki your way in and make it better :)

lol

Now you sound like someone I know, Jeremie ;D
… let’s set back and relax guys ;P

This being said, I don’t see how the wiki would be a bad tool to “sign up” for a given role ?

Last edited by davidm (2006-02-24 15:39:44)

jdueck · 2006-02-24 15:44:52

OK, let’s stop talking and put this on the fast track.

Let’s set up a meeting on April 24th to delegate a committee to do an investigation. The committee’s report will be due at the end of August, at which time they will report on their findings and issue recommendations. On September 20th there will be a hearing on the merits and disadvantages of the committee’s recommendations, followed by a meeting on November 17th to vote to select a single member to draft a resolution on the same. Revisions to the resolution will be offered on the Dec. 11th meeting, and (after adjourning for the holidays) a final resolution will come up for vote on January 29th, after which a committee will be selected to draft a schedule for implementation of the resolution and assign responsibilities.

NyteOwl · 2006-02-24 16:19:03

choking laughing jdueck, you don’t work in government by any chance? :)

davidm · 2006-02-24 16:48:37

lol yeah well that sure was funny !

But not an accurate description of what we’re trying to do here… at least I believe (if someone thinks so please come here and shoot me in the head !)

Jeremie · 2006-02-24 16:49:36

Nope, it’s not :)

davidm · 2006-02-24 17:23:01

Thanks Jeremie, my head is safe for now :P

<em>Following up on skubidu’s post…

Might seem off topic but I think it helps clarifying were txp stands against what I deem to be its competition (tada : not WordPress I am talking about ! You’ll see why…). Of course this is my take on things, nothing more : as such, it’s highly subjective…</em>

Skubidu wrote : I think it’s important, because Textpattern has to keep up to date and because other comparable systems have made big improvements in this area.

That’s something I had meant to emphasize and it’s nicely said… we don’t exist in a vacuum. I think some systems are catching up (EE, CMSMS and MODx are the 3 systems I would set in the same flexible/modular category, though each has weak and strong points, and to me CMSMS is still pretty young…).

How I see comparative advantage :

CMS Made Simple

BETTER THAN TXP

illimited hierachical levels (though can be achieved with txp, so I hear, and will be feature of txp 4.1)
permission and user management

AS GOOD AS TXP

blobs akin to forms
templating and tag system akin to textpattern’s, though much less tags available (for now)
user tags are in fact plugins called via tags : e.g can be placed in template and you can pass parameters in a way very similar to txp

NOT AS GOOD AS TXP

missing Textile ;p (as far as I know…) or Markdown
no concept of section : templates are assigned to pages individually, conditionnal testing is more limited
admin is clear but not as elegant as txp, and most certainly dull
less features overall (not necessarily bad, but certainly more limited than txp)
fewer – less stable plugins (but growing fast)
younger than txp (wouldn’t use it in production yet)

EE

BETTER THAN TXP

multiple weblogs is very easy to set up (as good if not better than b2evolution or WordPress Mu in this respect)
conditionnal global variables (detail here)
custom variables is more powerful than txp (can choose type, and associate custom field group individually to weblogs)
integrated gallery is nice (but only available in paid version)
revisionning (utility of this might be discussed though)
rights management and user management (both backend and frontend, pretty granular control over permissions)
Built-in Private Messenging (can be useful for collaborative writing, as Jeremie often pointed out => Jeremie correct me if I am wrong) and mailing list

AS GOOD AS TXP

template groups are akin to sections (but same “problem”, categories cannot be hierachically placed under template groups)
sub-templates akin to forms
tags are easy and readable, templating is as good as textpattern, so is standard compliance.
plugins are called via tags : e.g can be placed in template and you can pass parameters in a very similar way

NOT AS GOOD AS TXP

not opensource (but now, free core)
urls are not as flexible and search engine friendly as txp (based on path info. To EE users : yeah I know, can be tweaked with rewrite rules, but more complicated)
admin is ugly and way too heavy (though better laid out than before)
fewer plugins (under 90, most of them adding limited features…)
modules are very late and scarce (forum and galery were long overdue… and feeling lonely !)

MODx

BETTER THAN TXP

custom fields (aka Template Variables) : you can choose any type and any number of custom fields, which are linked to templates
frontend editing : QuickEdit module is way more advanced than anything I have seen so far
illimited hierarchical levels (tree based structure, documents can be made into “folders” => some are against this, but useful)
permission and user management (backend and frontend access, though a bit complicated system => will change soon)
content-type for web documents can be of any mime-type
CSS are parsed by MODx : kind of “native” server side CSS => you can have global variables and snippets (=plugins in txp) usable in CSS
chunks usable in CSS (very useful to have re-usable bits of CSS code => just like for HTML pages)
dbAPI and API for developpers, helps building custom solutions fast

AS GOOD AS TXP

chunks are akin to forms (re-usable bits of content)
tags can be used the same way txp does (though less intuitive syntax ugly & and `)
snippets are called through tags, but with an additionnal built-in capability to call it cached/uncached
can use Textile or Markdown

NOT AS GOOD AS TXP

Admin is bloated and ugly (inherited of Etomite => will change soon), with javacript
if you don’t disable it, script.aculo.us library is bulking page weight (and it’s necessary to use QuickEdit. This said, AJAX library is not freezed : moofx is a candidate for example)
Fewer plugins/modules/snippets (though growing fast and high quality stuff => not buggy and great features added)
still young, less mature than txp though more potential (but it’s a framework… )

Last edited by davidm (2006-02-24 17:51:49)

alexandra · 2006-02-24 17:54:52

@jdueck lol lol lol …

@David
Brilliant summary David! Thanks for that. Such comparisons should go into dev´s roadmap discussions. Very valuable.

Please let me add, TXP is on it´s way:

first steps are made towards a ThemeEngine
elements (Zem reported about)
sub ~~categories~~ sections will come
Kusor is working on XML-RPC
Rights & Permission (we work on a paper)

My concern is, TXP lacks of coordination in many regards. F. e. such summaries as Davids above should go to a development coordinator/ dev coordinating group. It should be discussed and transformed.

Last edited by alexandra (2006-02-24 18:06:34)

Jeremie · 2006-02-24 17:58:38

davidm wrote:
Built-in Private Messenging (can be useful for collaborative writing, as Jeremie often pointed out => Jeremie correct me if I am wrong) and mailing list

I don’t think private messaging is that useful. Nice for some people, but far below the needed feature list in my opinion.

For collaborative work, even very basic, it’s more like a per article & per usergroup thread (forum thread, or parallel backend comment thread if we want to re-use existing TXP features) is imo the top thing needed.

Email is 99% of the time more effective than private messaging.

Textpattern CMS

Textpattern CMS support forum

#85 2006-02-24 07:00:13

Re: [feedback] How to bring txp back on track ? Let's debate !

#86 2006-02-24 08:24:01

Re: [feedback] How to bring txp back on track ? Let's debate !

#87 2006-02-24 12:27:25

Re: [feedback] How to bring txp back on track ? Let's debate !

#88 2006-02-24 14:23:42

Re: [feedback] How to bring txp back on track ? Let's debate !

#89 2006-02-24 15:38:40

Re: [feedback] How to bring txp back on track ? Let's debate !

#90 2006-02-24 15:44:52

Re: [feedback] How to bring txp back on track ? Let's debate !

#91 2006-02-24 16:19:03

Re: [feedback] How to bring txp back on track ? Let's debate !

#92 2006-02-24 16:48:37

Re: [feedback] How to bring txp back on track ? Let's debate !

#93 2006-02-24 16:49:36

Re: [feedback] How to bring txp back on track ? Let's debate !

#94 2006-02-24 17:23:01

Re: [feedback] How to bring txp back on track ? Let's debate !

#95 2006-02-24 17:54:52

Re: [feedback] How to bring txp back on track ? Let's debate !

#96 2006-02-24 17:58:38

Re: [feedback] How to bring txp back on track ? Let's debate !

Board footer