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

I'd like to propose that the current Code Catacombs structure be replaced with a doclist-based structure. Doclist has proven itself practical in its applications to Tutorials (as subclass tutlist) and the PerlMonks FAQ (as subclass faqlist).

There are really only two main steps the gods would need to take to launch this conversion task:

After those are done, the pmdevils can do any necessary coding (which should be minimal), and the new group can begin creating and populating nodes of the new doclist type. One of the first lists created should be for holding New sourcecode posts, just like New Tutorials. Then we'll need the gods to make a maintenance create node, just like perltutorial maintenance create.

The new doclist type would need a name; I propose "codelist". The new user group would need a name; I propose something like "librarians" or "custodians" or "curators" — or, if we want to keep to the catacombs metaphor, "troglodytes".

PS - Ideally/ultimately, this same doclist-based approach would be used for the (much anticipated, never realized) Categorized Questions and Answers revamp.

And in case anyone's wondering — I volunteer for all of the above! (except the godly parts, of course.)

We're building the house of the future together.
  • Comment on Revitalize the Code Catacombs using DocLists!

Replies are listed 'Best First'.
Re: Revitalize the Code Catacombs using DocLists!
by Arunbear (Prior) on Dec 08, 2006 at 22:44 UTC
    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!)

[reply]

      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]
        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]
      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]

Back to Inner Scriptorium