please create new web to talk about Twiki Next Generation. I argued in length here why new web - in short to remove "noise" from Codev web, and to allow simpler skin, more user-friendly for outside experts which I want to invite.

the current concern is lack of coding (that could be done without re-writing TWiki) to incorporate new feature or with going for a new generation design. Hence the need was to get more people involved and in particular more good coders into the CoreTeam. I don't see how a Tng web would achieve this.

My understanding is, that there are developers willing to work on new kernel, where features will not be suitable to add to current stable Twiki core, and (these patches) will rightfully be rejected - and efforts to create them wasted. They do not want to fork, but do not want to be constrained by current stable Twiki core. Try full redesign, and we will see. -- PM

Tng problems

Would existing TWiki Webs be convertable to Tng?

Yes, later when Tng will settle down. -- PM

Are we talking new generation design? If so, what doesn't the existing design let you do?

Idea is to have great stable Twiki, where all unstable patches are weeded out by CoreTeam, and discussion about the possible design of one or more separate kernels of next Twiki -- PM

it breaks through the design limitations of current Twiki. Detailed, it would take many pages, a few hundred K of text, UML diagrams and charts. -- AA

Tng features

Tng will have a compatability mode that subsumes the topics in their present form while offering other storage options, using plugins, driven by a config file.

OO encapsulation, starting with wrapers around the present code, mvoing through refactoring the present code into an extenisble OO format and eventualy offering a fully OO code base that can support various storage and configuration options

Multiple storage formats would clearly appeal to a lot of people, I see no reason TWiki can't cope with that, but there's lots of coding and testing needed to achieve this. If someone has the time then I'd be happy to contribute, I'm particular interested in how TWiki could cleanly deal with moving between different formats e.g. using the current RCS format as a neutral transport mechanism.

TWiki needs a SIMPLIFICATION. The documentation on TWiki is not adequate,
there are too many interfaces that are marginally understood.
Other threads of discussion here and in Support give credence to that.

TWiki is too complex for people who haven't spent a lot of time studying the code and reading
Codev and Plugins and figuring what topics are out of data and what is currently revelvant.
It may be fine for the core team who "grew up with it", but the learning curve is too great.
There is a lack of structure and disciplne to the docuemtnation.

I think we would all agree that the features have always been are continue to be carefully discussed and likewise how to change the implementation is carefully considered WRT whatever is already there.

But, the problem is architectural complexity. Its not that the complexities aren't worked through carefully by the CoreTeam before being implemented, they are. But, see, therein lies the symptom - only the CoreTeam have spent the many hours required to understand that complexity, and they are hesitant to give change access to the CVS repository for fear that someone will mess up one of many interdependencies.

I don't understand the core of TWiki, but I have been using it for 2.5 years. I grew up with OO, structured design and building models before coding. I also grew up with building in the small and sticking on the next bit. Sooner or later good projects just need a redesign. Look at http://gallery.sf.net - one of the most successful projects on SF. The author there has stopped all coding on V1 because he has to redesign the core. The fact that it is worth doing that is a tribute to the success of the project. TWiki's the same. The code is not the project.

All sotware suffers from an increase in entropy. It takes active work on the part of the
developers to fight that.

As you say, the code is not the project. That's why we want to stay in the project and not
fork off to TnT ("Ting's not TWiki"). I recognise that those who have been involved in TWiki
are very likely to be interested in contributing to Tng and the work on Tng can also contribute
to the 'mainline' TWiki. Call it an experiment if you like rather than a branch or fork.
Right now, a lot of people have experimented on their personal TWikis.
Perhaps we need to roll these things up and try restructuring them.

I do support the idea of a Tng web, and splitting off this re-architecture work to enable it to progress independently, though I would hope with a lot of shared participants and some code sharing. Moving to TWikiOO with a real Wiki:UnitTest approach would be very useful,

There are precedents from projects such as Samba for having an 'in house' code fork.

Care would need to be taken with OO Perl to ensure that performance remains good, particularly for non-ModPerl environments - TWiki is already 13,000 lines of code without plugins, and ModPerl is often not available, even on intranet servers. OO Perl would impose some additional overhead, though this could perhaps be hidden through smarter algorithms (e.g. building in a version of the CacheAddOn).

Contributions of usable code or documentation are always very much appreciated, particularly if they follow the PatchGuidelines and are already well-tested. The main reason that things don't happen faster with TWiki is that the CoreTeam are busy with their day jobs, not out of some malign plan to just not do anything...

I tried to refactor text above, run out of time. Please help me some. If you miss something what is important for you, please restore. Thanks. -- PeterMasiar

Sorry to insert before refactoring is complete...

Inhouse forking or not... It would clarify discussion if there was a separate area to discuss. Not a new web per se.
Another way to create a new discussion thread on Codev is to create a new topic tree. Then create child topics under the new topic.

Generally Codev is not well structured. Seems that parent-child relations are not often used, only the webform to classify topics. But this is a flat hierarchy.
For example, if you look at the breadcrumb at the top looks quite absurd: TWiki > Codev > CoffeeBreak > TimDistro > PleaseCreateNewWeb. It's a historical path, not a logical one: it doesn't tell you anything about the meaning of this page.

To be able to browse logically through Codev topics, other topics (a lot? almost all?) would have to get reparented.

And each topic would need to reserve an area to navigate this relations. Or we should use a skin that supports this.

For instance: on the page of BeijingRelease, you cannnot see that EasierUpgrades is a child topic. It's only the way around, from child to parent.

Arthur what you say makes a lot of sense; we should be making better use of the tools already avaialble to us. I have freely reparented topics before and nobody complained. I seem to remember seeing a formatted %SEARCH example somewhere which showed the parent-child relationship in other direction as well.

To cut and run from Codev is a seductive idea, except that we end up making a plethora of back-links to keep the interesting topics. Ever searching for the simplest solution, why not just use categories? We use categories extensively to organise threads of related knowledge in our webs, but we don't use the TWiki categories mechanism (is it still there?). Instead, we use the c2 approach and simply write "CategoryXXXX" at the bottom of a page in a category and write SEARCHes to find the categorised information. If the category doesn't exists, then it stays question-marked until someone creates it. CategoryRefactorCoreCode might be a good place to start.....

plethora of back-links - We can just start with the interesting topics...

The difference is that you don't always need to search. Especially if you are not looking for something specific. Sometimes its more productive if you are able to browse topics - to get the big picture, or just to get new ideas. The category approach also doesn't do hierarchies.

You misunderstand what I mean by 'search'. Here's one of our category pages, actually it's CategoryConfigurationManagement:

Topics related to Configuration Management
%SEARCH{"%TOPIC%" nosearch="on"}%
(Note that this table is automatically generated.
To add a page to this category, insert a link to %TOPIC% on that page.)
----
See also: Main.FaqCategories, CategoryCategory

The front page of the web contains a search for CategoryCategory, so that each of the known categories is "in your face".

All of the most significant open source communities have some centralized "cathedral" elements -- look at the way Linus controls what goes into the Linux kernel, or the way Larry Wall controls what goes into the design of Perl. But the most successful open source communities surround that cathedral with a bazaar that is significantly open.

IMHO we have two groups of developers with somewhat incompatible goals:

big legacy extablished installations - where code stability and backward comaptibility is the most important, and

curious and adventurous - people which came along attracted by Twiki's superior features, and trying to participate in this successfull project, but they do not have yet big installations with many users trained and many pages to maintain.

Because priorities are different, misunderstandings are inevitable.

Are goals of these groups mutually exclusive? Seemingly yes: adding new features which adventurous are proposing might affect code stability. But without adding new features Twiki would stagnate, cease to be leading-edge. Then first adventurous will leave to other leading-edge projects, and after that, Twiki installations would be converted to other wikis with superior features, and only couple legacy installations will remain, forever happy what they have. So Twiki will remain alive, but -- let's say not kicking

Another area where "adventurous" wanted to go is to improve and make easier and more intuitive both

user interface and

installation and system administration

So I strongly believe that even in interest of "legacists" is to allow "adventurous" to try new ideas, as long as they do not push then into legacy branch before stable. FriendlyFork is a way to do that.

"legaciscts" in CoreTeam realize this, too, and allowed to work on improving of user interface - because that it is good even for legacy installs.

I strongly believe that for long-time survival Twiki as the best wiki on the market, and in the best interests ot both groups of the twiki community, is to increase speed of innovation of twiki code. Many important features currently unique for Twiki are implemented by other wikis. Especially KwikiWiki architechture is very open for both accomodate Twiki features, and to accomodate markup from other wikis. I strongly believe that unless very radical changes are made, Twiki's superiority will be lost, leading edge will move to other wikis, and all inwestment of time by the "adventurous"
in twiki will be wasted.

"to save Twiki's superiority" was the reason why I asked for new web and for FriendlyFork, not to annoy CoreTeam or add them more work.

I have almost all I need in Twiki - I customized Twiki a lot (see my Usability wiki, some Twiki admins loked
my customizations and I am looking forward to share with them.

Recently I was looking for a open-source system to handle other my needs (IT infrastructure for department working on many small-to-medium software projects) and found GForge, http://gforge.org/ . It is open-source clone of SourceForge, excellent tool for departments and small software companies to manage projects. It has CVS, viewCVS, bug tracking, maillist, jabber IM server etc.
The only thing they are missing is a wiki for docs, and they started looking for one.

I would like to find out if there is other developers in Twiki community interested in it - please comment at TWikiForGForge page , not here.

And we cannot wait another 3 months to decide this - I am sure TikiWiki will be glad to be default wiki for GForge and for hundreds of projects, and I bet they are working to make it happen. So I create TWikiForGForge page for it.

A second line of development has a lot to be said for it. But considering the difficulty of getting enough help for TWiki as it stands, the chance of the extra effort to develop a new TWiki, maintain existing and merge back changes seems low. I wanted to make big changes to TWiki and didn't need a fork to achieve this. However, it did take a lot of effort.

First step - post some small helpful changes, help take this into core e.g. respond to suggestions

Do a mix of the major changes I wanted with others suggested on Codev. Got invited into the CoreTeam to finish this.

In this process I added a lot of OO (often mentioned as needed for core), the Session capability (alluded to above, for integrating in different logon systems), the form system and several other changes.

My personal preference would be to see more work on the current codebase; a ton of improvement is still possible. However, we need more active developers to achieve this, recents changes a good step towards this. If others want to have a separate fork then free software allows for this and my best wishes go out to you. But don't be suprised if some on the CoreTeam have concerns and reluctance.

John, IMHO your comments above are regarding GForge - I refactored part of the discussion (and opinion poll) to new TWikiForGForge page. I appreciate your opinion, but cannot vote for you

Also, I disagree with you that Twiki has not enought developers. It has more than enough patches waiting to be comitted (and some perhaps never will be applied, because original developers alredy left Twiki), so clearly bottleneck is elsewhere - and FriendlyFork is how GPL world solves this kind of problems, IMHO.

My comments above do not directly relate to GForge. Also, please note it takes developers to apply patches and often quite a lot of work is needed. The CoreTeam has been in desparate need of new members; it's difficult to find people with the rights skills, commitment and interest. Also there's a lot more to it than applying patches. Free software offers many possibilites - forks are not a necessary result. I have deliberately given me contributions as free (in the original GNU sense); so whilst I'd prefer to not see a fork, I wish people luck, including use of any software I provided.

We can learn from history. Linux thrives because there is one small kernel managed by a small team, and there are lots of distributions adding value for different user bases, all based on this kernel. This scales well. BSD on the other hand has fragmented into several forks with different kernels and thus lost momentum. (BTW, no offence to BSD, it has many very nice features)

TWiki is used in many different areas, many more then initially anticipated. The current one package approach does not fit that bill anymore.

I think the Linux model can be applied to TWiki. A small kernel (controlled in cathedral style) with different distributions (in bazaar and/or cathedral style). Those TWikiDistributions can be done by the CoreTeam and others. In TWiki's case, the kernel is composed of the TWiki libs, the docs, a base set of Plugins and a few Skins.

Now, the kernel can go through revisions. At some point it makes sense to rewrite large parts of the internals, e.g. to switch from procedural to OO. This should be done without negatively affecting the dependencies and the TWikiMission. TWiki is an OS, it need to remain backward compatible.

A TWiki rewrite does makes sense at some point. Questions that need to be resolved are:

How can we ensure that the current "legacy" TWiki gets evolved in a timely manner based on the mission and current release priorities?

How can we make sure TNG is backward compatible? (What test infrastructure do we need to build?)

My concern is that the core team could thin out too much at this time with an internal fork. I think it is OK if Andrea focuses on TNG with his researcher role, but the other core team members should focus on the current TWiki: Project advancement and process improvements as laid out in AppealToCodevCommunityByCoreTeam.

At the point when TNG is stable, backwards compatible and performs well we can take it into the next "kernel" version of TWiki.

Please see NextGeneration. This is a new category for WebForm to mark a topic as next generation. Not a new Web, but hopefully has the benefit people were looking for. I've also created NextGenerationForm - this means extra fields can be added for NextGeneration topics.

It seems a new web is not required. Just make a topic on the Brainstorming web and incorporate the ideas there. I think it would be best to not use simple "brain-dead" search of all the ideas on the Brainstorming web or codev web, if that is where it winds up. Instead, we need a high-level topic that will collect some key sub-ideas, etc. The ideas need to be organized a bit more, and not just by the date that they were added to the conversation. This is some work, and requires that someone collect the ideas that are presented. Marking the pages NextGeneration is one step in the right direction, but still leaves us with a slew of ideas with no higher-level grouping. Even then, it is necessary to pull together similar ideas and try to make some sense of the directions that are proposed.

I'm not aware that there is a Brainstorming web. NextGeneration will give no more grouping than a new Web. Grouping will come from parent information and extra fields can be created on NextGenerationForm that give extra grouping, plus of course the usual Wiki techniques of key words and "portal topics".

Yes, if you use the word 'web' to strictly mean the separate namespace web on a TWiki then you are right, but I really don't see that a new web is necessary as long as the ideas are tagged with the Brainstorming tag within the Codev namespace web. There is no reason you can't use another form. My point is that I don't agree that a new namespace is needed just to talk about something new. In fact, the concept of separate namespaces on one Twiki install especially for a single user is something that deserves a second look. I think it is just added complexity without much benefit. If you are going to add the tags anyway with another form, just add the form and a means to categorize them, as you mention. New namespace is not needed. That's just my opinion.

I'd like to think that the TWikiCommunity 's opinion counts for the architecture and design considerations for a new web so I was perplexed to read that "A TWiki rewrite does makes sense at some point" and "OK if Andrea focuses on TNG with his researcher role, but the other core team members should focus on the current TWiki"...

The only person willing to summarise with a straight "no" for a new web for TNG was Michael: most core team members agreed. Maybe we were too loud.

I want to help archiving the stale content on TWiki, Codev and Plugins.
The old content won't be thrown away, but moved to less visible webs:
CodevAttic, PluginsAttic, TWikiAttic.

(BTW can the Cairo code handle wikiword webnames?)

The tagging has shown a large portion of stale_content that can be
moved.
If the old topics are moved, normal search results will be more
relevant.

Arthur

Sven Dowideit 07 March 2006 22:51

I support this, rather alot

sven

[Quoted text hidden]

Colas Nahaboo 08 March 2006 01:56

On 3/7/06, Arthur Clemens wrote:
> I want to help archiving the stale content on TWiki, Codev and Plugins.
> The old content won't be thrown away, but moved to less visible webs:
>CodevAttic, PluginsAttic, TWikiAttic.

It would be nice, but will break URLs (and this can be confusing on TWiki
as going to a non-existing url with prompt for page creation)

The alternative is to "date" webs, e.g. use CodevCairo, CodevDakar
(or CairoCodev, DakarCodev, ...). TWiki release gives a natural
timescale, Codev2006 would be awkward. TWikiCairo could this hold
the Cairo docs while the Dakar ones would be on TWikiDakar...
And this would ease seeing which Plugins are ported to Dakar.

An interesting setup could even to have many TWiki installations running
at the same time, one per release: The Cairo one would hold the
Cairo-related webs and
the Dakar ones would hold the Dakar ones... could be quite useful!

TWiki is revision controlled, so there is really no argument against this. The fact that when you move a topic you also move the history is actually a bug, not a feature.

So, WIBNIF when you move ThisTopic to ThatTopic, links to ThisTopic still work, but refer to a read-only copy of the last revision of ThisTopic before it was moved? The same also applies to deleted topics, of course. Moved topics would of course play no part in searches, would not appear in index lists, and could be retired after a time subject to a log of accesses to the moved topic. Frozen copies would also say whether the topic was moved, deleted or whatever, and link to where it was moved to.

Of course, if someone subsequently re-creates ThisTopic with different content, the link cannot be expected to "know" that the link is meant to refer to an "old" version of ThisTopic; but in most cases, including the 'Attic' case under discussion here, it would work rather well.

BTW I say "topic" above, but of course I mean any versioned container i.e. attachments and webs as well.

Kenneth Lavrsen 08 March 2006 04:15
Crawford Currie wrote:
>
> TWiki is revision controlled, so there is really no argument against
> this. The fact that when you move a topic you also move the history is
> actually a bug, not a feature.
>
> So, WIBNIF when you move ThisTopic to ThatTopic, links to ThisTopic
> still work, but refer to a read-only copy of the last revision of
>ThisTopic before it was moved? The same also applies to deleted
> topics, of course. Moved topics would of course play no part in
> searches, would not appear in index lists, and could be retired after
> a time subject to a log of accesses to the moved topic. Frozen copies
> would also say whether the topic was moved, deleted or whatever, and
> link to where it was moved to.
Without seeing this in context of twiki.org I would hate that moving a
topic is a half way copy. When I rename or move I want the whole thing
including history to move with it.

A new "copy topic feature" or "copy and freeze old" would be the way.
But changing the move/rename to something in between would cause more
trouble than it would solve.

Kenneth

--
Kenneth Lavrsen,
Glostrup, Denmark

Michael Daum 08 March 2006 04:53

On Wednesday 08 March 2006 09:36, Crawford Currie wrote:
> Meredith raised the spectre of "frozen links" again on IRC the other
> day. This has been discussed before, but never acted on.
>
> Basically the argument is that if I have a link to ThisTopic, and
> someone movesThisTopic to ThatTopic, a link to ThisTopic should
>still work even though the topic has moved.

Actually Meredith proposed something different ... and I as Kenneth
would disprefer a "Move Topic" that is no real move. In fact
the problem is that moving a topic is the same as renaming it right now
and does not always match the user's intend: "move _away_" is more
likely a "move to trash" or "move to archive" whereas "rename topic"
will likely keep the thing in place but only lets say correct a typo in the
topic name or improve the topic name (users have problems naming topics).

What Meredith actually proposed is a way to have any stable urls at all
(correct me if I am wrong). This is not the Web/Topic url but some url
generated automatically and this should be doable using a PermalinkPlugin
which has a database being updated using the afterSaveHandler() that maps
the permalink to the current location of the topic registered for it on creation time.

So using an url like http://.../bin/permalink/ will not look so nice but
be permanently usable in any context outsite the wiki.

Even as I find the permalink and the Spooring of the resources
proposal quite interesting, can we focus on the very specific and
domain-constrained problem of the Attics webs for TWiki.org? There is
still a long time until these features are implemented, and Codev
needs a cleanup ASAP.

There is a lot of "stale_content" and "cruft", unrefactored
discussions, and several BugResolved" and "FeatureDone". Moving them
to an Attic web is no different that deleting or renaming them after a
refactoring of the content was done (and this has been done in the past).

At the end, it's quite simple to create the Attics web, move there the
stale content, and install FindElsewherePlugin in twiki.org so links
from outside still work.

Copy interesting topics over from Codev, replacing the original content in Codev with a link to the new web.

Add a BROADCASTMESSAGE in Codev pointing to the new web.

Thus Codev becomes an Attic, and Developer is lean and mean enough to be used.

C.

On Wed Mar 8 13:08 , Rafael Alvarez sent:

Even as I find the permalink and the Spooring of the resources
proposal quite interesting, can we focus on the very specific and
domain-constrained problem of the Attics webs for TWiki.org? There is
still a long time until these features are implemented, and Codev
needs a cleanup ASAP.

There is a lot of "stale_content" and "cruft", unrefactored
discussions, and several BugResolved" and "FeatureDone". Moving them
to an Attic web is no different that deleting or renaming them after a
refactoring of the content was done (and this has been done in the past).

At the end, it's quite simple to create the Attics web, move there the
stale content, and install FindElsewherePlugin in twiki.org so links
from outside still work.

So I assume the problem we're talking about arises when an external site links to a topic on twiki.org, whether with a hard link or with an interwiki link. Because the topic does no longer exist at the loctation, the visitor is lead to the "This topic does not exist" page.
It wouldn't be so difficult to check if the topic exists in CodevAttic web, and if so, show a message "This topic has been moved to MyStaleTopic".

Arthur

Michael Daum 08 March 2006 13:18
On Wednesday 08 March 2006 18:54, Arthur Clemens wrote:
>CodevAttic web, and if so, show a message "This topic has been moved
> to MyStaleTopic".

this is an important thing, we need to look at the implications
before we jump into creating a new web.

I do not think that creating a new web is necessarily the best
solution. Lets take a step back and see what the problem points
are. The key issue is that there is a lot of stale content in
Codev, the secondary point is that there is clutter and
unorganized content.

Another point to consider: Each "This topic does not exist"
message page does a topic name search in Codev, which is slow.
More importantly, it imposes additional load on the already
overloaded twiki.org server.

Peter

Meredith 08 March 2006 15:44

On Mar 8, 2006, at 3:31 PM, Peter Thoeny wrote:

> All:
>
> this is an important thing, we need to look at the implications
> before we jump into creating a new web.
>
> I do not think that creating a new web is necessarily the best
> solution. Lets take a step back and see what the problem points
> are. The key issue is that there is a lot of stale content in
> Codev, the secondary point is that there is clutter and
> unorganized content.
>
> I see these requirements:
> * Stale content needs to be out of the way, but accessible
Solved with either moving to an attic or creating Codev5

> * Cool URIs don't change
They won't change. The web they are in may, however

> * It should be easy to mark content as stale
It will be once we have a manageable web. It isn't with 4k+ topics.
> * It should be easy to mark useful content
Ditto
> * It should be easy to access useful content
Ditto
> * No new webs on twiki.org (use other means of organizing
> content)
I believe you are alone in this. At the very least, the consensus
is that we need at least one new web.

And i don't want to spend a month arguing about this. I really don't.

meredith

[Quoted text hidden]

Michael Daum 08 March 2006 16:07

On Wednesday 08 March 2006 21:39, Peter Thoeny wrote:
> Another point to consider: Each "This topic does not exist"
> message page does a topic name search in Codev, which is slow.
> More importantly, it imposes additional load on the already
> overloaded twiki.org server.

This is not a problem of managing "Stale Content". Is more a problem
of the tremendous chaos that is Codev.

I ask "What is the purpose of Codev"? I see it has several uses:
1. Brainstorm Ideas, that later are made into Features
2. Report Bugs and Issues
3. Serve as a place to store... interesting stuff (Howto's, links
to the competition, etc)
4. Track & Announce releases

As such, Codev has accumulated too much "cruft" over the years because
it's was overloaded" with too many responsibilities.

Now, we can see that some of the responsibilities of Codev are being
moved to other places:
2. Report Bugs and issues: This is being done in Support and Bugs
4. Track & Announce releases: Tracking is being done in the Bugs
web.

What I think that we should do is:
* Move all the Bug reports, feature done and release tracking
topics "out of the way" (Attic?).
* Either move all the Feature brainstorming discussion to a
Development web, or all the "interesting stuff" someplace else (I
vote for the former, as I think it's easier).
* Use each place for it's function, and only that function alone.

I strongly disagree that tagging content will help. It won't help the
WebChanges being flooded with content I don't care about while moving
out of the page the content I do care (no, I don't want to use the
RSS feed), nor it will help the severe performance impact in search
while looking through 4000+ topics, and won't help when I look for
information about the META PI and I need to scan 500+ unrelevant
topics.

Think about this: If you are looking for information that you've never
look at and don't know how to classify, what is your first choice:
Google or del.icio.us?

--
Best regards,
Rafael

[Quoted text hidden]

AJA 08 March 2006 17:29
Rafael Alvarez wrote:
> This is not a problem of managing "Stale Content". Is more a problem
> of the tremendous chaos that is Codev.

Rafael has hit on the point here.
Its not about tagging, its about loss of focus and confusion.

> I ask "What is the purpose of Codev"? I see it has several uses:
> 1. Brainstorm Ideas, that later are made into Features
> 2. Report Bugs and Issues
> 3. Serve as a place to store... interesting stuff (Howto's, links
> to the competition, etc)
> 4. Track & Announce releases
>
> As such, Codev has accumulated too much "cruft" over the years because
> it's was overloaded" with too many responsibilities.

Dead on.

And to this end, Peter's - now obsessive - stance of 'No More Webs' falls
short. Good design is about focus and clarity of purpose and objective.
The great strength of UNIX was, as Rob Pike so eloquently put it, was that
"each thing did one thing, only one thing and did it well". We have seen
that same clarity and focus emerge in the refactoring of the TWiki code
base into modules and functions whose purpose is clear and definite and
also follows Pike's dictum. Nothing strange about that; its been a
recognized principle of good software design for longer than programmers
practicing it have been alive.

What we're talking about here is fighting entropy.

> What I think that we should do is:
> * Move all the Bug reports, feature done and release tracking
> topics "out of the way" (Attic?).

When I first dealt with TWiki back in 2002 Codev was perhaps half the size
it is now. It was still very confusing for me - I had trouble determining
what was current, discarded, implemented ... Codev was and still is a
grab-bag. I hate to think how it must be for newcomers.

I note that one of the more vocal people for cleaning up this cruft is a
newcomer - Meredith. I think we should particularly pay attention to this.

> * Use each place for it's function, and only that function alone.

Ah, yes ...

> I strongly disagree that tagging content will help. It won't help the
>WebChanges being flooded with content I don't care about while moving
> out of the page the content I do care (no, I don't want to use the
> RSS feed), nor it will help the severe performance impact in search
> while looking through 4000+ topics, and won't help when I look for
> information about the META PI and I need to scan 500+ unrelevant
> topics.

Another good point.

And lets not forget that this 'high bar' to comprehension is going to
discourage new adopters.

Meredith 08 March 2006 19:10

What is this obsession with "no new webs"? One of the features of
TWiki is that there are multiple webs. This is a strength, not a
weakness.