Form Definition for the Mizar web

Name:	Type:	Size:	Values:	Tooltip message:
TopicClassification	select	1	Select one..., AnsweredQuestions, TWikiVsOtherProducts?, TWikiAddOnProduct?, MizarQuestion, MizarPitfall, MizarTools, MmlSuggestion, ErrorMessage, FeatureBrainstorming, FeatureEnhancementRequest?, FeatureToDo?, FeatureHack?, FeatureUnderConstruction?, FeatureDone?, FeatureNotSuitable?, BugReport, BugAssigned?, BugResolved?, BugDuplicate?, BugRejected?, DocRequest?, DocsToDo?, FeatureDocumented?, DefineTerm?, AdminTopic, GatewayTopic?, MathSC2000	Classify a topic
ProjectGroup?	checkbox	3	NoneOther?, ChangesProject?, CodeBaseProject?, CollaborationProject?, FeaturesProject?, InterfaceProject?	Classify by dev area
ImplementationDate?	select	1	N/A, TWikiAlphaRelease?, TWikiBetaRelease?, TWikiProductionRelease?, ------, TWikiRelease01Dec2001?, TWikiRelease01Sep2001?, TWikiRelease01Dec2000?	Pick a TWiki version

• Set ALLOWTOPICCHANGE = TWikiAdminGroup

Related Topics: WebPreferences, WebTopicEditTemplate, TWikiForms

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

-- WikiRoot - 04 Jul 2002
to top