Tags:
create new tag
view all tags

Proposed new Form and Classification System - (Fourth Draft)

Forms that support PostCairoDevelopmentModel. Note that these forms are not intended to coexist with the existing forms. They are intended to replace them, to give a far simpler and more general management system. (However they are designed to coexist with the present forms while they are being phased out.)

Contributors: SamHasler (main contributor), CrawfordCurrie, SvenDowideit, PeterThoeny, WillNorris

If a new classification system can be agreed upon SamHasler is willing to do ALL the work to transition to it, regardless of how much of Sam's own ideas it represents. That includes creating WebForms and classification topics, reclassifying old topics to be out of the way, changing searches and forms (e.g. BugReports) to use the new forms.

For the current implementation see BasicForm, WebForm and TopicClassification which is the main classification and state tracking field on both forms.

The following is the Fourth draft of the proposal. See also the:

This draft uses the TWikiForms syntax so that it can be cut+pasted into place when it's finalised. Headings denote topic names for form and field value definition topics.

BasicForm

Replaces WebForm. Unmaintainable/useless fields removed.

Name: Type: Size: Values: Tooltip message:
TopicClassification select 1 Select one..., AdminTopic, BrainstormingIdea, DefineTerm, GatewayTopic, NextGeneration, TWikiAddOnProduct, TWikiCommunity, TWikiAdvocacy, TWikiDeployment, TWikiDevDoc, TWikiDevQuestion, TWikiVsOtherProducts Classify a topic
TopicSummary text 80   Short summary of feature/bug/idea
InterestedParties text 80   Use for tracking and show key interested people
RelatedTopics text 80   Please add links to related topics

BasicForm TopicClassification select

BasicForm now uses an explicit definition for TopicClassification on the form itself rather than leaving it to the TopicClassification topic itself. This is to limit it to only those classifications that are relevant for BasicForm. Replaces TopicClassification pull-down. Note that the goal is to get topics into one, and only one, BasicClassification, so the current situation where the same topic could be in any one of half a dozen different classes goes away. There are still overlaps, but it's easier to select a single focus with this list.
Name Type Tooltip Message
Select one... option  
TWikiCommunity option Any subject to do with the TWiki community
TWikiDeployment option Any subject to do with TWiki in action
TWikiVsOtherProducts option Discussion of any type of relevant software
TWikiAddOnProduct option Programs, protocols, modules...anything that can be used with TWiki
TWikiDevQuestion option Specific queries about TWiki development
DefineTerm option A basic definition/external link for specialized term, protocol, product, company, person,...
AdminTopic option TWiki/Codev functional and/or descriptive topic (ex: WebForm, ActiveTopic; includes placeholders linking to same-named topics in other webs)
GatewayTopic option A top-level launch-point topic, linking all other Codev topics and threads related to a broad main area of TWiki development: overview, active core discussion, sub-topic excerpts, links to SummaryTopics for specific features and ideas.
NextGeneration option Ideas, possibly far out, for future TWiki architecture and development

ChangeProposalForm (Form)

A ChangeProposalForm is the basic form type for all requests/reports that may lead to a change, whether they are ideas, specific feature requests, patch proposals or bug reports. See TWikiReleaseManagementProcess for details.

Name: Type: Size: Values: Tooltip message:
TopicClassification select 1 FeatureRequest, BugReport, CodeRefactor, DocRequest Classify a topic
TopicSummary text 80   Short summary of feature/bug/idea
CurrentState select 1   State of ChangeProposal
CommittedDeveloper text 80   Name of the developers that has commits to implement or drive the feature implementation
ReasonForDecision select 1   The detailed decision for or against the proposal
DateOfCommitment date 15   Date the proposal got a committed developer (used for 7 day feedback period)
ConcernRaisedBy text 80   Name of a person that raised concern against a proposal, a name in this field suspends the 14 day rule
BugTracking text 80   Bugs in Bugs web that track implementation
OutstandingIssues text 80   Comma separated list of remaining issues before completion
RelatedTopics text 80   Please add links to related topics. If proposal was decided at release meeting add link to meeting minute here
InterestedParties text 80   Use for tracking and show interested people
ProposedFor select 1 , LimaRelease, KampalaRelease, JerusalemRelease, IstanbulRelease, HelsinkiRelease, GeorgetownRelease, FreetownRelease, EdinburghRelease, DakarRelease, CairoRelease, BeijingRelease, AthensRelease, TWikiRelease01Sep2001, TWikiReleaseSpring2001, TWikiRelease01Dec2000 Which release was/is this targeted for, Anyone can set this
TWikiContributors text 80   People who have contributed to the code or documentation of this ChangeProposal

CurrentState select

A ChangeProposal's CurrentState field is used for tracking its development status. It can take the following states:

Name Type Tooltip Message
UnderInvestigation option New proposal which is not yet been fully discussed or decided upon.
ReadyForReleaseMeeting option Discussion has finished and proposal is ready to be voted for at next release meeting
AcceptedProposal option Proposal was accepted and ready to be implemented
RejectedProposal option Proposal was rejected
ClosedProposal option Proposal was closed due to duplicate proposal or retracted proposal
UnderConstruction option For an accepted proposal documentation and coding started. Please give Item number in BugTracking field
MergedToCore option Has been merged to core or default plugin
ImplementedAsExtension option It was implemented as an optional contrib/plugin/addon, and doesn't need a core merge
ParkedProposal option Proposal needs someone to drive it

The workflow for this field is as follows: #CurrentStateWorkflow

UnderInvestigationAcceptedProposalRejectedProposalConsensusReachedSevenDayFeedbackPeriodConcernRaisedByReadyForReleaseMeetingUnderConstructionMergedToCoreParkedProposalImplementedAsExtensionDrawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)

WhatDoesItAffect checkbox

What subsystems does a ChangeProposal affect.

Defined in WebPreferences by WHATDOESITAFFECTCATEGORIES with values: API, Auth, Documentation, Install, I18n, L10n, Performance, Plugins, Prefs, Refactoring, Rendering, Search, Security, Skins, UI, Usability, Vars

Discussion

in ChangeProposalFormDefect ThomasWeigert said:

The categories in WhatDoesItAffect need some explanation. Also, for none of the bugs so far I have submitted I found a suitable item to select.

Please feel free to make suggestions for extra categories in this topic.

-- SamHasler - 14 Feb 2005

Design Decisions

Some quite lengthy discussion went into producing the forms above. The following is a summing up of the reasoning behind the design.

  1. Deliberately not used WebForm so that we can leave old topics untouched.
  2. There will be a new form ChangeProposalForm that will cater for all feature requests, bug reports and patch proposals.
  3. The old TopicClassification confused classification (what it is used for) and state (under construction, done, etc). TopicClassification has been simplified to only record what the type of the topic is, feature, bug, documentation request etc; The workflow/status elements have moved to a separate field. The TopicClassification on ChangeProposalForm only contains topic types that will require a workflow; all other topic types/classifications are only available in BasicForm now.
  4. CurrentState is a simplified and well documented status/workflow for all ChangeProposals. This means that there is now a unified workflow for bugs, features, code refactoring and documentation.
  5. The old ScheduledFor field is now ProposedFor because it was decided that anyone should be able to modify the field in order to retain some equivalent of a "Nice to Have" table whilst not making it sound like a promise that the change will make it into a release.
    If it is overused then topics can always be unproposed, and should if it hasn't got a CoreTeam priory and is still UnderInvestigation.
  6. Instead of a "Scheduled" and "Nice To Have" tables in a release topic there are be "Completed" and "Uncompleted" tables. The completed table would include all topics ProposedFor that release that were MergedToCore
  7. The Uncompleted changes will not be separated into CoreTeam sponsored changes and "Nice To Have"'s
    This change, along with the removal of the patch classifications so everything is a ChangeProposal, mean that there is only one queue for each release.
  8. There is no status for documentation separate from status of tasks in general. This is because documentation is an integral part of the process of implementation, and cannot be separated.
    Production of documentation before implementation will be encouraged by using a new templates. (similar to PatchProposalTemplate) that would have a heading for documentation before implementation. However it is not possable to always complete documentation before merging, see next item.
  9. The Progress fields were removed because the state should be all that is needed for tracking a topic to completion (at least as far as Spec is concerned) but the reality is that there will always be topics that need some followup, even after code has been MergedToCore. Also, the progress fields were often not updated and even when they were they often failed to reflect how much work was required to complete.
    With the DevelopBranch / MainBranch model we will have features that are accepted into the MainBranch but need follow-up work. If we do not have a progress indication we would need to split up a larger change request into lots and lots of smaller topics, which is not practical. The requirements are as follows:
    • a way to track all changes to completion, with many changes running in parallel
    • and with good real time reporting on progress
    • and with minimized chance to miss incomplete items
  10. A new OutstandingIssues field will keep track of pending items of features merged into the MainBranch. It should be comma separated list. Example: fails Test:TestCaseFooBar, doc not merged It could also be used for tracking before changes are merged as it is a useful indicator of where others can help out.
  11. The AssignedToCore and AssignedTo fields were removed so as not to discourage input by others. However they were also important for crediting the contributors (see autogenerated CairoReleaseSummary, used to update TWikiHistory before the release) so a TWikiContributors field was added for this purpose. This should hopefully not discorage others from contributing and also makes the crediting process more transparent.
  12. HasPriority allows the CoreTeam to indicate their commitment to each change and prioritise the order of ChangeProposals on the release topics. This should make it harder for high priority ChangeProposals to be overlooked.
  13. ChangeProposals listed on release topics would be sorted by the CoreTeam's priority (HasPriority). When a scalable desirability poll is introduced there will be a column for average desirability which can be used by the core team when evaluating priorities.

Conversion List

Checklist

To make the transition easier I'm not going to use BasicClassification, I'll leave the field as TopicClassification, but define it explicitly on the Form topics WebForm and BasicForm.

This is to save me having to convert all the topics that will remain on BasicForm. (currently 236, see Sandbox.CodevBasicFormSearch#Topics that will remain on BasicForm)

ChangeProposalForm will still use CurrentState.

  1. All topics to be created for ChangeProposalForm should use BasicForm, and be marked as either AdminTopic or DefineTerm.
  2. State and classification topics should have:
    1. Guidelines for usage of the state/classification
    2. A search for topics with the state/classification
  3. As well as a description matching the tooltip in the form definition topics should RelatedTopics

Topic creation should only be marked done (DONE) in the checklist when all of the above has been completed for the topic.

  1. DONE Create ChangeProposalForm topic from table above
  2. Create all topics listed in ChangeProposalForm with appropriate searches
  3. DONE Reclassify or Convert topics using BasicForm with a TopicClassification that will not be kept. Topics listed by Sandbox.CodevBasicFormSearch#BasicForm Topics to be reclassified or converted to ChangeProposalForm (Currently 62 topics)
  4. DONE Set BasicForm TopicClassification explicitly (in the BasicForm topic, not in TopicClassification) to: TWikiCommunity, TWikiDeployment, TWikiVsOtherProducts, TWikiAddOnProduct, TWikiDevQuestion, DefineTerm, AdminTopic, GatewayTopic, NextGeneration
  5. DONE Create ReleaseQueuesInsert as replacement for ReleaseFeatureTable searching ChangeProposalForm topics
  6. DONE Create ChangeProposal as a The documentation topic. It should serve as the entry point.
    • DONE Copy the workflow diagrams into it. (put on CurrentStatus and included)
  7. DONE Create Templates for each TopicClassification (base FeatureRequestTemplate on ChangeProposalTemplate?)
  8. DONE Create the Classification topics and put HTML forms on them for creating topics in each of the templates.
  9. DONE Create WebCreateNewTopic that includes forms for creating topics in BasicForm and ChangeProposalForm using the appropriate templates (and support questions in the support web?).
  10. Transition EdinburghRelease topics and check they appear correctly in ReleaseQueuesInsert
  11. Topics Scheduled for DakarRelease
  12. Review TopicClassification topics that will no longer be used and see how much work would be required to convert all topics still classified as them.
  13. Create OldWorkflowNote topic and insert into remaining topics listed in TopicClassification that will no longer be used
    • list them here before starting .....
  14. Delete or convert the following as they will no longer be used. (they are now TopicClassifications)
  15. Change the following to CategoryCategory classifications and allow them to be added using EDITCELL difinitions in the templates and HTML forms for new topic creation.

Additional conversions that could be made:

  1. CategoryRefactoring topics converted and classified as CodeRefactor.
  2. WebForm Topics to be reclassified or converted to BasicForm - Currently 450. These can be left for now, but the BasicForm TopicClassifications can't be removed from WebForm until these topics are converted to BasicForm.

Open Issues

TopicClassification naming

Is there a better name than FeatureRequest? Preferably an already existing topic name.

-- SamHasler - 01 Dec 2004

The name FeatureRequest is fine.

-- PeterThoeny - 04 Dec 2004

Hmm, maybe DocRequest and DocRequestTemplate would be better.

-- SamHasler - 04 Dec 2004

Classification of changes (Separate issue that shouldn't hold up implementing the form)

What determines what belongs to a release for bugs, features etc? For TWikiHistory I need the distinction between features/enhancements (with sub grouping Install/Rendering/Skin/Search etc) and bug fixes.

-- PeterThoeny - 12 Nov 2004

The IsBug tickbox of the WhatDoesItAffect field classifies a ChangeProposal as a bug report. "Install/Rendering/Skin/Search" you have some of that with WhatDoesItAffect, which is more than WebForm gives you.

I could add an AffectsInstall checkbox to it. Would AffectsInternationalisation and AffectsLocalisation also be helpful?

-- SamHasler - 12 Nov 2004

If you look in TWikiHistory, there are many more. Here is the list: Install, Internationalization, Authentication, Preferences, Skins, Rendering, Variables, Search, Plugins, UI, Code refactoring, Fix. The last one is for bug fixes. By convention we put that into the TopicSummary field. We can keep that convention. Or add all to WhatDoesItAffect list? At least we need a new AffectsSecurity option.

-- PeterThoeny - 13 Nov 2004

Prefixing the TopicSummary field is a good convention and should continue. However Topics can cover more than one of these classifications so to fully capture them the checkboxes are also needed. The TopicSummary can be used to indicate the primary nature of the topic. A small performance gain isn't as important in the history if the topic is mainly about new search functionality but it's still useful to know when planning what to include in a release.

Is it essential that all field values are WikiWords?

Comparing the list on TWikiHistory with WhatDoesItAffect and the suggestions on this topic:

TWikiHistory WhatDoesItAffect One word field name
Install   Install (Deployment?)
Internationalization   I18n
    L10n
Authentication   Auth
Preferences   Prefs
Skins AffectsContrib * Skins
Rendering   Rendering
Variables   Vars
Search   Search
Plugins AffectsContrib * Plugins
UI AffectsLookAndFeel? UI
Code refactoring IsRefactoring Refactoring
Fix IsBug IsBug
  AffectsDocumentation Documentation
  AffectsPerformance Performance
  AffectsPublishedAPI API
    Security
     

* AffectsContrib could be a plugin or a skin

It says in TWikiForms "(at present, the ... format is not supported)" which is a pity because [[AffectsInternationalization][I18n]] would work so much better.

Check out This example in the Sandbox web. Save/cancel it to also see how view treats the field values.

-- SamHasler - 14 Nov 2004

I'm fine with adding "AffectsXXXX" values for everything BUT I question the usefulness, for several reasons:

  1. How does the person filling in the field know what it affects?
  2. what does "affects" mean?
  3. the "areas" are not well defined; for example, to me, "Vars" and "Preferences" are synonymous.
  4. What is someone going to do with this information? What value does it have?
I think I'd rather have a topic called "AffectsInternationalisation" that lists all the changes that affect it, and not try to enumerate all possible areas in the form.

-- CrawfordCurrie - 18 Nov 2004

  1. It doesn't have to be right first time (WabiSabi).
  2. Impacts positivly or negativly.
  3. Looking at TWikiHistory "Variables" are TWikiVariables, but I conceed that there can be overlap in some of the definitions.
  4. I think we need to capture this information on the form for the following reasons:
    1. To help when prioritising ChangeProposals and when reviewing the queue close to a release as a reminder of why they have the priority they do. I'm thinking particularly of Security & Performance.
    2. To assist Peter in compiling TWikiHistory
    3. As a reminder to use these classifications and so they can easily be applied by anyone. So that they are more readily available than CategoryCategory classifications.

While I was writing the above I thought: Why not just use CategoryCategory classifications in the Related Topics fields?

It wouldn't be so obvious that they need to be applied but it saves having a lengthy checkbox field in edit. If I created CategorySecurity and CategoryPerformance etc. then it would be just as easy when generating the release queue from a search to pull these out of the RelatedTopics field.

-- SamHasler - 18 Nov 2004

If you say that "AffectsXXXX" is a wikibadge, then you could write a search like this one:

The following wikibadges for affected areas already exist: AffectsContrib AffectsDocumentation AffectsFunctionality AffectsLookAndFeel AffectsPerformance AffectsPublishedAPI . If this proposal affects one or more of these areas, please add the wikibadges to the proposal topic.

in the topic template. That would be a pretty clear hint.

-- CrawfordCurrie - 18 Nov 2004

I wouldn't want a have a search on every change proposal by default. Although it would be very helpful to have the list of CategoryCategorys on the edit page. Perhaps there should be a topic included by the edit template for inserting such web/site specific editing prompts. (What would be really nice: multi select boxes in forms for a field defined by a search.)

I was thinking it was better to stick to the CategoryCategory classifications. The main reason being there's no point in having two separate classification schemes. As it is we can already use CategoryRefactoring and probably CategoryUpgradeStrategy. People are then free to create whatever Categories they want and if they are useful for prioritisation we can check for them in the ReleaseQueuesInsert (Search for including in release topics like ReleaseFeatureTable). We could also have a topic that pulls in every category from the MergedToCore changes for the current release into a table to assist writing the TWikiHistory topic for a release.

-- SamHasler - 19 Nov 2004

I Didn't realise that Categories are searched for based on the topic starting with the text "CategoryDescription:" in which case the AffectsXXX topics could be reused but since there was some confusion as to what affects I wanted to avoid it and stay consistent with the majority of category topics already existing.

-- SamHasler - 19 Nov 2004

I like the idea of using the CategoryCategory links in the RelatedTopics field, that we can retire the proposed WhatDoesItAffect field. A small disadvantage is that it is not a simple checkbox selection process, but this is OK.

-- PeterThoeny - 04 Dec 2004

We could prepopulate RelatedTopics from checkboxs on a HTML form on topic creation. If EditTablePlugin didn't resolve variables when it saved we could keep them in the topic as =%EDITCELL{}%=s defined in variables.

-- SamHasler - 04 Dec 2004

I've created the BugReportTopicTemplate and FeatureRequestTopicTemplate with EDITCELL definitions defined in WebPreferences. Have I got the WHATDOESITAFFECTCATEGORIES right or should they be WikiWords?

-- SamHasler - 07 Jan 2005

Please also edit the table above

Multiple Templates (Misunderstading clarified?)

I'd planned on creating a single topic with HTML forms for creating any kind of topic with BasicForm or ChangeProposalForm and different HTML forms using separate templates for Bugs and Feature Requests. (It's on my #Checklist)

-- SamHasler - 12 Nov 2004

This is a usability question. I do not agree that a single entry point is a good thing because people come to Codev with something specific in mind, like filing a bug, adding a brainstorming idea etc. I believe we need to keep different pages with forms to fill in, also because of different template text.

-- PeterThoeny - 13 Nov 2004

Of course the forms should appear on separate topics, it's just useful to also collect them together on one page so that when people are creating new topics they realise that there are different templates they can use. I'm talking about having several forms on one page so that people can decide which one best suits the topic they want to create.

-- SamHasler - 13 Nov 2004

Too many fields on form / Form to large (resolved, some issues will have to be revisited)

But, I am concerned about the numbers of fields in the form, it is/will be over the practical limit (the WebForm is at the limit)

I find AffectedReleases, HaveWorkaroundFor, HavePatchFor and ProposedFor confusing. Any way to simplify/consolidate this?

We can simplify the form if we define more then one template topic and put some structure into the templates. For example, the current NewBugTemplate has a Environment table which tracks the TWiki version affected. In other words, move some form content that are not used for all types of content into tables which can be queried using $pattern(). If we change the existing Environment table of bug topic we have more work when reclassifying a support question into a bug or vice versa.

-- PeterThoeny - 12 Nov 2004

I think you're right about moving some of the fields into templates.

Since HaveWorkaroundFor and HavePatchFor would never both be ticked for the same release I've replaced them both with a single field HaveQuickFixFor. I also removed future release names from AffectedReleases, HaveQuickFixFor because they don't make sense for them yet.

I've just realised that AffectedReleases and HaveQuickFixFor should not use release names; but the dated format instead, i.e. TWikiRelease01Sep2001, including all the TWikiBetaRelease2004x10x30 types. Similar to the as "TWiki version:" field on the BugReport form. In all this would mean 13 checkboxes per field, and more in the future when other release come out.

AffectedReleases is only for IsBug ChangeProposals anyway so that's an obvious one to chop and put in the bug template as an %EDITCELL{ ... }%.

HaveQuickFixFor can also apply to features if patches are made for retroactively applying to old releases. If put on the templates it could be split back into Have Workaround For and Have Patch For.

With AffectedReleases and HaveQuickFixFor removed, and assuming you go for an extra TWikiContributors field there would be 11 fields on the form, only one of which is a checkbox field with a possible 8-11 boxes. Would that be short enough?

-- SamHasler - 13 Nov 2004

Number of form fields: I believe 11 (with one checkbox field that spans several lines in edit) is over the practical limit. Especially if we add the 3 progress fields back.

Moving some fields into tables in the template text has also the advantage that options lists can be initialised with a SEARCH, e.g. to compile the list of all releases. This reduces maintenance overhead.

For ease of parsing it is better to have a vertical | Key: | Value | table layout, not a horizontal one. But there is one limitation with the current EditTablePlugin: For maintainability, all field definitions should be included from a central topic (with %EDITtable{ include="" }%), but that currently does not work with the %EDITCELL{ ... }%.

-- PeterThoeny - 13 Nov 2004

Check out This example in the Sandbox web.

-- SamHasler - 14 Nov 2004

Bother mad!

I was hoping that we could use variables for EDITCELL definitions, but EditTablePlugin will resolve them and save the result back to the topic. (See what happened to DynamicEditCellTest)

-- SamHasler - 30 Nov 2004

I've removed AffectedContrib as it should probably be in the topic too.

-- SamHasler - 01 Dec 2004

When is something UnderConstruction

PeterThoeny said in DeveloperResponsibilities:

Do we need a new ChangeRequest with all its other states? To avoid clutter, why not use FeatureUnderConstruction for DevelopBranch? Once in MainBranch in can be set to FeatureDone.

Do we need an InDevelopBranch classification or should that be what UnderConstruction means?

-- SamHasler - 03 Nov 2004

That's what UnderConstruction means.

-- CrawfordCurrie - 04 Nov 2004

What about the PatchProposal, PatchAdjustmentRequired, PatchAccepted, PatchNotSuitable topics with patches attached? See #Conversion_List

These aren't in DEVELOP but there is/was code available.

Since there's only a handful of these I'm inclined to just mark them ConsensusReached and set the HaveQuickFixFor field. If no one comments before I get to them I'll just do that.

-- SamHasler - 11 Nov 2004

There is no replacement for BugDuplicate and BugRejected. (Resolved)

I'll hold off doing anything about BugRejected for now because I think we can live without it but if nobody comments soon I'll add the DuplicateChange state to CurrentState.

Bother! I'm going to have to redraw the flow chart again wink

Below is the list of options I've considered, please add to / refactor it instead of commenting.

-- SamHasler - 11 Nov 2004

These are process issues that should not affect the forms. 1 and 1 are the appropriate responses. We agreed that rejected states were inappropriate, and we need to encourage refactoring. Sure, CoolURIsDontChange, but since when was a duplicate bug a cool URI? Keep It Simple, I say.

UnderInvestigationConsensusReachedUnderConstructionReadyForMergeMergedIntoCoreImplementedAsContribNeedsARethinkDrawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)

The above needs to be refactored into #Design_Decisions

Voting and Desirability (Can wait)

Discussion moved to GradientsOfAgreement and SupportSparklines.

Discussion on the proposed new forms

Crawford said "Why do we persist in having two forums for reporting bugs (Codev and Support) - can we rationalise to one, please?"

I think the support web has it's uses but perhaps Support.WebHome should be rewritten to provide more links to installation topics as that is a frequent issue that comes up. It could also encourage users to provide feedback on plugin dev topics or file bug reports (although hopefully ChangeProposals will be able to handle bug reports for plugins).

-- SamHasler - 14 Sep 2004

from FeatureToDo:

Can we get these listed by priority, difficulty, and subsection area?

Priority is covered by HasPriority. A desirability will also be available once a scalable desirability poll is introduced. Subsection area is covered by AffectedContrib.

I don't think it's worth adding a difficulty field. It would probably stop otherwise solvable problems from being looked at. Something that one person sees as difficult may be very easy for another, and vice versa. I'm a strong believer that estimates should only be done by the people that are actually going to do the work.

-- SamHasler - 01 Oct 2004

I am more in favor of enhancing the current forms evolutionaly then revolutionary, mainly to avoid a MassDisruption with thousands of topics changed (Codev has now 3000 topics), and losing form values when editing an existing topic who's form has changed.

I would start first by documenting better the current workflow web have (as shown incompletely in WebHome), including a graphical picture (nice work SamHasler!). As a second step, enhance the workflow evolutionary, with minimal changes to existing forms. There is a balance between simplicity and full support for workflow. Semi-structured content that does not fit well can be managed with WikiBadges.

The usability of topics decreases if the form is getting long, too much scrolling involved. The existing WebForm topic is about at the limit.

The current BugReport system uses a hybrid between TWiki forms and TWiki table to store structured bug data. This is quite flexible and allows us to generate reports based on both, forms (e.g. scheduled for) and table (e.g. TWiki release version), respectively. We could expand on that, e.g. add content specific to a class of topics more to Edit Tables then TWiki forms.

There are different opinions on this, but IMO it makes total sense to keep tracking (bugs, ideas, features) in the Codev web because it allows for easy cross-linking, reclassification, refactoring and discussion.

The Support web is separate namespace for users, mainly to keep user questions and developer content separate. The "Environment" table in the AskedQuestions and BugReport have the same format, thus it is possible to convert a support question in the Support web into a bug report in the Codev web (happens rarely).

The missing piece is Plugins bug tracking. I suggest to use the Plugins web for that. Pros: Easy cross linking to related content, and keeps core and Plugins separate. Possibly name topics based on Plugin, e.g. CommentPluginBug1234 (with autonumbering)

-- PeterThoeny - 03 Oct 2004

FWIW I think what Sam has proposed is exactly that; evolution rather than revolution. The key thing is to simplify the current confusing forms, which unfortunately means losing some fields. Sam has stated he will do all the work required to transform Codev, which would of course involve ensuring that no existing data is lost. Right, Sam?

-- CrawfordCurrie - 03 Oct 2004

Yup.

I deliberately didn't use WebForm and won't be renaming the topic, ChangeProposalForm will exist alongside it. So there will be no possibility of form values being lost and most of Codev's 3000 topics won't need to be changed. Any topics that will have to change forms will be done manually by myself.

The way I see it, the minimum that will need to be changed straight away is:

See #Checklist for a more detailed list of what I will be doing.

To schedule other topics for a release they will have to have their form replaced with ChangeProposalForm. It should be possible to write a search to find topics modified after the form changeover that are still on WebForm. Myself and others can monitor that search.

I agree that it would be better to have plugin bug reports in the plugin web. I'd like to see them using the same ChangeProposalForm form in the Codev web. Would that cause problems? One reason for this is because I want to make it easy move bugs between the Codev and Plugins webs if they are created in the wrong web.

Once we are tracking bugs in the Plugins web I will create a template topic for insertion in every PluginDev topic with a form for creating bug reports and a search listing unresolved bugs.

-- SamHasler - 03 Oct 2004

Oh, and the PatchNeedsDocumenting field, while I think of it.

-- MartinCleaver - 03 Oct 2004

With the current spec we are going to lose the current NiceToHave functionality. People will still want to suggest ChangeProposals for a release. How can we let them do this?

On the other hand, how may topics that were placed in NiceToHave tables ever made it into the release?

If we had polling that could be used in generated tables (i.e. on BrandNew / WeUnderstand / UnderConstruction classification topics) to sort the topics by desirability then that would probably be adequate.

I don't think we should roll out the new forms until we have this issue sorted out.

-- SamHasler - 04 Oct 2004

These forms will also need to be used for Plugins.TWikiExtensionBugs so that releases can also schedule changes to Plugins.TWikiExtensions

-- SamHasler - 12 Oct 2004

Musings from IRC: 

   There's also the issue of whether Plugins bugs should be stored in the Plugins web or not
   I'm inclined to think they should
   but that causes problems with moving bug reports between Codev and the Plugins web
   because the WhatDoesItAffect field would have to be different for each web
   If you move a topic from one web to another, when you edit it does it still link back to the form it had in the old web or does it try to use a form of the same name in the new web?
   hmm, it links back to the old web
   SamHasler   but strangely the "Replace form..." button is now missing.
   ok, so there's no forms in the web I'm in, but it would be nice to have the option to remove forms from other webs

Also, forms from another web appear as Otherweb.FormName, and WikiWord field names are unlinked because they don't exist in the new web.

The reason I'm worrying about this is because I expect that with bug tracking in the Codev and Plugins that a significant number of bug topics will be created in the wrong web due to user unfamiliarity with standard practice or due to the bug being misdiagnosed as being in TWiki core/plugin when it is located in the other (or both?), which will lead to lots more moving of topics with form data between webs.

-- SamHasler - 12 Oct 2004

Just for the record: I suggested a date proposed field, but Sam says its not needed.

-- MartinCleaver - 21 Oct 2004

Changed HasPriorty from a text field to a label. I'd completely forgotten about TWikiFormWithLabelType.

As the topic says, there are ways to defeat the system, but if I implement something like the example it should stop casual/unwitting abuse of the field.

-- SamHasler - 14 Nov 2004

Sam, I believe all design questions for the new forms have been resolved in December, we should be ready to roll this out. This topic has been quiet recently, but it is important to roll this out soon since, without the new forms, it is currently very difficult to track what features are in MAIN vs DEVELOP.

-- PeterThoeny - 06 Jan 2005

Discussion of other forms

A form needs creating for capturing the structured data on CodevDocumentationProjectTemplate: using tables in the text is ineffective because it makes queries fragile, and the templates in any particular instance is quickly out of date WRT the master.

Added I've add an AlertOtherParties field? This is like InterestedParties but where you want to get the attention of a particular other individual, a generalisation of the PeterPleaseComment WikiBadge.

-- MartinCleaver - 02 Oct 2004

BasicForm
TopicClassification TWikiDevQuestion
TopicSummary New forms structure to support PostCairoDevelopmentModel
InterestedParties

RelatedTopics PostCairoDevelopmentModel
Attachments Attachments
Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdraw bugprocess.draw r4 r3 r2 r1 manage 14.7 K 2004-11-15 - 08:14 UnknownUser TWiki Draw draw file
GIFgif bugprocess.gif r3 r2 r1 manage 7.7 K 2004-11-15 - 08:11 UnknownUser TWiki Draw GIF file
Mapmap bugprocess.map r2 r1 manage 1.1 K 2004-11-15 - 08:12 UnknownUser TWiki Draw map file
Edit | Attach | Watch | Print version | History: r71 < r70 < r69 < r68 < r67 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r71 - 2005-11-27 - SamHasler
 
  • 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-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.