Tags:
create new tag
, view all tags

The Original Coffee Break Page, replaced and waiting for splitting up into Codev topics and general refactoring. NOTE: All of the original CoffeeBreak content, minus the separate dev discussion tangents, is being moved over to the new CoffeeBreak. This has already begun. So basically, it'll soon be the OG CB....



As you know, this summer we had a boost in features, and with that a time of a not so stable code base. Now we are almost back to normal, but not quite. A not so stable code base is untypical for TWiki, most previous Betas used to be stable and could be used for production. Going forward, key points we need to focus on to bring TWiki back to "normal" and keep it that way:

  • Agree on spec of new features in advance.
  • Code carefully.
  • Before you put code canges into TWikiAlphaRelease: Test all parts that you might be affected by the code change.
  • Review CVS commit notfications and reply to the author in case you found an issue.
  • Release often and early.
  • Introduce more unit tests.

-- PeterThoeny - 31 Aug 2001

It's really good to see the new release, I'll get our guys at work to have a bash at installing it. So - thank you all! I appreciate how much effort it takes to get things tucked and tailed to get out the new release.

Meanwhile, I am pleased to see the efforts that MikeMannix is putting into sorting out the references in the TWiki web. I also think that:

  1. It would be good if some topics can be retired into Trash now, and consolidated into other topics.
  2. It would be good if Mike's changes, if not content additions, could somehow not show in the last changes section. I guess this is a general problem that it would be nice to solve. On some TWikiPlatforms this could be done by reinstating the previous datestamp so that it sorts to its existing place instead of to the end.
    (Yeah, it looks a bit mad when you see one person's name on everything all the time - checking 'Minor changes' fixes that for WebNotify, at least. Then again, in this case it'll die down soon - on any busy web that's also maintained a lot, it could be an annoyance/problem, but only if someone's correcting simple typos. Anything less trivial than that - refactoring, correcting links, whatever - is probably worth noting in WebChanges; the editor can decide if it's also worth a WebNotify. Well, here's to another revision... -- MikeMannix - 19 Sep 2001)

-- MartinCleaver - 19 Sep 2001

We already have the minor changes checkbox. This affects what is written to the .changes file. Perhaps we should allow search to use this instead of file timestamps for recent changes.

-- JohnTalintyre - 19 Sep 2001

Certainly I was thinking of the minor changes checkbox. I4d say that the meta data should contain the authoritative record of when the last changes for each topic happened. Also I4m starting to think that changes might be thought of as types:

  • refactor content
  • add content
  • minor formatting change

The reason I suggested fudging the file datestamp was for efficiency. I guess that searching either the meta data or the .changes files in order to get the WebChanges page is likely to become very expensive as WebChanges is, at least for me, the most commonly invoked page.

-- MartinCleaver - 19 Sep 2001

In some cases, using an %INCLUDE% to publish common messages on multiple pages is useful, and avoids committing trivial page changes (as well as saving a lot of time). See TWikiTemplates, or any other docs page. This is a simple approach for simple situations.

Thinking of types of changes, only really minor typo corrections are "trivial". Rewording a sentence for clarity may seem minor, but it's easy to change the sense of a post by changing a few words, which is not trivial - in editing a magazine, say, copyediting is expected, but in TWiki collaboration, nuance should be preserved in the short term, and changes noted. So it seems a matter of admin style: unless it's a hard news or grammar web, the admins shouldn't be obsessively changing typos all the time. It'd be a waste of energy, and counter to the whole freeform collab concept. And the revision control should be kept straightforward (tiny changes with no record of them is...a little creepy).

I guess that means, I don't think there's problem with WebChanges noting all...web changes. There could be a problem with the web changers, which should be easy to fix.

-- MikeMannix - 19 Sep 2001

I think it is appropriate that all web changes be recorded and available in the change record, but:

  1. Some of the discussion above was about the WebNotify email, which does not list changes marked as minor. This is a good thing (even though I usually review the email, but then review the changed pages by calling them from WebChanges).
  2. On another page, it was proposed that some additional tools be made available which include the ability of the editor or contributor to mark changes as minor (and perhaps other categories), along with the ability of the reader to choose to see change lists that do or do not include the minor changes. (Or to see all changes along with a notation as to whether the changes are minor or not (in the judgement of the editor/contributor). (That page (see DiffsHardToRecognize (and WordDiff)) also included a wish that diffs would be available in "word" style -- with deletions hashed out, additions underlined (or bold).)

(Uh,oh, isn't the automatic numbering working, or am I using the wrong markup? Skip the blank line between the paragraphs and it works -- HansDonner - 21 Sep 2001 )

PS: I like the idea of using %INCLUDE% to incorporate the same message on multiple pages. I'm unclear as to whether those pages are marked as changed -- I guess I'll have to test it out.
Only when you add the %INCLUDE% itself. And a couple of variables like %INCLUDINGTOPIC% can come in...handy! -- MikeMannix - 20 Sep 2001 Mike, Thanks!

-- RandyKramer - 20 Sep 2001

Just realized, that's a whole lotta pages here in Codev that I don't recall touching, trivially or otherwise. Most of those pages got tagged through Rename/move - I moved a bunch of topics to Plugins, and they're the referring pages that got updated. I'd count automatically updating a link to keep it pointing where it should as even more trivial than correcting a typo. NOT registering a change in this case would probably be OK, because it's almost misleading - there was a change, but it didn't affect content, and no-one even actually viewed the changed pages. Renaming/moving just one heavily referred-to page in a big web would change the profile. Say 30-40 topics that hadn't been touched in over three months appeared updated, it would give a completely wrong perception of activity, for one... It's an easy way to look real BUSY...

-- MikeMannix - 20 Sep 2001

So, it's bug. In any case, I'd put forward that minor changes shouldn't appear in the WebChanges view as by their nature the author is proclaiming that they are not interesting and the reader of WebChanges only wants to see interesting changes.

-- MartinCleaver - 21 Sep 2001

Great to see the new TWiki release, my thanks to all the developers! I agree about the minor changes, should not appear in WebChanges typically (although perhaps this should be configurable by the viewing user).

As for making minor typo changes a lot - this is a matter of taste, the only thing that stops me correcting other people's typos is time. (A SpellChecker would help quite a bit.) I do often fix typos when I'm going in to edit the page for some other reason.

-- RichardDonkin - 21 Sep 2001

Shouldn't Support.WebTopicEditTemplate include the following? I think it used to at one point before the upgrade:

  • Web browser:
  • Client OS:

There are some support questions which clearly relate to BrowserIssues, as always - this would help to clarify them.

-- RichardDonkin - 23 Sep 2001


Is it just me, or has raw been deleted from the action bar in view.tmpl in the latest release?

-- HansDonner - 26 Sep 2001

It any other options are to be found when select more. Or you can just add raw=on to the view url (raw=debug) if you want to see the meta information.

-- JohnTalintyre - 27 Sep 2001

I think the view raw should be on the main bar, because it will allow somebody do some handy cut & paste...

Also note the topic is locked msg: "To look at the text without editing the topic click on the View raw text link."

-- HansDonner - 28 Sep 2001

Maybe an idea to get some DiscussionsRetired topic? This can be the place for topics that are continued in another topic...

-- HansDonner - 28 Sep 2001

It would be useful if anyone could rename (most) topics in Codev and other TWiki.org webs - e.g. I wanted to rename UrlCorruptionWithMozilla to something more accurate, having refactored that page, but the access controls don't allow me to.

-- RichardDonkin - 29 Sep 2001

This is a big usability and Wiki-style point, because Rename is particularly attractive to all users. If you can freely edit text, it seems natural that you can rename titles, too. Knowing this is possible, but restricted, disrupts the essential Wiki spirit. Also, given the challenge of making meaningful, unmangled WikiWord topic titles - FaqList ? CiaRocks ? -- renaming is a sure hit, and restricting it more acutely felt.

Another case in point from higher up on this page: the discussion of how rename/move automatically updates links in all referring pages (a good thing), which causes WebChanges to list those pages as changed (not so good thing).

Great feature. Now, to...harmonize it with the essential Wiki flow!

-- MikeMannix - 29 Sep 2001

On the other hand we are disrupting the Wiki spirit when we rename topics! I see Wiki systems as a community brain that never forgets, in this sense it is like the XanaduProject (was that the name?). The rename feature violates this aspect. Rename fixes links on this site, but links from the outside do break.

  • Focusing solely on the communication/collaboration aspect, why should topic titles carry so much more weight than topic content , AND be effectively removed from the refactoring process? TWiki notes that people at first may be scared of editing freeform, until they get used to it. But when it comes to starting a new topic, that free flow's broken again - we know a title's set in stone, so making that branch is discouraged, we hesitate. How different would the evolution of a Wiki be if titles were easily revisable - forget Rename, imagine a 30 minute grace period in which you could rename a new topic (that's NOT a suggestion). Would that change the whole flavor of discussions? In practical terms, there is a need for consistent titles - for persistent, reliable external links; for revision control to "allow" freeform editing - but that doesn't justify a fixed topic title being the arbitrary unit of structure. When I outline a report or plan or storyline, my section headings get scrambled, rearranged, rewritten...that's most of the fun...the rest is just blanks to fill in. wink -- MikeMannix - 30 Sep 2001

TWiki is very robust because of version control. Vandalism can be done but does happen very rarely. An rename feature open to the world would lower that barrier.

Because of these two reasons I believe we should keep the rename restricted to the admins. A "please rename to xyz" note on a topic is enough of a hint to get the topic renamed. Agreed it's advisable to restrict Rename for practical reasons right now (and to each their own TWiki site rules) - unfortunately, that also adds a webmaster routine, the type of centralized task that Wiki's by definition are free from... -- MikeMannix - 30 Sep 2001

-- PeterThoeny - 30 Sep 2001

Regarding the rename bug - it would be a bit better if the renames are marked as such in the WebChanges file. Perhaps we could add a field in WebChanges or modify the user field to include (renamed). Without something reading WebChanges becomes impossible.

-- MartinCleaver - 30 Sep 2001

A simple solution is to use the changes script instead of view WebChanges. I did that for the Changes link in the web actions row. (BTW, the original noisy WebChanges is still accessible as a "hidden" link of the "|" vertical bar preceding the Changes link.)

  • Whilst I agree that the new format is better, I believe a better way to organise it is to create a new page, perhaps WebChangesInDetail, that invokes the old method, and re-purpose WebChanges to call /changes/Codev. Otherwise the changes are no longer on a Wiki page. (Assuming they should be.)

-- PeterThoeny - 30 Sep 2001

At the current time I have to agree with Peter about restricting Rename on TWiki.org. The memory part of TWiki is important. Now there is the method for search for a moved topic, this can be used when trying to view a page that doesn't exist:

   % METASEARCH{type="topicmoved" web="..." topic="..." title="..."}%

But, this can only cope with a page moving once, as the meta data for a topic move has only one copy. Expanding this to any number would help. But, you still have to deal with a topic changing e.g. rename TopicA to TopicX, then create TopicA, but with different content. Perhaps this later case isn't too important. Thoughts?

-- JohnTalintyre - 30 Sep 2001

  1. See also above for my comment about WebChanges.
  2. Can we make it so that hits for pages that do not exist automatically perform this search?
  3. TWiki.org keeps giving Internal Server error - very annoying!

-- MartinCleaver - 01 Oct 2001

I think tracking more than one level of renaming is probably not worth it - you end up building a temporal database, which is very hard to get right. I think that MasterRefactor and in fact most refactoring would benefit from being able to rename topics, but as long as there's a convention such as 'RENAMEME', it's a minor inconvenience.

On another topic - TWikiPreferences shows that InterwikiPlugin is not enabled, it would be good to get this working again.

  • Discovery of Plugins is enabled again. Was a side-effect of tightening the security. -- PeterThoeny - 23 Oct 2001

-- RichardDonkin - 23 Oct 2001

  1. I'm finding all these changes on Codev difficult to keep up with - are we working towards a plan?
    There aren't any major changes, really. MasterRefactor is being continuously updated - that has the plan and the progress. It's a clean-up. (more below) - MikeMannix - 01 Nov 2001
  2. What's with the %BASEWEB % variable?
    Nothing, really. The way it's used now, it's the same as Codev or %WEB%. (#3 is not me.) - MikeMannix - 01 Nov 2001
  3. Can we up the number of topics shown in WebStatistics? I would find it interesting to see the top twenty most viewed topics.
    • I guess this should be a TWikiPreference rather than a TWiki.cfg variable.

-- MartinCleaver - 01 Nov 2001

MasterRefactor: There are nearly 800 Codev topics now, practically none of them maintained - ie: they're straight thread mode discussions, often going back up to two years. Feature status hasn't been updated in many cases, and current discussions (last three months) continue threads from back in 2000, across major new versions of TWiki. Same with bugs. Etc. The idea is to organize as much as possible under a few natural dev categories: collaboration, tracking changes, interface/navigation/general usability, features. And then edit down, refactor within reason - hopefully, with topics usefully linked, some people will handle their own stuff. Ideally, a clear TWiki snapshot and future dev roadmap will be outlined for Codev input. Right now, TWiki is loaded with features, but there isn't a clear, explicit future direction - what's next? I'm hopefully helping by cutting through a lot of the noise and junk! Also, tackling this is a good workout for TWiki features, what works and what doesn't! (For example, as previously discussed, the automatic WebChanges is a big problem when doing maintenance like this - I'm tired of seeing my name on every page, and it's totally confusing.)

-- MikeMannix - 01 Nov 2001
That's great, I thank you for doing it, its a worthy cause.

I am concerned, however, that the *Thread topics you have created are manually maintained. Surely this is time consuming to maintain and could be automated?
There's a discussion of that TaggingRelatedTopics, and of related changes notification issues in WhatsNewIndication. I also put in a KeyWord field in the WebForm, to use for temporary tags, but I doubt that'll be too useful - it'd probably work best with a "replace all in found set" type of operation to permanently tag a found group, which isn't something TWiki does (or should even consider doing?). BTW, the INCLUDE method is temporary - just for this reorg project. I find all this an cool test - MasterRefactor is needed on this scale from not having followed original Wiki "everyone religiously cleans up every day" pracices, which aren't exactly human nature, so it's probably something that would happen or be required on all sorts of Wikis. So this is part of the Documentation Project, but a field test, too.

Also, perhaps you could use a different Id for doing reorganisation. I have realised that I have a habit of skipping any contribution from your Id because I have learnt that they don't say anything new!!
That's a big problem, evident while working on MasterRefactor, and also mentioned in some of the posts to do with WebChanges and WebNotify. (Although it wasn't the conscious reason, maybe that's partially why I created the ExtraExtra topic :> ) If I were to change IDs, the caretaker ID would still show up. "Real" contributions under my name wouldn't being ignored, but I'd have to relogin all the time, or work in a less natural way to separate the IDs. And it wouldn't solve the problem of maintenance IDs obscuring the true overall change record - when was a topic last significantly changed? -- MikeMannix - 01 Nov 2001

-- MartinCleaver - 01 Nov 2001

One thing about these Thread lines: surely they should be a field on the topics rather than being inserted at the top of every topic?
Martin, do you mean a form field (There's the KeyWord field in WebForm, but that's awkward to use and not too promising so far...) I've place the Threads on topic on purpose, so that it's easy to scan, and reach, the related topics. If and when they're fully refactored, the number of fields should be greatly reduced, maybe by as much as 80%. It would be great if people would contribute by adding related links. ChangesThread, CollaborationThread, and InterfaceThread are pretty straightforward. FeaturesThread is a bit trickier, it's not meant for every last feature idea, it'll develop by example. I'm going to start a correspondending Project topic for each area, to serve as a MasterRefactor base: ChangesProject, CollaborationProject, InterfaceProject to start with. -- MikeMannix - 02 Nov 2001

Regarding the caretaker ids, we need to sort this anyway because at the moment any change to the meta data (such as an action to subcribe to an individual topic) would cause a "Content change". Content changes also need to not occur for "minor mods".
Also, as previously noted, when referring links are changed during Rename/move. - MM

  • Right - two things. Firstly can anyone please confirm my suspicion of whether both UNIX and Win32 are capable of altering / overriding the last modified date written to the filesystem? If so, we can write the minor mods version to the filesystem and then write back the original date hence not causing a minor mod to go up the WebChanges list. Secondly, we can update the minor mod with the name of the last major mod.

  • Together these two should ensure the minor mod doesn't distract the flow of people reading WebChanges.

regarding BASEWEB directive, what's the intent behind it? Ie. where does it add anything beyond WEB?
No reason at the moment - because it's there! I don't think there's a negative performance hit? Can you see an problems arising? - MM

  • Why is it there? I ask because it seems incoherent to have two tags that do exactly the same thing when one will do. Which should I use? Is one going to be discontinued? Do they function exactly the same way? BASEWEB seems useful, no, just not particularly? And INCLUDINGWEB. To make things self-configuring or whatever when INCLUDEd between webs... That's it!. -_ __MM
-- MartinCleaver - 02 Nov 2001

Also, its rather quiet around here, don't you think?

-- MartinCleaver - 13 Nov 2001

confused I've spent some time thinking before I wrote this Mike but I have to ask this question:

  • Why are the topics in topic ExtraExtra more worthy of attention than other topics?

What merit do we use as the basis to ensure that the whole or majority of the community believe that those appear in there are important to the community? Do we have a means test?

I do agree that we need a mechanism to promote items that we, the community, think are worthy of attention - indeed, that's why I started DevelopmentAreaByPersonInterested - but I think:

  1. Any idea needs sponsoring by an individual
  2. Ideally the idea needs to be able to be voted on by the community

I must say that I dislike the new name ExtraExtra. Why did you change it?

-- MartinCleaver - 20 Nov 2001

I hate Extra!, EXTRA! even more, and ExtraExtra is unspeakably annoying. I'll blame it on Peter - he didn't like RFC for confusion reasons. I couldn't think of anything better, probably because I knew it would be GONE quite shortly...

RE the purpose: well, Martin, you ought to love the one-two of renaming CoffeeBreak to DevOpinionPoll. The idea of Extra, now OpPoll, is to push forward certain things that may be overlooked - like, I personally wanted to get comments on the trend to incorporate Wikis into CMS/Weblog systems, like Scoop (ScoopMeetsTWiki), PostNuke, other Slash-type systems. Nobody paid attention to that as RFC or EXTRA! anyhow. But if the OpPoll page got accepted, then people should remove their posts after a while. Reason #2, the idea of "discussing it on Codev" comes up in emails, but just putting up a topic again often doesn't get response. So maybe focussing on a page that has stuff like new feature votes, too, will establish this... WDYT?

-- MikeMannix - 21 Nov 2001


Regarding the ChangesThread, CollaborationThread, etc, I would recommend that you implement categories for these so that it is really easy for people to assign topics to them.

-- MartinCleaver - 20 Nov 2001

They should be gone soon! I was gonna put them all at the bottom, but the idea is, once it's all tagged up, to be able to click around quickly to edit things. Categorizing them - I assume you mean in forms - is more complicated: don't get the menu on each page. It could be done, about the same work, but no easy ref menus. I put a color, an ABOUT and a bit more explanation to clarify.

But what do you think about the topic divisions, and the related project pages. The actual idea. Does it, and the actual groups, make sense to you?

-- MikeMannix - 21 Nov 2001


I initially came here to respond to the "Also, its rather quiet around here, don't you think?" of a couple of weeks ago, and found activity has picked up a little. : )

I'm off work at the end of the november for 6 months or so - we're having a baby. I intend to install TWiki at home and continue learning and contributing but I don't know how well that will work in practice (everybody keeps telling me "you think you have no time now, just wait!"). Anyway, I just wanted to let people know I may not be too active (in this realm) for awhile. : )

Martin: I think DevelopmentAreaByPersonInterested is a great idea and your point about topics needing to be sponsored is important and deserved to be thought about and emphasized.

WRT to the why of why the ExtraExtra. This is a response to lack of response. Is it an appropriate solution? No, because it doesn't really address the underlying problem - how to solicit feedback and increase general participation - while causing problems of it's own: more noise, less signal.

Think of being in a room with a bunch of people, all having seperate and concurrent conversations. When I need to bring Mike into the conversation, who is busy somewhere else, I shout "HEY MIKE! What do think about...?". A few iterations of this and pretty soon everybody is shouting and nobody is hearing.

What is an appropriate solution? I don't know. The question is a deep one and is being struggled with all over the world in many different arenas. I do know that whatever the solution is, it will be revolve around reducing complexity by offering fewer choices.

-- MattWilkie - 20 Nov 2001

Well, congratulations, Matt! And hey, that sounded...deep, at the end there! You'll see my reply to Martin above. And the changes. Without going into a whole ramble, there's a method to my slightly erratic...method right now. I was juggling everything - ideas in my head - until the crash. Now that's wiped. So it's a bit weird. But anyhow, I'm approaching this as a Wiki lover (hmm..), a non-programmer, and an editor, so it may seem odd if you don't have that perspective: it'll work out if (WHEN) I finish. And Matt, you seemed so promising as an...active co-participant. Oh, well. Keep checking back!

BTW, I emailed BlueRobot (CSS) a couple hours ago to see if "rob" might be interested in volunteering a couple hours to do a pure CSS/CSS2 template version. I used one of his scripts on a TWiki and it's cool. (Did I say this before?) Anyhow, it's great, two columns...

All this chatter - worse than IRC/IM... <g> Later... (More comments, please!)

-- MikeMannix - 21 Nov 2001

I'd like to say that i'm not overly impressed with the refactoring that's occurred. It seems more formal (and thus more constrained) and has more nesting to get to places where one can actually post something. It also doesn't help that my mental map of twiki has gotten scrambled, so finding things is harder. I had to look around for "CoffeeBreak" (a perfectly good name for a casual page imo). Also, if you have a particular interest in what some people post compared to others, it's not been helpful that most pages where last touched by Mike Mannix (isn't he a fictional character? wink ).

Anyway, on to the proximate reason I came in search of CoffeeBreak. After a year of mucking about with TWiki on Windows, I at last have a 100% working Twiki!! huhRAH! (I think there's an issue with modperl hanging onto old content, but I doubt it's a TWiki issue.) I think most of my previous problems had to do with support utilities (grep etc.) that where not what TWiki expects. I've gotten a new machine and had the room to download and install the CygWin stuff and all the weird diffs and embedded grep pattern strings are a thing of the past.

BTW, if you don't like CoffeeBreak, how about OpEd? smile

-- DavidLeBlanc - 20 Dec 2001

Mike Mannix is real, He is Me. Apologies, I should have fixed this CoffeeBreak thing, which was an experimental change, like several others, that lasted for all of about about two days. In this case, someone else almost immediately started a new CoffeeBreak, leaving this page to be...refactored. If that's the extent of the "refactoring that's occurred" that you're not overly impressed with, your expectations aren't too high <g>.

This being the original CoffeeBreak, it contains up there round about the middle, a whole chunk on the very problem of is-Mike-Mannix-real - the fact that using one of the fine new features, like Rename/move, with its referring link changes, touchs all pages, rendering WebChanges pretty well useless as a way to check up on changes, for one. So that's OG CoffeeBreak content, but the question is, should the mental map remain intact, or should related issues be connected, topics refactored?

It's clear that Wiki collaboration is in name only without active participation. Otherwise, it's just a cool frame for a standard message board, like the dev systems of practically all OSS projects. Feedback is EVERYTHING when it's got NEW INFO, IDEAS, whatever. So it annoys me, in proximity to my name (so, presumably referring to whatever I've been doing w/o just SAYING SO), a comment like:

i'm not overly impressed with the refactoring that's occurred. It seems more formal (and thus more constrained) and has more nesting to get to places where one can actually post something. -- DavidLeBlanc - 20 Dec 2001

What are you talking about, exactly? I'm really interested if you have something to say.

-- MikeMannix - 27 Dec 2001

My personal view - can't speak for David - refactoring whilst good in principal, if done over zealously with too much impact on collaboration is bad. For example using a varied and too many type faces continuously changing on a single page results in a highly unreadable page. Far better to simply emphasise something

By putting it on a line by itself like this

And rather than replying

    In italics in the middle of someone elses text, such that you have to skip back and forth between fonts and font styles

Simply replying at the end of a logical chunk with no font/style change is much clearer to the eye. (IMO of course!)

The other thing is that some of the editting is far too imposing - and by this I mean that it gets in the way of collaboration - not that the editting itself per se is bad. What do I mean by this?

Well you've created a new entry in the category table (or Peter has) for the Project groups you think you see (*) in the Codev web. However, clicking on those (not checked for all) isn't useful - it gives you one (or a few people's opinions) on what that group should be about, but not what topics are actually in that group as per the category table. (Compare & contrast the Plugins web if you want to see what I mean by that! smile )

    (*) not everyone will agree on these groups - but most of us have day jobs, and Twiki comes second to those, even where it is used as a very useful tool in those jobs and as a result some grouping is better than none)

What's "worse" in a way is the list of related topics that you're including at the top of pages. For example:

  • You're including CodeBaseThread - but this contains a manually maintained list of topics. Furthermore it's biased (not intentionally in a bad way I'm sure smile towards things you're interested in... (Both a good thing and a bad thing)

  • Contrast that say with the older more manual way of looking at the pages that don't have such a CodeBaseThread included at the top - eg: ReadWriteOfflineWiki a thread which I know many people were interested in and some developers are still working in that direction (me, a few others, etc)

A combination of the two approaches using something more intelligent to automate the process - such as the FormattedSearch on a "thread" page that is linked to from the category table rather than included on every page would useful IMO. After all from my perspective the DataAndCodeSeparation stuff had nothing to do with any form of CodeBaseProject - it's more to do with systems administration practicalities of a twiki server, and wanting to hand off the server to the IT dept!

ie Put a page somewhere with a formatted search that automatically generates the topics in your projects threads from the category tables. Trust us to use the tables (I know I do!) and Do The Right Thing - saving you alot of burden, and consider removing the manual thread list from the top of every page. (Meta information does after all live at the bottom of most TWiki pages!)

Penultimately, one last thing - refactoring by definition involves modification of existing pages, filtering out the chaff, and putting a logical order to things. This does not always increase the content value to a page nor does it always make the page more "discussion worthy . However a page that changes regularly is often discussion worthy, and changes mean useful stuff is being added. This latter point is what (for me) makes the WebChanges page soooo useful. Refactoring drastically and often pages that haven't had any new content added in a long while simply impacts (for me) collaboration in a detrimental fashion.

That said, the Codev web IS huge, and DOES need refactoring, and by volunteering and doing it you're doing a good job. As a result the one thing I would suggest is this: If you refactor a page that hasn't changed in a while (you decide smile ) please, please, please, make gratuitous use of the "Don't Notify" button ? That way at least on the mail notifications the necessary refactoring won't get in the way of the necessary collaboration !

Finally text is a harsh medium - this is intended as constructive criticism only, take the good, ignore the bad.

Cheers

-- TWikiGuest - 27 Dec 2001

Well, after four (?) days of Linux/Apache/etc cramming, it's all name-based virtual domains vs separate IPs, the virtues of Webmin over command line, IPtables and chains, measuring bandwidth usage by account, Squid?, Plesk?, PAS?, BIND8? 9?, whether there's any reason at all to set up a name server, and a thousand other details, from WHY port 443, to why the etc dir is pronounced "ET-see" (at least, in Texas)...mixed in with marathon TWiki...I gotta wonder, if I get trashed tonight...will I forget all this stuff? As for your comments, MichaelSparks, as my last TWiki CoffeeBreak comment of 2001, I gotta say, people too comfortable with lecturing in the obvious tend to have other complementary unhelpful characteristics, too - like generally bad judgement. I don't imagine that judging is your profession, so no harm.

The one thing, and probably main practical point, I'd like to get your further feedback on is. HOW TO SOLVE THE MINOR UPDATE PROBLEM?

  • My name on a topic change is already...greatly devalued - a MikeMannix post means nothing. Why? Because, by renaming a single well-referred-to topic, all ref pages get tagged as updated. This has been rather well-discussed weeks ago, but it doesn't seem to be a priority. On private webs, probably access to rename is restricted, and it's seldom used. Or the problem has been hacked around. (clicking Minor change doesn't solve it.) So here is probably the central issue - for two months, MikeMannix dominates changes. For no good reason. But it's not a priority fix for TWiki.org. How do we address stuff like that? And WHY isn't it a priority - what's the dev model?

I haven't actually "refactored" a single page so far, other than docs topics in the TWiki web, and there, only copyediting, really. I'll start this week, though. That should be fun, too (I'm actually quite good at it)!

-- MikeMannix - 27 Dec 2001

Mannix! was a private-eye TV show from the 70's starring Mike Conners. I just checked and the character's actual name was Joe Mannix, not Mike - perhaps I confused the actor's first name with that of a character. I guess you'd have to know about and/or remember the TV show to get the joke about Mannix being a fictional character.

With respect to refactoring, please see ThoughtsOnRefactoring.

-- DavidLeBlanc - 28 Dec 2001

Yeah. Radical dude with a black secretary, after the first year, named, uh, Peggy?! My dad used to get a phone call from a little kid, when I was a kid, too, around 7am just about every weekday for maybe a year, saying, "Joe Mannix? I need a private dick..." or something like that. My father's name wasn't Joe, either. The fanatic kid probably wound up in a clock tower somewhere...

Mannix is an Irish name, not all that common. Mike Connors, the actor, was Armenian. For no good reason, that's always stayed in my mind.

This is CoffeeBreak!

-- MikeMannix - 28 Dec 2001

Edit | Attach | Watch | Print version | History: r78 < r77 < r76 < r75 < r74 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r78 - 2003-09-06 - MichaelSparks
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.