extract_stuff1Add my vote for this tag stale_content1Add my vote for this tag create new tag
, view all tags
The current fields on Codev need some improvement - the use of threads such as FeaturesProject and ChangesProject is very broad, making it hard to find related features. There are so many topics in FeaturesProject that I can't really detect a common theme, and the term 'project' suggests there is a goal and start/end date for such an effort, which is not the case. I realise MikeMannix has put a lot of effort into this, but I don't feel that this model has really taken off, and I find the older DevTypeForm is actually more intuitive when assigning field values to a new topic as well as when browsing for features. See TWikiExtraFeatures for some more discussion on this.

The ImplementationDate is quite confusing (is it the planned or actual date of implementation?) Also, there should be a field that indicates a patch is available for a given bug/feature (as in TWikiPatches).

One meta-issue is that it seems that every time this issue is raised, it seems to fail to result in any real discussion or action - ironically, the volume of discussion in Codev tends to mean that the topic dies out, even though a better set of fields for Codev would make it easier to handle this volume. Maybe this discussion should take place on the TWiki web, which is much lower-volume?

-- RichardDonkin - 12 May 2002

I certainly don't find TopicStatus or ProjectGroup very useful. I believe ImplementationDate is the date of implementation - the idea being you can know if a particular version has a fix or feature in.

-- JohnTalintyre - 13 May 2002

Well, months later, comments! This was started ages ago, at the end of Sep, it was temporary, and I asked about it first, didn't want to get in the way, because it was mainly for my own use. It says on the Codev home: be aware that this is NOT part of Codev's main organizational structure. I'd crammed in so much TWiki reading in three weeks while helping with the Sep-01 release, and noticed a few threads that kept repeatomg in different places, but never coming together. With all that stuff fresh, IF I'd gathered a good number of pages under my headings, I would've written a likely useful summary, with links.

Problem was, SF crshed right then, for three weeks, and by that time, remembering where hundreds o little comments were was well long gone from my head. After that, it became just a big job that I wouldn't have started otherwise. I seriously doubt I'm gonna re-read the 200-300 topics already collected - which I had originally and more.

The organization, not suitable for indexing features individually, is valid on a practical user end.

Like, ChangesProject was reflecting the several related issues to do with being able to get alerts, spot changes in the body of text, not have changes marked when doing maintenance, etc... These are still issues: like, I've racked up 100+ changes this month, mostly minor, but skewing the changes list. So, it's not useful - too broad - as a specific features workflow set-up, but it makes sense from the user's side - are you annoyed to see 50 posts marked as changed, but probably not...

CollaborationProject was another obscure, half-discussed area, not really buy-in, but how to get people involved. There was the original Ward Cunningham high-concept stuff - basically, a higher order of people are required for good Wiki. The outline of that is reflected in GoodStyle (but who uses that? and if not, why is it a pop-up in Edit?). I've seen at least a few gateway pages started, but none carried on. Also, Codev has grown from 800 pages when MastorRefactor started, to over 1200 now So Collab made sense from a docs POV, because there were lots of comments not really tied together, and things were clearly piling up here, for one.

Anyhow, back then, I thought that summarizing and seeing if there was consensus on points would help all 'round. For new visitors, of all technical persuasions, as well as the dev team. It's all explained right there. And I didn't want it taken wrong - being a NON-programmer and all - as my idea of a master plan.

The ImplementationDate IS quite useless - that's also noted if you take a look. There's no real tracking of which beta or other version anything applies to. That's not up to me. TopicStatus - useless, too, since it's not used. The idea originally being there'd be some sort of refactoring and archiving. There were a few comments a while back that seemed to find the whole idea useful, but as a solo project, too much.

Anyhow, I'll wipe it out - the doomed MasterRefactor - in the next day or two. It's been annoying me, anyhow, not done. Comments four-five months ago would've been helpful, though <G>!

-- MikeMannix - 13 May 2002

I was just trying to get a better set of CodevFields, with some way of more easily organising topics into smaller groups, based on subjects.

I agree that TopicStatus is not really used, so it should be dropped IMO.

I figured out the meaning of ImplementationDate a while back, but it is somewhat confusing to new users. Something like ImplementedIn would be better - the use of the passive makes it clearer this is not a 'scheduled for' field. It would be worth considering a separate form for bugs and features, perhaps - if we had a separate form, you could have FixedIn for bugs and ImplementedIn for features.

A field that describes the release that a bug AppliesTo would be useful - this is already in the text for BugReport but it seems like a key field for sorting and searching.

I'm not sure that just wiping out the MasterRefactor is a good idea - it's just that it is currently the only way of organising topics using CodevFields that are subject based. I agree that solo refactoring is far too much work - in fact, even a single large topic like TWikiOnWindows is much more work to refactor than it was to write afresh in DocumentMode as WindowsInstallCookbook.

-- RichardDonkin - 14 May 2002

Codev has two types of content that seem to work better together than they would apart, but have different classification needs:

  • brainstorming - freeform discussions that thread through multiple topics, can stick pretty close for a specific feature or functionality, or get quite broad, and don't usually stick to topic titles, often with multiple general discussion areas covered in a single topic (typcial refoactor candidates).
  • coding projects - dev discussion and progress updates for very specific code additions and bug fixes (which could be a third form, defaulted to with creation of a bug report), and contained in one or two clearly titled topics

SUGGESTION: __Use the multiple forms option!* It's actually already partially in place: DevTypeForm is available in place of WebForm, the current form in Edit.

  • more general end-user/administrator oriented form for brainstorming stuff
  • tighter, automated production form for actual development, with assigned developer, dates, etc - as suggested by PeterThoeny.
  • shared fields like TopicClassification, in both types of form - whatever's relevant in both contexts

-- MikeMannix - 17 May 2002

I agree about the concept of brainstorming vs coding projects, but I don't think the word project should be used for the latter - we don't work in a project fashion on TWiki (i.e. defined goals, start date, end date, project plan, project control), so it's best to use some other term.

There's another very important sort of content, which is gateway topics and associated info pages (sometimes linking into brainstorming/coding topics but sometimes linking to pure info topics such as WebLogs). For some examples, see PerlTips, TWikiDebugging, BrowserExtensions, OpenSource, RichSiteSummary, ActivePerl, etc. These often end up as DocumentMode topics, and are useful as references when discussing these issues in other topics of course. Some are also referenced from the Support web.

These gateway/info topics are often lost in the flow of discussion topics, so it would be very useful if GatewayTopic could be prominently linked from various places in Codev - if structured properly they'd be more useful as an 'index' than WebIndex, which is too big to be usable on Codev.

The term GatewayTopic is a bit unclear in meaning - something like DirectoryTopic or InfoTopic might be good (latter would cover the 'non-gateway' topics as well.) See TWikiExtraFeatures for some more discussion on this. It might also be useful to reserve InfoTopic for non-gateway topics - currently we tend to use DefineTerm which is not very obvious, but is not too bad.

What would be really useful is if the GatewayTopics acted as 'reviews' of the various specific coding/brainstorming topics, e.g. grouping them together and classifying them as in EmailNotificationEnhancements. This would avoid the information overload of FeaturesProject et al, whereby there are so many topics. Of course, someone has to write these, and IMO they should be more narrowly focused to avoid them being too big (e.g. EmailNotificationEnhancements).

Using more than one form will probably be confusing, unless all of them are designed to work together - DevTypeForm should be removed and a new form (or forms) designed to fit the requirements mentioned here.

-- RichardDonkin - 18 May 2002

I'd like to suggest a few administrative flags:

I was also thinking that there should be some way of collectively lodging a RefactorRequest, perhaps as a variant of the CommentPlugin with buttons providing automated text inserts. A bar of buttons could be displayed under each edit. The buttons could include 'OffTopic (NeedsRefactor)' 'IAgree' 'IDisagree' 'IDontUnderstand' etc. It could change readers who passively read topics with a means to have their say. The text could be inserted into tables under each edit.

Somewhat ironically that last comment was arguably off-topic!

-- MartinCleaver - 04 Sep 2002


-- MartinCleaver - 06 Sep 2002

There is a more recent discusion which touches on this Topic in RestructureCodevWorkFlow.

-- SamHasler - 04 Jun 2003

Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r9 - 2003-06-04 - 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.