Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

RFC: a nodetype for considerations

by Arunbear (Prior)
on Nov 27, 2006 at 22:17 UTC ( [id://586341]=pmdevtopic: print w/replies, xml ) Need Help??

I'd like to propose a nodetype for considerations (i.e. a node which encapsulates all the current consideration data plus additional info like janitor comments).
Potential benefits are
  • considerations could have replies - this can be useful for suggesting alternative titles when a node is considered for retitling, or for suggesting additional remedial action
  • janitor comments (when necessary) could be stored in a field of the consideration instead of putting them in the node being edited.
  • there would be a permanent record of considerations i.e. the consideration nodes themselves (this may encourage considerers to be more considerate)
How does this sound?

Replies are listed 'Best First'.
Re: RFC: a nodetype for considerations
by Tanktalus (Canon) on Nov 27, 2006 at 22:38 UTC

    Why do I think this has come up before?

    What will develop is that we'll end up with meta-conversations that may or may not be easy to notice, depending on the implementation details. Which brings me to the second issue - finding someone to implement it ;-)

    That said, I'm not really sold on the current view, either. Two possibilities spring to mind. First, some sort of automatic wiki that allows those who can consider to instead update that wiki. Requires a fair bit of restraint to ensure that no one blows away anyone else's remarks, though. Not really sold on this - just the first thing to pop in my head.

    Second would be more of a /msg system. Allow nodes to "receive" messages. Allow considerers to send to the node. Allow the considerations nodelet to display all messages to the node. And then Janitors would clear the messages in one fell swoop through the act of editing the node (or not if we want the permanent record). I think I like this better - it keeps everything simpler, at least from an interface perspective. Not so sure about the code side.

    Of course, that has pretty much the same downsides as a nodetype - I've taken care of "not easy to notice" - but it's still a meta-conversation, and needs to find someone to implement it.

Re: RFC: a nodetype for considerations (history)
by tye (Sage) on Nov 28, 2006 at 00:43 UTC

    My idea was to allow multiple considerations per node. Then a "bad" consideration can be countered by a better one. All considerations for the same node would be shown together on NTC (with node only displayed once). Janitor comments should be store in a node history table which is already implemented in the moderation revamp that needs to get applied.

    - tye        

      Some considerations (e.g. for reaping) don't result in an edit but still need a janitor comment, which is why I think the comment should be stored with the consideration rather than in the node history table.

        Wait, the node history table isn't tied to edits. I'm not talking about "recent janitorial edits". I'm talking about the node history table that records node approval, move, consideration, unconsideration, etc. I'd rather not have comments tied to considerations since approval and moving don't require consideration. But whatever works. (:

        - tye        

Re: RFC: a nodetype for considerations
by demerphq (Chancellor) on Nov 29, 2006 at 14:03 UTC

    I like the idea, but I'm a little worried about making considerations a first order object. It seems to present scalaing issues that im not sure I like. Id rather see consideration objects being implemented independent of the node table. Yes this would mean you couldnt id link to a consideration, but I don't think thats bad.

    Elswhere, Tanktalus said:

    Second would be more of a /msg system. .... I think I like this better - it keeps everything simpler, at least from an interface perspective. Not so sure about the code side.

    Something like this IMO would be fairly straight forward to do. I think it bears thinking about, even if it is ultimately rejected.

    ---
    $world=~s/war/peace/g

      Why would considerations as first order objects not be scalable?

        I guess you can look at the issue two ways. In one considerations are like special replies and therefore are objects in of themselves. The other way is to look at them as being attributes. I think they make more sense as attributes, and therefore to me making them first order objects doesnt fit my mental map. I dont want to view a given consideration, I want to view a node and its considerations. Etc etc.

        Nodes are never destroyed, so you can't clean them up. We get a far number of considerations per posts, over time it clogs up the node table.

        Maybe I'm not expressing myself properly here, but I do see this an overall issue. We are now have ~ 600,000 posts, if you start adding a consideration node, lets say 1 per 20 posts, i see that as unnecessary growth of the node table for what is really very little benefit. Its unlikely that one will want to view the full consideration history of a node for very long, maybe a month or so for an extremely contentious posting. But anything that goes in the node table is forever. And everything that goes into the node table affects the performance of the site, across the board.

        Anyway, my view on this is that the msg idea had a lot of merit. It wouldnt be hard to extend the private message system to handle the needs of consideration. Occasionally these can be purged etc etc.

        ---
        $world=~s/war/peace/g

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (5)
As of 2024-04-24 12:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found