I have a note, last hour of cb, which I update every 5 minutes via a bot running on perlmonk.org. As a note, it has two features which are irrelevant and distracting: links to parent and root, and vote buttons. I'd like to get the type of the node changed to something that doesn't have those features. My first thought was to make it a sitefaqlet, but the problem with that (and with many other node types one might think of for something like this) is that each update to the node would create an entry in the edit history table. For a node that gets updated as often as this one does, that would clearly be a Very Bad Thing. So I went looking for node types which satisfy these two requirements:

1. Supports direct updates by owner (vs. janitorial type edits)
2. Does not support voting

A handful of node types pass this filter. Most of those have other problems/restrictions which could make them unsuitable. In the end, the one that seems most likely is scratchpad.

Therefore, I'm submitting a request to the gods to change the nodetype of last hour of cb from note to scratchpad.

Q. Why not just make a new node, rather than changing the type of the existing one?

A. There are already too many links to this node, by ID. These would break.

Btw... I think it would also be nice to give ownership of this node to a site maintenance group, such as SiteDocClan or pmdev, but this is not strictly necessary, as long as no one but me expects to be able to update it.

Thoughts?

Update: Of course, this is the sort of functionality which should (at least by some points of view) be hosted directly on PerlMonks, rather than depending on an off-site bot. And actually, there are two off-site dependencies here: my bot on perlmonk.org gets its data from demerphq's bot on flux8.com. If either one goes down (and apparently, perlmonk.org goes down with some frequency) then this page is b0rked. So, the natural node type should really be superdoc, probably, or something akin to that. But creating such a beast is a bit beyond my skills atm.

Update2: (2009-08-06) This has been done. The node in question was converted to type document, and ownership of it was given to SiteDocClan.

I was pondering this matter, and was inspired by what dbwiz wrote.
I believe there really is something suboptimal here which needs to be corrected. The problem stems from the fact that "being a tutorial"* means two completely different things:

1. being a node of type perltutorial
2. being linked in the Tutorials list (aka "section")

"Big deal," you say?

The problem stems from the fact that the site's searching capability only looks at node type, not at where the node is linked. This means using Super Search to search through "Tutorials" will in fact only be looking at nodes of type perltutorial — including all the crappy ones — and possibly not finding nodes which are clearly listed in Tutorials!

How to resolve this problem?

As long as the contents of the Tutorials section (that is, the nodes which are linked there) are under manual control of people, there is no perfect solution. But one large step in the right direction, in terms of enabling those people to manually fix problems where they find them, would be to empower the Pedagogues to convert a perltutorial node into a perlmeditation node, and vice versa, at will. (Note that, more or less analogously, QandAEditors currently have the power to summarily demote a Categorized Question into a SoPW question (but not vice versa).)

This may be too much to ask. As an essentially equivalent alternative, the Pedagogues could submit requests for such conversions to the Janitors (perhaps by using Editor Requests). This circumvents the consideration process, which, based on the threads raised by dbwiz, was mostly ineffective, and I don't think it should be up to the voting public to decide anyway. The only other opinion which should be considered, imho, is the author's: obviously, if an author doesn't want her writeup converted to perltutorial, we should respect that, but it should come with the consequence that her overlooked gem won't get listed in Tutorials either. Similarly, if someone posts a crappy tutorial, we should be able to summarily demote it to a meditation.

* An analogous situation applies in most of the other sections as well.

Later addition:

Another possible approach to solving this problem would be to change how Super Search searches Tutorials. Rather than considering "tutorials" to be nodes of type perltutorial, it could look at some other metadata of the node; for example, we could perhaps set the parent field of "tutorial" nodes to point to some "sentinel" node (the Tutorials list itself, say), and then have Super Search consider any node which has that field value to be a "tutorial" for the purposes of searching. Another, similar possibility which occurs to me would be to use the keywords field – set a certain keyword (Tutorial, maybe ;-) on each node which is to be treated as a "tutorial".

However, I do not favor this approach, as it just makes the Tutorials section that much more different from the other sections. I believe very firmly that the best situation is for Tutorials to meet the definition of a PerlMonks Section in this fundamental respect: that being "In Tutorials" is exactly equivalent to be a node of type perltutorial.

While poring over our access logs, I was wondering whether it would make sense to ask the crawlers not to look at our "print" and "xml" views of the pages. These don't provide any additional information.

The code to patch lives in Everything/HTML.pm. linkNode needs to learn about another parameter which will contain a hashref of HTML attributes to append (in addition to the implicit href= attribute). Then superdoc title chooser would need to be patched to use the new parameter to prevent crawlers from following these views.

I was looking at system settings, %HTMLVARS, and set_htmlvars... And the picture which emerges is that certain parameters are defined with one name in system settings and used in Everything/HTML.pm with another name. This "renaming" is done in set_htmlvars. For example, permissionDenied_node is loaded into %HTMLVARS from system settings, but then is copied to a new %HTMLVARS entry, permission_denied. Everything/HTML.pm has been modified to use the new names. The old names now only occur in system settings, where they're defined, and in set_htmlvars, where they're copied to new names.

Why was this done, rather than simply continuing to use the old names?

It seems to me that we can improve clarity and performance by defining the new parameters directly in system settings; then we don't need set_htmlvars to copy anything. Is there any reason we shouldn't do this?

Here is a draft of a proposal for the creation of a new usergroup. I'd really like feedback on this proposal, especially from the gods, who, obviously, would have the greatest stake in the change. Thanks in advance.

I'd like to create a new theme (e.g. like Blue Web-Safe Theme) which sets no style settings. It would be named "No Theme". This is the theme users would select when they want to set all their display styles using CSS. Does this sound like a reasonable thing? If so, would one of the gods be willing to do it? Thanks a lot in advance...

I wonder what, if any, reservations the patch appliers have about my Red CSS - (patch) and kin. They're very small changes with potentially major benefit. Though, of course, they're but one of a slew of similar steps toward fully css-based PM theming.

It works like this - if you're a janitor and you have the 'Don't show embedded d/l links' setting turned off, then next to the [download] link at the base of a code section, you'll see another link called [add readmore]. Click on this and the code section will get wrapped in readmore tags (and the edit will be logged in the node history table).