sometimes, dealing with a specific problem, I remember that <insert your name here> wrote a meditation about it which I happened to stumble upon, but I don't remember its title. How to get at it? There's Super Search you say.

Ok, I go there, leave "Match text containing" text box empty, "Match authors" gets <insert your name here>, then "Search the following sections: [X] Meditations", further down "[X] Don't include replies" has to be set, then I hit "Search" and I please am patient after submitting my search.

But then, there's the showtype parameter to Perl Monks User Search, except that there's no combo box where you could select e.g. "Meditations" from. You have to add the parameter to the URL as e.g. &showtype=perlmeditation to constrain the search to Meditations.

With a Node Type combo box in Perl Monks User Search, all I had to do is enter the monk name, select the Node Type and hit "Search".

I wonder why it is not there. Adding a combo box for Node types to constrain the search would be trivial (just a bit of code reordering). The layout of the paramenter table could be

   Author: |________________|                     show |__50| nodes
 Order by: |_Newest_First_|v|              starting at |___0| .
Node type: |_All_Types____|v| [ ] Show categorised Q&A (Why?) |Search|
[download]

which doesn't increase the vertical table size.

Of course, as ysth notes, "adding additional filters means the sort-by-reputation becomes even more revealing of node reputations than at present" - but would that be bad somehow?

Has this been proposed before? Is this proposition a desirable change? What do you think?

update: Patch submitted and (after killing bugs) applied. Thanks, tye. See What's New.

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Since this came up in the pmdev wiki, I'll outline some design notes for a long-standing desire I've had for nodelets.

I'd rather that going to Other Users would just show you the nodelet contents (currently it shows you the source code for that nodelet if you are in pmdev and tells you "tough beans" otherwise). If you went to /bare/?node=Other+Users then you'd get just the nodelet content w/o any nodelets, headers, etc. If you want to see the source code for the node, then use displaytype=viewcode, which already works.

But some nodelets don't make any sense w/o a "current node" (that is not the nodelet itself). So I'd like the default display page for a nodelet to pretend, for the nodelet's sake, that some other node is $NODE. The "obvious" choice for that is the previous (non-nodelet) node viewed.

Then you could have a lot of nodelets (or even all nodelets) that you don't show but that you can quickly jump to if desired. So you don't have to show the moderation nodelet but when you want to consider a node, you click a link that takes you to the moderation nodelet with the node you were just on faked up as $NODE so that you can consider that node.

This type of thing is especially useful when browsing from tiny devices like a cell phone. But it also means you could greatly reduce the number of nodelets you have always up, making browsing the site faster for you.

Then the "/bare" version of pages could get a header that has a simple "nav" link that goes to a page with links to some common items including some nodelets and includes the refer node's ID in a CGI param such that those links show you the chosen nodelet but using that prior node as context. The "nav" page would even have a "search" box where you could type the name of any other nodelet to get that same effect.

The "nav" page could also include Free-Nodelet-style stuff so that you could customize it easily and powerfully. Perhaps even the "nav" link would just be a default that could be overridden with Free-Nodelet-style content.

On a nearly-unrelated note, we could also allow a Free-Nodelet-style insertion into the headers over subordinate nodes (replies when viewing a thread, nodes when viewing a section page or Nodes to Consider etc).

I think a relatively small step toward making keywords (as in the Keyword Nodelet and keyword search, the latter currently "tough beans" for non-pmdev) eventualy much more useful and more immediately somewhat less useful for anonymous abuse, would be the addition of an approved keywords table.

This approach occurred to me in part because it would also make keyword search less likely to become a resource hog. It won't do enough to make keywords /really/ useful, but I think it is a small step in the right direction that could eventually result in a reasonably nice system.

The idea is a new table that only vetted group members could add keywords to. I'd just make a new access rule rather than a new group, at least at first, allowing janitors, sidedocclan, and pedagogues to add/delete approved keywords and delete (at least at first) keywords on nodes. Those wanting access to do keyword approval could join pedagogues. Note that I wouldn't add pmdev as the ranks there are too swolen and unchecked, IMHO.

The other pices to be added, in nearly whatever order, include:

• Hiding or de-highlighting unapproved keywords displayed in the keyword nodelet
• Adding a user option to show unapproved keywords in the keyword nodelet (which selects between the "hiding" vs "de-highlighting" above and default to "don't show", that is, "hide")
• Encourage addition of only approved keywords via the keyword nodelet, but allow addition of unapproved keywords to be considered as requests for new keywords to be approved by the vetted users or as clear abuse to be deleted by them (or something between to be left in limbo). I'm not sure the best interface for this "encouragement" (does HTML allow drop-downs that also allow editing? I don't think so).
• Prevent anonymous users from adding unapproved keywords (they won't see them either since they can't change the user setting away from the default value)
• Accountability and voting. So abusers can't be anonymous and so non-vetted monks can chip in selecting the best keywords. The current "voting" is pretty pointless for many reasons. Voting per keyword per node is likely too much data to be worth doing. But voting on approval status of keywords might be worthwhile.
• Only showing approved keywords in the keyword search drop-down. To search for an unapproved keyword, you'd need to just type it in or, for vetted members, request the list of unapproved keywords (perhaps a new node for that).
• Add a "keyworders' wiki" that all non-anonymous monks can write to (at least at first) for discussing keywording. (Note that creating a usergroup with a large number of members is not a good thing to do at PerlMonks.)

Note that I'm not volunteering to implement this. Just a design idea as a starting point. I'll certainly do some applying of patches, creating of tables based on MySQL definitions someone else works up, etc. Those gods-only tasks, etc.

The first patch did result in removal from the parent section, but did not do the conversion to sopw. The second patch (which differs from the 1st by invoking removeFromNodegroup after changetype) does convert the node to sopw but does not remove it from the parent QandASection.

Can anyone shed some light on this mystery? Many thanks.

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:

• Create a new node type derived from doclist, in just the same way tutlist and faqlist were. (Note that no new database table is needed for this.)
• Create the user group authorized to manage the new node type, and give it some members.

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.)

• 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)

I could only think of one reason: to always see the newest messages, in what could be a huge pile. The pile could be that huge, that it gets truncated. For example, the Chatterbox Sidebar only shows at most 2 messages.

Wouldn't it be a good idea to show just the last messages in your inbox, instead of the first? I've tested it, that's what the Chatterbox does. And Message Inbox, too. Even if it does say at the bottom "Plus 2 earlier (of 5) messages not shown.", those are actually the more recent messages.

My proposal: the way I'd prefer it, is that the sublist of messages get selected in reverse chronological order, for example the latest 10 by default, but that the display order is chronological, if that's what the user chose in his settings.

Does anyone else, but me, care?

Currently, when a QandAEditor deletes a Categorized Question or Categorized Answer, the node is nuked, which means it's wiped out of the system, and there's no (publicly visible) record of the delete action. Perhaps it would be better if this were changed so that nodes so deleted by QandAEditors are reaped instead?

Update: I have determined that if a Categorized Answer node is simply reaped, it continues to be listed under its Categorized Question (with the usual skeleton left for reaped nodes). And there is (currently) no user setting for disabling the display of such reaped nodes. This could be remedied, of course. A user setting for this could be added; the user setting for display of reaped replies could be used; or the node type could be changed, upon reapage, to something other than Categorized Answer.