Re: Revitalize the Code Catacombs using DocLists!

One issue here is that there are far more code contributions (and snippets - which I think can also benefit from categorization) than there are tutorials, faqlets and categorized questions:

Nodetype count

sitefaqlets 145

tutorials 229

categorized questions 808

sourcecodes 1635

snippets 1834

Nodetype	count
sitefaqlets	145
tutorials	229
categorized questions	808
sourcecodes	1635
snippets	1834

I also think this is a useful way of aiding research, but I wonder how efficient it would be to maintain a categorization of such a large pool of nodes, both in terms of database load (is nodegroup the right construct for this?) and for the users that would have to maintain the categories.

curators++ (I work with real curators - they are a delightful bunch!)

Comment on Re: Revitalize the Code Catacombs using DocLists!

Replies are listed 'Best First'.
Re^2: Revitalize the Code Catacombs using DocLists! (fit) by tye (Sage) on Dec 09, 2006 at 03:09 UTC
So long as authors can put their own nodes into an appropriate list, then this might work. I'm not a big fan of things that require a privileged group. I prefer things that allow the rabble to clean things up and police each other. But if the privileged group is only needed when a new grouping needs to be created, then this is probably as good as anything we could do without a ton more effort. Do doclists allow one item to appear in multiple lists? That'd be a good feature. But whatever mechanism allows authors to place their items should prevent them from putting it into too many lists. - tye	[reply]
Re^3: Revitalize the Code Catacombs using DocLists! (fit) by jdporter (Paladin) on Dec 09, 2006 at 04:09 UTC
Do doclists allow one item to appear in multiple lists? Yes; the parent refers to its children; the children do not refer to the parent. So long as authors can put their own nodes into an appropriate list, then this might work. One of the cool things about this proposal is that it doesn't demand any changes to the structure of the nodes being categorized. sourcecode nodes currently have a `codecategory` field which users are requested to fill in when posting. This could be used by the "curators" in selecting a category in which to file the new node. We're building the house of the future together.	[reply]
Re^4: Revitalize the Code Catacombs using DocLists! (fit) by tye (Sage) on Dec 09, 2006 at 06:42 UTC
"used by the curators in selecting" means nothing gets sorted unless a curator does it. Yuck! The normal flow should be people posting and selecting the list(s) to post to with curator intervention only required when an author gets the choice "wrong" (and clearly wrong, unless the curator gets the author's buy-in on the move). - tye	[reply]
Re^5: Revitalize the Code Catacombs using DocLists! (fit) by jdporter (Paladin) on Dec 09, 2006 at 14:27 UTC
Re^6: Revitalize the Code Catacombs using DocLists! (fit) by tye (Sage) on Dec 09, 2006 at 16:59 UTC
Some notes below your chosen depth have not been shown here
Re^2: Revitalize the Code Catacombs using DocLists! by jdporter (Paladin) on Dec 09, 2006 at 04:14 UTC
and snippets Yes, quite. I meant to include snippets in the proposal, but forgot. I wonder how efficient it would be to maintain a categorization of such a large pool of nodes, both in terms of database load (is nodegroup the right construct for this?) One of the huge benefits of the doclist approach is that they are "just nodes" and they contain references to other nodes. That means they're nestabable in a flexible and arbitrarily deep hierarchy. We can get away from the flat categorization we're used to. We're building the house of the future together.	[reply]