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.
https://twiki.org/cgi-bin/view/Codev/TimDistro#WhyNewWeb
I also refactored comments, moving some stuff to TimFlames 
PeterMasiar - 01 Jun 2003
If I understand correctly the idea is: - 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,
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::
IMHO we have two groups of developers with somewhat incompatible goals:
Another area where "adventurous" wanted to go is to improve and make easier and more intuitive both , 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/ 
-- 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.
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:
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
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.
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 -- -- 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:
Looking at the requirements and the proposed process, we can
manage content in Codev like this:
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. 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]
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.
https://twiki.org/cgi-bin/view/Codev/TimDistro#WhyNewWeb
I also refactored comments, moving some stuff to TimFlames
| 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. |
- 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
-
- Much of TWiki is documented before it is developed, more so than many non OpenSource projects. -- JohnTalintyre
- 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
- 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 2003I 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.
- 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
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.
Another area where "adventurous" wanted to go is to improve and make easier and more intuitive both - user interface and
- installation and system administration
, 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/
-- 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.
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?)
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.
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/
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.
- Create a new web; call it Developer (or something equally intention-revealing)
- Leave Codev where it is, so existing links continue to 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.
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 -- -- 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)
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)
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. 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]
Topic revision: r50 - 2020-04-26 - PeterThoeny
Site map
Blog web
Create New Topic
Index
Search
Advanced search
My topics of interest
Changes
Major changes only
All tags
Notifications
RSS Feed
Statistics
Preferences
Community 
Readme first
Developers News
How you can help
Community roles
#twiki IRC
Lima Release
Feature Proposals
Bugs Changes
Categories 
Account 
Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.