I'm starting to get confused (that's easy for me to do) about all the extra | new features that (can be) | (are) implemented in TWiki and how they can be implemented. This is a brainstorming page to see if we can work out a good way to deal with them (or if another way is necessary -- the TWikiPatches category is an approach to the same issue).

As an example, there is a patch or plugin that allows multiple words in the "definition term" of a definition list, so that a definition list item could look like this:

Multiple word definition term
   A group of words defined in a definition list item

I think it would be nice to have a table or something that perhaps looked something like this:

Feature	Patch	Plugin	Version	Comments
Multiple words in definition list	na	BlahBlahBlah	Beijing

This entry (which is assuredly not correct) would indicate that the indicated feature is not available via a patch, is available via a plugin, and is incorporated in the base TWiki features starting with the Beijing release.

If anybody sees value to this, please make suggestions on the format. It's just that I know there are a ton of features that could be implemented in a TWiki installation, features that I'd like to use, but I have a hard time keeping up with them and remembering how to implement each.

-- RandyKramer - 24 Mar 2002

The BeijingRelease page is the best guide to the features that are likely to make it into the upcoming release. Others are just ideas that may never get coded, or TWikiPatches that may not get included, of course. Your table is more informative but unless a feature makes it into the BeijingRelease type page I'm not sure it's a good idea to maintain this table separately (unless you want a sort of 'feature hopper' for those features that should be considered for a release).

Perhaps this table could be automatically generated from information in feature and bug pages on Codev, and similar info in Plugins, using FormattedSearch - this avoids the overhead of maintaining a separate page (already a problem with the 'known issues' pages). In fact, the known issues pages should perhaps be generated from a new BugReport state, e.g. BugVerified, which says 'this bug is not just a user issue, it really does exist and should be listed in Known Issues'.

The TWikiPatches page is solving a somewhat different problem, namely how to find those pages that have potentially useful code (for bug fixes or new features). However, a 'patch available' field in any new feature or bug page is a better way to address this.

Please comment in TWikiPatches on my proposed additions to the fields (for patches and bug priorities), as I think these would also make it somewhat easier to find patches and prioritise bug fixes.

One thing I'd like to encourage is patches that are in context diff format (i.e. diff -c oldfile newfile >foobar.patch) and are thus easily applied using patch -i foobar.patch. This makes life easier for CoreTeam members (so that patches are more likely to get into the core code) and for people who just want to get that feature or bug fix without waiting for core code updates.

-- RichardDonkin - 24 Mar 2002

Add a TopicClassification: Directory to be used to identify pages that are directories of pages on specific topics like Perl, Linux, Windows etc. Then add a page heading menu item "Directories" to bring up a list of pages in that classification.

-- DavidLeBlanc - 15 Apr 2002

That's interesting again -- somehow I missed RichardDonkin's comments.

Anyway, I think I confused the issue by mentioning Beijing -- I should have stuck with only previous releases -- my intent is not to predict the features that will come in any future release but pinpoint which release, plugin, or patch you need to get a specific feature.

I can't immediately see what DavidLeBlanc is getting at, guess I'll have to let that percolate in my head.

I guess I left some required information out of the table -- a patch or plugin may only work with a given release or later -- I should include columns to specify that.

-- RandyKramer - 15 Apr 2002

Missing comments is very common on TWiki, see the searches on my home page that are a simple form of ConversationTracking...

I think David is aiming for better navigation of Codev, by making it easy to find 'gateway' topics such as BrowserExtensions and EmailNotificationEnhancements (and maybe PerlTips, which is more of an 'external gateway'). In fact, GatewayTopic already exists, though it's not used very much - perhaps if there was a prominent link to GatewayTopic from Codev.WebHome?

I would definitely support a 'directory' type TopicClassification as part of a revamping of the current set of WebForm fields - I find the ProjectGroups are too broad, and would prefer something more specific to feature areas, as in the earlier DevTypeForm used in Codev, which had DevelopmentAreas such as Usability, Security, Installation, Windows, etc. Perhaps ProjectGroups could be considered optional, and DevelopmentArea reinstated?

I'm also not sure of the value of TopicStatus - I don't go looking for active or closed topics, and it's only occasionally of interest.

ImplementationDate is useful, but I found it quite confusing as to whether it was the planned date or actual date - and of course releases such as TWikiAlphaRelease are not dates, and change in meaning as an alpha gets into a full release, and another alpha arrives...

-- RichardDonkin - 15 Apr 2002