In general, I'd think the latter is better, more flexible yet stable; but I would add that each article in the series should also have links near the top to the prev/next articles and the head/toc article, for clicky nav.

I'd think the latter is better, more flexible yet stable

In case monks forget, eyepopslikeamosquito has a series of The Lighter Side of Perl Culture (Part I) that talks about general stuff, followed by Part II - JAPH, Part III - Obfuscation, Part IV - Golf, Part V - Poetry, and Part VI - April Fools.

So now, we're probably waiting for The Lighter Side of Perl Refactoring, or other series, to come up?

---

Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!

In general, I'd think the latter is better, more flexible yet stable;

One obvious advantage is that root nodes seem to have a better visibility than notes. Thank you for the added remarks too, I will certainly want to take them into account should I ever start a thing like this myself. (And I have a half-hearted idea of doing so - otherwise I wouldn't have been meditating about the issue. Incidentally it's somewhat related to another topic discussed today.)

Sorry for not providing links. I may update as time permits.

Ok, for completeness I'm providing them myself. (Part has already been done by naikonta.)

• Perl Idioms Explained by various authors - approach #2:
• Perl Idioms Explained - $|++
• Perl Idioms Explained - keys %{{map{$_=>1}@list}}
• Perl Idioms Explained - ${\$obj->method} and @{[sort @list]}
• Perl Idioms Explained - my $string = do { local $/; <FILEHANDLE> };
• Perl Idioms Explained - @ary = $str =~ m/(stuff)/g
• Perl Idioms Explained - && and || "Short Circuit" operators
• Perl Idioms Explained - my ($foo, $bar) = @{shift(@_)}{qw/ -foo -bar /}
• Perl Idioms Explained - !!expr
• Perl Idioms Explained - my $count = () = /.../g
• The Lighter Side of Perl Culture by eyepopslikeamosquito - approach #2:
• The Lighter Side of Perl Culture (Part I): Introduction
• The Lighter Side of Perl Culture (Part II): JAPH
• The Lighter Side of Perl Culture (Part III): Obfu
• The Lighter Side of Perl Culture (Part IV): Golf
• The Lighter Side of Perl Culture (Part V): Poetry
• The Lighter Side of Perl Culture (Part VI): April Fools
• "Sports Illustrated" by merlyn - approach #1:
• Swimsuits2004
• Swimsuits2005
• Swimsuits2006
• Swimsuits2007

(Could not find anything for "obfu balls".)

blazar,
Here is the list for obfu balls by teamster_jr which follows approach #2.
• Balls!
• Balls! Pt 2
• Balls! Pt 3
• Balls! Pt 4

Cheers - L~R

One point I think bears mentioning, if one is considering the second approach, is this:

The key phrase should form only part of each article's title.

For example:

• More date conversion happiness, by ctp.
• Refactoring Perl, recently posted by agianni.
• Flip Flop, by MeowChow.

• More Date Conversion Happiness, Part 2 and more date conversion happiness, part 3
• Refactoring Perl #1 - Extract Method
• Flip Flop II, Flip Flop III - Musical Buckets, and the usurpacious Flip Flop IV.

To see what happens when this mistake is avoided, check out title searches such as Perl Idioms Explained, The Lighter Side of Perl Culture, and The Drama of Being a Developer.

This leads to a corollary principle:

The key phrase in the titles should have uniqueness wrt all other posts not related to the series.

Yeah, I noticed that about the first Refactoring Perl node I posted. I'm planning on going back and changing that to "Refactoring Perl - A Proposal" or something like that. I also found that I can use supersearch to narrow down the search such that it would only ever retrieve my root node postings. I'm planning on putting a link to that search result on my home node at some point -- like once I have a few more written.

perl -e 'split//,q{john hurl, pest caretaker}and(map{print @_[$_]}(joi
+n(q{},map{sprintf(qq{%010u},$_)}(2**2*307*4993,5*101*641*5261,7*59*79
+*36997,13*17*71*45131,3**2*67*89*167*181))=~/\d{2}/g));'
[download]

Interesting that you bring that up. Indeed, I too was thinking of it as an example of posting a series of articles as replies to an umbrella node. However, your characterization that those replies update their parent is not quite accurate. It could be done, of course; but my dacha (which I've restyled my "treehouse") is not an example of that.

OTOH, an example I've done of using a reply to update a root node, rather than modify the root, is Tk Photo Slideshow - Production Release.

A word spoken in Mind will reach its own level, in the objective world, by its own weight

Another way would be posting something as DRAFT and updating that root node. To prevent that root node to fall into oblivion update notes could be posted as replies.

IIUC, this is a sort of variation on the first scheme I mentioned: it is interesting and efficient. But I fear it may cause some problems with replies from other people, if people are supposed to discuss the topic. Now that I think of it, for maximum efficiency -and depending on the actual kind of content- one could take a third approach consisting basically of both:

• the user, e.g. me posts an umbrella node with an indicative title, e.g. "blazar wants to do it" and explains there the stated goal of the planned series of articles, asking people to please do not post followups directly under that thread;
• he posts the first article as a separate root node in the appropriate section, with a title like "blazar wants to do it - part I: conquer the world (DRAFT)". He puts a link to the umbrella node and a link in the umbrella node, to the draft;
• after hundreds of monks contribute their words of wisdom about how to conquer the world, the user will want to update the original draft with all of their suggestions. Thus he will post a direct reply under the umbrella node with the finalized version, putting there a link to the draft version and vice versa;
• and so on for the other articles...

Sounds complex, but it sounds more than it actually is. It allows for separation between user discussions and nicely presented material. It is weak in that it depends on good will on part of "others" and however carefully you try to state something in an idiot proof manner, along comes a better idiot. But all in all I'm confident that as a scheme it would be robust enough. And yes: it allows for some DRY violation but not in an upsetting manner, IMHO.