Which way should we look?

The quick answer is: forward. And it's the right one.

We can't and shouldn't abandon Cairo users. There are too many installs out there and it would be irresponsible. This means that bugs in core plugins must be fixed and support questions must be answered. If Cairo is sufficient to their needs, that's great. I know of people who contentedly use a Mac Plus, because it serves their needs adequately.

We must remember, however, that Dakar is our present and near future, Edinburgh a bit further down the road. The code refactor was a great step towards cleaning the code up and more "objectifying" can only help. The doc needs a great deal of cleanup, IMO, and that will go a long way to cut down on support questions and present a more professional face to the public.

I understand that I'm quite new to the TWiki "inner circle" and that many people have a lot invested in the history of TWiki. I would never suggest throwing that history away. But TWiki can't grow in features, in speed, in professionalism if the past interferes with moving forward.

Peter's interest in taxonomy/folksonomy and implementation of the tag plugins is great and can only strengthen the product. I hope that the current "fight" over the chaos that resides in Codev (in particular) doesn't overshadow that contribution, or prevent people from thinking about organization in new ways. It's all too easy for people to wind up in entrenched positions, unable to see the merits of other positions.

Nonetheless, part of what needs to happen is to separate the historical from the currently relevant as best we can. Personally, I have found Codev nearly useless for most of my needs, and searching for information is a nightmare. I can only speak for myself, but I don't believe I'm alone in this.

A living software product cannot survive if it becomes bogged down in its own past. Folks, cherish the past, hang on to the gems that emerged then, but look towards the future. It's the only hope for TWiki.

-- Contributors: MeredithLesly

Discussion

In ManageStaleContent I stated that I think Codev has too many functions, trying to be several things at the same time. This topic is an example of that.

If Codev is for "Feature Brainstorming and Discussion" or "Tracking releases", this topic don't belong to Codev. BUT, as MeredithLesly pointed out in TWikiIRC, there is no other place to put it.

Just trying to make a point.

-- RafaelAlvarez - 09 Mar 2006

Excellent addition to current debate. I am curious, why did you choose to create this as a new topic on its own, instead of just refactoring it into one of the already existing topics on this subject?

If you are really trying to minimize chaos, creating seperate topics without much linking to context that already exists appears to me as a curious way of trying to achive this goal?

-- SteffenPoulsen - 09 Mar 2006

Rafael: I agree.

Steffen: I wrote this because I'm a writer and had something in my head that wanted to be written down. It did not 'feel' like a comment and a three line comment box isn't very inviting to a long thought. Also, I guess, I wanted to pull it out of the StaleContent debate.

As to why it's not linked to any context: this is an interesting wiki point, I guess. I probably should have put topics in RelatedTopics, but I would have had to search for the appropriate existing topics to put there when I created the topic instead of proceeding directly to writing, which is what I did.

So you bring up an unrelated but very interesting point: how does a topic someone creates get linked to existing topics that it is, in some way, related to? Looking up the WikiNames of topics that may be related just isn't natural to me and, as I think I've already said, would interfere with writing down what's in my head.

So, basically, I can't think of a natural way to both write an opinion, as someone tagged this, and link to existing topics, either in the mainstream text or in a form. In the minimal, specific case, I would have to either have another window open to ManageStaleContent, search to find the right name, or guess as to whether it's ManageStaleContent, ManagingStaleContent, HowToManageStaleContent, or some other variation. (By the by, I were guessing, I probably would have picked HowShouldStaleContentBeManaged).

And it's wicked annoying that I can't even read what I've just written.

-- MeredithLesly - 09 Mar 2006

Some interesting opinions here.

This topic is clearly about managing stale content. IMHO, this topic should be refactored out in the interest of a better navigation experience in Codev. DeleteMe after that.

-- PeterThoeny - 12 Mar 2006

This isn't (just) about managing stale content. It's also about compatibility and general developer state of mind.

And isn't DeleteMe incompatible with CoolURIsDontChange?

-- MeredithLesly - 12 Mar 2006

On "it's all too easy for people to wind up in entrenched positions, unable to see the merits of other positions": Exactly!

On "DeleteMe incompatible with CoolURIsDontChange": As mentioned there, "if a topic is just a few days old, the chance that other sites and search engines point to it is relatively small."

-- PeterThoeny - 13 Mar 2006

While the number of other sites in general is meaningful, I guess I don't see why search engines make a CoolURI. It may make a NecessaryToBeRetainedURL, but that's quite different than being "Cool".

-- MeredithLesly - 14 Mar 2006

Perhaps a better way of expressing that point is to say that the search engines will re-scan and update their databases so it doens't matter if the URL changes so long as you have the search engine to find out what it is now.

Perhaps a more significan't point is that we can't simply paint all topics with the same retention-policy brush. Yet, it is relevant from a historic point of view how forms were introduced, but to someone dealing with 'how TWiki is now' the details of that are just clutter. Hence there are two clear alternatives.

1. Do what we do anyway with things like CoffeeBreak - move the archived content. This would put the content in the Attic while retaining the URL. It would lighten the load on content searches - slightly. The 'cool' URL topic could be locked. Or not. Depending.
2. The second matter is to do what most firms do anyway with e-mail and documents and reports and classify them according to policy. (This is the every-day work area for me.) In turn this leads to an enhanced SEARCH function that is also policy-driven. PeterThoeny has hinted at a plugin like this but I don't tink he goes far enough with the idea.

The issue here is that we need to define a retention/archive POLICY - and it should be ne that can be automated in the sense that it is algorithmic -- "is it so or not".

-- AntonAylward - 15 Mar 2006

See ScriptToReorganiseCodev

-- RafaelAlvarez - 15 Mar 2006