You've probably all seen the recent discussion, Change Find Nodes "Saints in our Book".
In it, someone said "the Monastery is based on nodes IDs and not names," by which he presumably meant linking.

So it got me thinking about this issue, which has probably been raised before:
Would(n't) it be better if the links in the monktitlebar were ID links, rather than title links? I think it would, but I'm not sure why...

Update 1: In response to Tanktalus' comments below, I'll clarify my proposal as follows: The links should all be constructed using the [id://123|Text] format.
This means:

1. Link texts are statically customized for the context, and are immune to changing actual node titles;
2. Target nodes are absolutely certain, because node IDs are unique, and node lookup by ID is optimal.

The following benefits obtain:

1. No server load incurred for looking up titles at page render time;
2. No server load incurred for node searching by title at "click" time.

The downsides:

1. If it is deemed propitious to modify a link's text, it is done to the link, not to the target node's title. (This could be an upside; it all depends on the situation.)
2. If a target node is superceded by a new node, the link(s) to it must be changed to use the new ID.

In my estimation, the upsides far outweigh the downsides.

Update 2: I'll amend the proposal to be generic, i.e. applicable to all "high-visibility, high-traffic" links on/to site docs/functions. IOW, not just the monktitlebar, but also links in cabalistic nodelets and various superdocs, sectioncontainers, etc.
(This topic has definitely been discussed before, but danged if I can find a PMD for it. Perhaps we can put this puppy to rest. ;-)

Please check out demerphq's sandpit and review my reimplementation of the message inbox. Its not super pretty, and there is still some support code outstanding that will allow you to define new "archive-folders", but it should be usable.

Feedback would be much appreciated. Thanks.

Update: Yay! its back online... :-)

Now that we have releveled i think we should consider what the new minimums will be for joining the various usergroups.

I have a number of people asking to join PMDEV and i dont want to respond until I know what the rules should be.

<p><small>
$c_date Considered ([$considerer]): <i>$c_reason</i><br />
$u_date Unconsidered ([$unconsiderer]): <i>$u_reason</i> (Keep: $k, Ed
+it: $e, Reap: $r)
</small></p>
[download]

(2005-12-06 18:11) Considered (rinceWind): Retitle: omit "daft"
(2005-12-06 21:10) Unconsidered (holli): Enough Keep votes (Keep: 8, Edit: 7, Reap: 0)

Similarly, I saw bart's pending patch to replace perldoc.com (whatever happened to that?) and wondered if instead using the new annotate site might be "better"?

This is a report of a possible bug (suspected to be an interaction between "Render spoiler settings" = span and "html error reporting" = 3) seen in the rendering of The anomalous each()--Part II.

ww was using Firefox 1.04 on w2k. See CB quotes below in which ambrus ( galeon, linux-i686, gentoo usually. sometimes firefox on the same machine or firefox on debian linux-x86_64) confirms seeing same. (I was too late asking Tanktalus for broswer and OS info.)

Using VIEW | SOURCE, code (with two comments added by ww) appears as:

...
<p>Can you see why?

<span class='spoiler'>
# /----------------- ww thinks problem is here ---------------\
<font color="#808080" class="htmlinserted">&lt;/span&gt;</font></span>
+</p><p>Whilst I suspect that many people will jump on the use of each
+ in a scalar context as the source of the problem, the actual cause i
+s using <tt class='inlinecode'>%h</tt> as an rvalue.

</p><p>My (tentative) explanation is that not only is there only one i
+terator per hash, but that iterator is also used internally when a li
+st is generated from a hash.

<font color="#808080" class="htmlignored">&lt;/span></font>
# ww thinks the end span should be  -----------^
#    though this <font ... /font> seems effectively a NoOp ???
[download]

(Edited) CB coversation beginning at 005-11-19 13:02:19-05 included for its info value:
ww: OP's spoiler appears as a spoiled </span> after "Can you see why?"
belg4mit WFM
Tanktalus: Doesn't seem borked to me...?
ww: firefox 1.04 on w2k is rendering the node with the spoilt (right after "Can you see why?") and rendering the next two grafs in the clear
ambrus: what's your "Render tags as" setting in Display Settings ?
ww: set as "span" ... "error reporting" = 3
ww: "enforce nesting" is also set, which made rendered page show two spurious end span tags
ambrus: If I both set "spoiler" to span and "html error reporting" to 3 then it breaks for me too (enforce nesting is set to on already)

PS. hmmmphf (more puzzlement): in preview here, I get a warning that I'm missing a </spoiler> after the previous paragraph.

Trying for precision, but if this is more than is needed and useful, my apologies.

UPDATE: In case that's not clear, I am inquiring about:

1. Reaping me
2. Having me be an alias for the author

Now for the questions:

• how will we use the flag to stop reaping?

  E.g. we could use it to stop the node from being considered again by not showing the consider checkbox and textfield in the approval nodelet (probably too extreme).

  Or else we could use it in the approval nodelet and Nodes to consider by not showing the 'delete' radio button.

  Or else we could use it in consider by not invoking reapnode if the flag is set.

• Should the flag be stored in a setting (e.g. approval nodelet settings) or in a (new) table?

Thanks for all ideas.

I've just ported the Keyword Search superdoc (which will only be visible for pmdev, currently), over from the test site. For those that can't see it, its very similar to the Perl Monks User Search with a dropdown list of all currently used keywords to select from.

Anyway, the purpose of this discussion, is to outline some FAQ which will suggest how people should go about tagging nodes, such that useful searching is possible. I've been doing some tagging of my own already, but for global use this needs to be documented.

My suggestion for this would be something like:

• If a node mentions a module or its question can be solved with a module, tag with the module name, eg "IO::Socket".
• Always use common capitali(s|z)ations/spellings of nouns, eg "Perl6", "Perl/Tk", "SOAP" - (Though I hope the search is/will be case insensitive anyway)
• .. ?

The doc also needs to mention that keyword deletion can be done by editors^Wjanitors, and a consideration/editor request/msg can be used to accomplish such.

Also I'm wondering if we shouldn't have a "tagging group" who will put official tags on things, so the search can either search "official" tags, and "everything else" (Can be accomplished by adding a column to the keyword table for the user_id, where the id==tagging group for members of that group).

Please add your ideas about the documentation to this discussion, thanks.

C.

ysth put in some great work in last night deprecating a bunch of unused infrastructure nodes. I was wondering if we could come up with some kind of mechanism for marking said nodes so that they can be reused at a later point. IMO its preferable to reuse older infrastructure nodes than it is to just create new ones...

The question is how to mark them? Via a faqlist perhaps?