OLD WORKFLOW: The following is using the old WebForm workflow. We are now using ChangeProposals. Forms for creating new topics should have been removed. See WebCreateNewTopic for alternate forms. Any topics listed here in dynamic tables will need to be converted from WebForm to the new ChangeProposalForm if you want to propose them for a release. Please read the preferred method to use for conversion.

Form Definition for the Codev web

Name:	Type:	Size:	Values:	Tooltip message:
TopicClassification	select	1		Classify a topic
TopicSummary	text	80		Short summary of feature/bug/idea
InterestedParties	text	80		Use for tracking and show key interested people
AssignedTo	text	40		Who is working on this - not usually CoreTeam
AssignedToCore	select	1		CoreTeam member working on this, will assist AssignedTo
ScheduledFor	select	1	, DakarRelease, CairoRelease, BeijingRelease, AthensRelease, TWikiReleaseSpring2001	Which release was/is this targeted for
RelatedTopics	text	80		Please add links to related topics
SpecProgress	text	10		completion percentage of the specification
ImplProgress	text	10		completion percentage of the implementation
DocProgress	text	10		completion percentage of the documentation

• Set ALLOWTOPICCHANGE = TWikiAdminGroup TWikiCommunityGroup

Would it be a good idea to have BugResolvedInAlpha? Bug would be set to BugResolved when put into a release.

-- JohnTalintyre - 27 Sep 2001

That is a good question.What is more useful and has less work? A new BugResolvedInAlpha status or above ImplementationDate?

-- PeterThoeny - 30 Sep 2001

I'm not clear, does John's BugResolvedInAlpha refer to another TopicClassification option. I see what you mean, Peter, but it still doesn't solve the dating problem...

ImplementationDate, unfortunately, was another temporary solution: it wasn't clear, even with the topic revision date, to what TWiki version a feature or bug comment referred. This new field is still only partially effective, because it's near impossible to identify which Alpha or Beta is involved. They could be all written out by date - I put in the slightly bizarre quarterly system for now.

Ideally, I think that, keeping the unique date approach versioning, there should still be a shorthand numeric code for Betas and TWiki Production versions (see more in UsabilityIdeas).

-- MikeMannix - 31 Oct 2001

---

TopicStatus is a new field that classifies topics according to the usefulness of content. Although a judgement call, the intended standard is very broad: only the most obviously useless info, or comment that's moved elsewhere, is tagged ClosedTopic or TopicToDelete. See TopicStatus for full list.

-- MikeMannix - 21 Nov 2001

---

ProjectGroup, a development from MasterRefactor, is an attempt to group TWiki feature-related topics into meaningful collections, by area of user-end functionality. Each project is organized and tied together through a jump-off project page.

-- MikeMannix - 03 Dec 2001

Please feel free to make comments on the individual ProjectGroup pages, based on the criteria outlined above: critique, add to definition, suggest alternatives/new ones. They are more end user/"author"-oriented, deliberately. If you have a problem with that orientation, please express it! Otherwise, try to take that point of view for comments and topic grouping.

• Remember, these are temporary categories, part of an overall Codev decluttering/refactoring project that will come to an end - they're not permanent classifications or dev areas or anything like that.

-- MikeMannix - 28 Dec 2001

Added GatewayTopic to TopicClassification.

-- MikeMannix - 01 Jan 2002

---

Based on CodevFields as a kind of catalyst for something that should've been cleaned up earlier, I've started to make the more end user/docs-oriented curretn ProjectGroup classification set-up out of the main categorization area by removing the TopicStatus field. That's clearly useless since there is no real team working on maintaining topics on that level, and there's no quick-lock mechanism (or archiving procedure) to make things like ClosedTopic mean anything at all.

ImplementationDate renamed ImplementationStatus (but not physically renamed just yet for impact on Changes). Added TWikiProductionRelease to replace individual production versions.

(In the same vein, thinking about this - not so much usefulness of ProjectGroup, but of the form usability itself for organizing pages, I just put in a one-field form in TWiki, to handle the new docs dev working pages - not part of official docs, that're beginning to pop up there. The tracking requirements are much simpler there, of course.)

-- MikeMannix - 14 May 2002

I reverted the ImplementationStatus field name back to ImplementationDate because if you edit an existing topic it will forget about the current ImplementationDate setting. A TWiki form does not work well with [[ImplementationDate][ImplementationStatus]] links for form field names.

If we rename "ImplementationDate" it should be done for all existing topics - wow, one BIG rename. "ImplementationStatus" would be a more accurate term, but IMO "ImplementationDate" is close enough.

-- PeterThoeny - 15 May 2002

Changes made as per RestructureCodevWorkFlow.

-- JohnTalintyre - 09 Sep 2003

Removed non specific ImplementationDate entries e.g. alpha, beta.

-- JohnTalintyre - 10 Sep 2003

Removed field ProjectGroup, as generally considered more confusing than useful. I have hard coded the results of some of the searches that checked this field. Note that data in this field will only go away as topics are edited.

-- JohnTalintyre - 27 Sep 2003

Is there interest in have a patch field add to this form? e.g would have checkboxes for each TWiki release, tick would mean that specific patch exists for this release.

-- JohnTalintyre - 27 Sep 2003

Agree on removing the ProjectGroup field.

Instead of a patch field, how about a "SeeAlso" or "RelatedTopics" field where TWikiPatches could be listed. This would clean up the topic text, e.g. "Category: TWikiPatches" text and "Related topics: ..." text could be moved into the new field. A search for all patches can be done easily as well.

Also, where needed, the ProjectGroup links could be moved into "RelatedTopics" field. We could even do a mass-rename of ProjectGroup to RelatedTopics, which would fix all forms in all topics. But that is too disruptive, touching 1693 topics!

-- PeterThoeny - 27 Sep 2003

Would "RelatedTopics" be a manually entered text field?

Isn't someone likely to be interested to know the patches related to their version of TWiki? Hence my suggestion for a list of TWiki versions, you indicate which patches exist for.

-- JohnTalintyre - 27 Sep 2003

Yes, "RelatedTopics" would be a manually entered text field. If it contains TWikiPatches (among other entries) you can do a AND search on the patches available for a particular release. A separate patch checkbox field would work as well, but makes the form larger.

Small detail on the sequence of fields, I think this would be more natural:

TopicClassification

InterestedParties

AssignedTo

AssignedToCore

ScheduledFor

ImplementationDate

RelatedTopics (in case added)

That is, move InterestedParties up to the second spot. First, someone is interested in a topic, then a developer works on it, then a core team member works on it.

-- PeterThoeny - 27 Sep 2003

If nobody objects, I will add the RelatedTopics text field to the form. There are some many topics that have it already somewhere in the topic. This field encourages people to think about related content!

-- PeterThoeny - 16 Oct 2003

I added the RelatedTopics field and moved the InterestedParties field up where it logically belongs.

Please provide feedback in RelatedTopics.

-- PeterThoeny - 17 Oct 2003

I removed the ImplementationDate field. It is obsolete as stated elsewhere. The BugReports have a table with the release the bug applies to.

-- PeterThoeny - 28 Sep 2004