Tags:
extract_idea1Add my vote for this tag create new tag
, view all tags
Dear CoreTeam members,

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.

http://twiki.org/cgi-bin/view/Codev/TimDistro#WhyNewWeb

I also refactored comments, moving some stuff to TimFlames wink

Developer Create? Web name Comments
PeterMasiar Yes Tng here is why
MartinCleaver Yes Tng  
AntonAylward Yes   Codev needs to be split even as it stands
ArthurClemens Yes   Can give more focus, will do no harm.
RandyKramer Yes Tng is ok Arthur (above) said it well
MichaelSparks Yes No There is a need for more than one web and not for a "TNG", the content of Codev web is IMHO too diverse see end for comments
RichardDonkin Yes Tng? Tng is a good idea, also need improved CodevFields at least
AndreaSterbini Yes Tng We need a place to work on TNG and to leave a friendly space for FriendlyForkers
DavidLeBlanc Yes Tng Need a good front page on Tng to segment the work areas. "SubWebs" would be good here to mirror the main TWiki tree as development procedes.
       

PeterMasiar - 01 Jun 2003

If I understand correctly the idea is:

  • Codev - covers code changes to the existing TWiki.
  • Tng - covers code changes for a future TWiki, presumably with a very different codebase, otherwise Codev would be used

Codev problems:

  • Codev web is nearly 2000 topics
  • A lot of the coding problems comes from teh complexity of the Twiki interfaces and the lack of
docuemntation. Like so many Open Source projects, the response of the developers has been to code first and docuement after
  • 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

-- JohnTalintyre - 01 Jun 2003

Tng features

  1. 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.
  2. 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

AntonAylward

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.

-- JohnTalintyre - 02 Jun 2003

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.

-- AntonAylward - 02 Jun 2003

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.

-- MartinCleaver - 02 Jun 2003

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.

Whatever, a new web sounds like an ideal place for that.

-- AntonAylward - 02 Jun 2003


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...

-- RichardDonkin - 02 Jun 2003


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.

If this is done, we could first start by creating
TWiki > Codev > Tng (or whatever)
and below:
TWiki > Codev > Tng > GeneralDesign
TWiki > Codev > Tng > CpanInstallingIssues
etc.

As a fairly newcomer: is reparenting allowed as refactoring job?

-- ArthurClemens - 18 Jun 2003

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.

-- MattWilkie - 19 Jun 2003

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.....

-- CrawfordCurrie - 19 Jun 2003

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.

Both methods can have their place, they don't bite each other.

-- ArthurClemens - 19 Jun 2003

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".

-- CrawfordCurrie - 19 Jun 2003

The categories system was replaced with TWikiForms, topics using old categories are automatically upgraded when edited (assuming a form replacing the categories text file is present).

-- JohnTalintyre - 19 Jun 2003

Conversation refactored to PleaseCreateNewCategories

-- MartinCleaver - 06 Jul 2003

Tim Reily's article about architecture of participation:

  • 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.

-- PeterMasiar - 14 Jul 2003

I wholeheardly agree with the proposal to create a new web to start developing TWikiNG/TWikiOO.

Moreover, this space would be a good place to show the richness of the development that is ongoing around TWiki. This would show also that TWiki already goes beyond his current state of development.

Several developers are nowaday working on TWiki extensions (TWikiClones) ad I think that it would be a good idea to cooperate with them to design the new TWikiNG.

I embrace the TNG (TWikiNG) web proposal and I suggest that (as others already have said):

  • we make a CallForFriendlyForks to collect the interest and the cooperation of TWikiClones/FriendlyFork developers
  • we acknowledge the active contribution of such developers
  • we use our best skins (GnuSkin, or KoalaSkin or what else) to show that TWiki is beautiful as much as other content management systems
  • we start working on the new Object-Oriented DevelopmentVersion of TWiki:
    • to make more easy the collaboration among developers (have you noticed how the Plugins concept worked well?)
    • to gain in efficiency with mod_perl and aggressive caching
    • to allow the user a wider choice of template systems, storage layers ...
  • we use better the Perl modules in CPAN
  • we use both CPAN, RPM, ZIP and Debian packages for distribution

Just my 2c

-- AndreaSterbini - 05 Sep 2003

Added my vote -- DavidLeBlanc - 05 Sep 2003


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 smile

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.

And if this will not happen - see most of you a year from now at http://www.kwiki.org/ frown

-- PeterMasiar - 06 Sep 2003

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.

-- JohnTalintyre - 07 Sep 2003

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 smile

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.

-- PeterMasiar - 07 Sep 2003

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.

-- JohnTalintyre - 07 Sep 2003

Lets look at the bigger picture.

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.

The TWikiKernel and TWikiDistributions scenario has many advantages over a FriendlyFork, like decreased code merging efforts, efficiency and scalability (by people). The focus on the TWikiKernel is to extend the API to support the different TWikiDistributions.

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:

  • Does the CoreTeam has enough resouces?
  • 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.

At this time I would like to see the majority of CoreTeam members and CodevCommunity members focus on the CairoRelease. That is, focus on EnhancementsToThePluginAPI and EnhancedSkinHandling.

-- PeterThoeny - 08 Sep 2003

Better late than never - I hope smile

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.

-- JohnTalintyre - 12 Sep 2003

How about a mechanism to promote TWikiApplication / ExampleWebFormApplications? i.e. allow authors to create their own webs to show off what they have done?

-- MartinCleaver - 30 Oct 2003

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.

-- RaymondLutz - 11 Nov 2003

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".

-- JohnTalintyre - 12 Nov 2003

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.

-- RaymondLutz - 19 Nov 2003

In KickStartingTestcaseDefinition Crawford has mentioned that he'd like a new web for testing. I agree.

I also note there is a Core web - not that mere mortals can use it.

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.

-- MartinCleaver - 22 Oct 2004


Footnote: Please comment

  • above about (old) discussion about creating new web (for OO Twiki or something you feel is important),
  • at TWikiForGForge page about creating FriendlyFork or new new TWikiDistribution to integrate Twiki and GForge.

Martin Cleaver <mrjcleaver@gmail.com>


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!


Crawford Currie 08 March 2006 03:36 Colas Nahaboo wrote: 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)

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 moves ThisTopic to ThatTopic, a link to ThisTopic should still work even though the topic has moved.

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.

Follow up in FrozenLinks

C.


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 moves ThisTopic 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.

Micha.

-- -- Michael Daum -- http://jojowiki.dyndns.org


This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___________________________________________

[Quoted text hidden]


Rafael Alvarez 08 March 2006 08:08

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.

-- Best regards, Rafael

[Quoted text hidden]


Michael Daum 08 March 2006 08:24

On Wednesday 08 March 2006 14:08, Rafael Alvarez wrote: > At the end, it's quite simple to create the Attics web, move there the
> stale content,

I second this.

> and install FindElsewherePlugin in twiki.org so links
> from outside still work.

Ehm, no. The FindElswherePlugin finds topics within a twiki installation.

-- -- Michael Daum -- http://jojowiki.dyndns.org


[Quoted text hidden]


Martin Cleaver 08 March 2006 08:28

How about we make multiple whiteboards per topic and move stale content into the attic whiteboard?

We need that anyway to implement the agreed summary/discussion view found in MediaWiki.

Regards, M.

[Quoted text hidden]


Rafael Alvarez 08 March 2006 10:34 Hello Michael,

Wednesday, March 8, 2006, 9:24:28 AM, you wrote: >> and install FindElsewherePlugin in twiki.org so links
>> from outside still work.

> Ehm, no. The FindElswherePlugin finds topics within a twiki installation.
>
You're right. My mistake.

-- Best regards, Rafael


[Quoted text hidden]


Crawford Currie 08 March 2006 11:58

There is what may be a more pragmatic, short-term, approach.

  1. Create a new web; call it Developer (or something equally intention-revealing)
  2. Leave Codev where it is, so existing links continue to work.
  3. Copy interesting topics over from Codev, replacing the original content in Codev with a link to the new web.
  4. 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.

-- Best regards, Rafael


Arthur Clemens 08 March 2006 12:54

On Mar 8, 2006, at 9:36 AM, Crawford Currie wrote:

Colas Nahaboo wrote: On 3/7/06, Arthur Clemens <aclemens@xs4all.nl> 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)

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 moves ThisTopic to ThatTopic, a link to ThisTopic should still work even though the topic has moved.

Within a TWiki, links can be updated when a topic is moved. So all links to MyStaleTopic become links to MyStaleTopic.

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".

... adding this to WebTopicViewTemplate.txt

This topic has been moved to CodevAttic.PleaseCreateNewWeb.

-- -- Michael Daum -- http://jojowiki.dyndns.org


[Quoted text hidden]


Peter Thoeny 08 March 2006 15:31 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
  • Cool URIs don't change
  • It should be easy to mark content as stale
  • It should be easy to mark useful content
  • It should be easy to access useful content
  • No new webs on twiki.org (use other means of organizing content)

Organizing content is a taxonomy/folksonomy question. A while ago I posted a proposed process/tool to manage stale content, http://twiki.org/cgi-bin/view/Codev/ManageStaleContent

Looking at the requirements and the proposed process, we can manage content in Codev like this:

  • Tag useful content
  • Tag stale content as "stale_content"
  • Enhance the Plugins API with search result hook
  • Filter out stale content from a default search
  • Make a search switch to include stale content in the search
  • Do a scripted tagging of very stale Codev topics (something like: Older than x month, and looked at by an authenticated person for y month)

IMPORTANT: Please follow-up on this discussion in ManageStaleContent.

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.

Hm, actually no.

This topic has been moved to CodevAttic.PleaseCreateNewWeb.

is just a one file lookup.

> > Organizing content is a taxonomy/folksonomy question.
> > * Filter out stale content from a default search
> > * Make a search switch to include stale content in the search

THIS is expensive.

-- -- Michael Daum -- http://jojowiki.dyndns.org


[Quoted text hidden]


Rafael Alvarez 08 March 2006 17:04 Peter,

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.

[Quoted text hidden]


Edit | Attach | Watch | Print version | History: r49 < r48 < r47 < r46 < r45 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r49 - 2006-03-09 - MartinCleaver
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.