http://qs321.pair.com?node_id=588724


in reply to 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

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        

      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.

        "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        

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.