Better yet (or in addition), should usergroups have a flag in the database (where?) to show that they are allowed to receive messages?

Update: tye proposed the clever idea of having messages directed to usergroups with just one member automatically go to that member (so msgs to editors would go to janitors). Because it was easiest, I made this happen only when the member is also a usergroup in message - (patch). If this is applied, all existing editors messages should be sql-updated to belong to janitors.

I would like to add a feature to the Janitors Thread Retitler where a '-u' switch on the command line would cause the root node being retitled to be unconsidered automatically. Currently this could be done in two steps. The first step retitles the node, and submits the change. The second step would select the proper radio button in the Approval Nodelet and click the moderate button. That requires two hits to the server, and requires that the janitor using the script ensure that (s)he has the Approval Nodelet turned on.

I could cause the node to get unconsidered in the same step that it gets retitled, requiring only one hit to the server, if there were an "unconsider" checkbox in the editors view. This would have the added benefit of not breaking if the janitor using the script had his/her approval nodelet turned off. The checkbox should pertain to the same form as the title and text editboxes, so that only one submit click is needed.

I looked at the code for the Approval Nodelet to see what it would take to add an "unconsider" checkbox to the editors displaypage. I'm sure that with enough time I could figure out what I'm looking at in the Approval Nodelet, and how to apply what I learn to the editors displaypage. ...with enough time.

If anyone else out there is already familiar enough with these segments of code that they could add this feature, doing so would enable me to implement the -u option in the Janitors Thread Retitler much sooner. I'm sure that even the Janitors who don't use the retitler would appreciate being able to edit and unconsider in one step instead of two.

Arunbear 2004-11-30
Yesterday, 410798 was blessed (or cursed?) as an offtopicroot. It was also considered for a retitle - 'add OT to title' (I voted 'delete'), but was finally unconsidered without the title change being made.

Is this now the official way to deal with off topic posts? If so, an announcement needs to made to that effect. Also, the Consideration and Editor's guidelines would need updating.

---

castaway, 2004-11-30
I did both of those. The unconsideration was because we (as editors) currently cant edit offtopicroot nodes, I should have edited first, then moved, but didnt. So now I have it in my TODO to fix, should anyone apply my patches to allow editing off offtopicroot nodes. (Or fix otherwise, should someone decide this isnt desirable). There are no official or hard and fast rules for 'what is offtopic', everyone has their own opinion on it, unfortunately. Its more of a 'you know it when you see it', thing.

For the curious, my scale goes something like (for SoPW):
OnTopic = Contains perl code, asks how to do something in perl, how to install/setup perl
BorderLine OnTopic = Algorithms (using perl code preferably), SQL using perl/DBI, file permissions in perl etc. pp. CGI problems when using perl, HTML/jscript (extreme borderline)
OffTopic = Linux installations, Apache installations/config (borderline when its directly about mod_perl/cgi), how to do stuff in other languages (borderline = communicating between them and perl), computer unrelated (tho we hardly get those)

As for the other sections, in PMD anything about the site is ontopic, everything else isnt; in Meditations theres room for philosphising about programming in general .. Theres probably some stuff Im forgetting. The biggest difficulty is when a question is posted, and its not immediately obvious that its about perl, try to assume it is, unless .. well hard to tell how otherwise. If its not obvious, then post a reply asking for clarification, before considering for OffTopic.

When Ive moved my Moderation changes over (soon, I promise!), I was planning to have a go at improving considerations, eg: consideration history for nodes, msg to author on consideration, msg to considerer on edit/reap/unconsider (with reason), more concrete consideration reasons.

---

tye, 2004-11-30
offtopicroot was a proof of concept. I haven't seen any concensus on actually making use of it, so I don't think using it is advisible (except as part of proving or improving the concept or trying to stimulate a move toward concensus on more of the issues surrounding off-topic nodes).

---

castaway, 2004-12-01 (Happy December!)
Hmm, ok, moved node back to perlquestion, retitled, and unapproved it.

---

This is one possible solution to the problem of what to do with off-topic posts. Please share your thoughts...

Updated (2004-12-05) as per tye's correction.

(Noticed while using davidos thread retitler, and passing it a 7-digit nodeid accidently.. ,)

C.

The following discussion has been shamelessly lifted from the editors wiki, at tye's sensible suggestion.

castaway, 2004-11-23
Folks, Any objections to raising the number of keep/edit votes needed to prevent a reap? (We can raise the number of reap votes needed too if need be) - reason, there are many more >lvl5 than there used to be, so more likelyhood of bungled votes, IMO. In fact, having these as some (small) precentage of the number of users >lvl5 would fix it for good..

ysth, 2004-11-23
The larger number of senior monks means more lemming-votes too. I'd rather keep it at 2 even at the cost of more trouble for janitors/gods.

davido, 2004-11/23
I could see raising the number of keep/edit votes necessary to block reaping to three, or at the very most, four. I believe also that there should be a minimum consideration time, so that if enough 'delete' people jump onto a node quickly to get it reaped, the system still gives a few minutes for voices of reason to weigh in. Maybe it could be something like this: If there are zero keep votes, the consideration lasts ten minutes. If there are one, two, or three keep votes, consideration lasts an hour. And if a fourth keep vote comes, reaping is effectively blocked.

Editor deletes wouldn't be subject to the wait period. This will allow a few Janitors to jump on something truly offensive if necessary.

Let the discussion begin...

Wiki discussion was edited prior to posting in Inner Scriptorium, to put the wiki comments in forward chronoligical order (as opposed to wiki-standard reverse-chronological order).

i haven't had much time lately to devote to perlmonks, and i've been not only impressed with the recent pace and scope of changes, but inspired by it. i'm happy to see the many new css classes, and happy to see that the css is valid as per the w3c css validator.

i'd like to see the same for the html markup, which doesn't validate to any x?html variant. the markup is defined as html 4.0 transitional, but there are some xhtml-style tags used throughout. i'd like to apply patches to help make this site validate, but before i start making changes, i'd like to confirm the target doctype. personally, i'd prefer aiming for xhtml, but if the decision is to stay with html 4.0 transitional, i'll aim for that.

anyone?

I was looking into some CSS/HTML related issues today and came across a weird but apparently quite useful trick for working around IE related problems. IE supports something called "html conditional comments", like this:

One variant allows HTML to be embedded that is ONLY seen by IE. IE will magically uncomment the group if the conditional is true. The comment like construction causes non IE browsers to treat the whole thing as a normal comment.

<!--[if IE 5]>
<p>This will only show on IE 5.</p>
<![endif]-->
[download]

The second variant will NOT be rendered on IE browsers (IE will magically remove the block if the expression is true), but WILL be rendered on NON IE browsers:

<![if !IE 5]>
<p>This will only show if NOT on IE 5.</p>
<![endif]>
[download]

The problem obviously is that our square bracket linking mechanisms will b0rk this totally. As I think this could be a really useful way to work around a number of IE related oddities I think its worth seriously considering the changes required to NOT bork it.

Anyway, just thought i should bring it up.

• patch wikipermissionmenu: done
• adjust wiki permissions as desired
• adjust ReLevel's in super search
• patch other hardcoded 10's, 11's, whatever
• mark level setting as obsolete
• patch level experience
• patch level votes
• decide how abilities mentioned in the level faqs should be apportioned
• add/modify level faqs
• patch level faqlinks
• review rest of relevant site doc
• etc.

Perhaps I am being naive, but could it be as easy as creating a new nodelet that just called showprivatemessages?

Am I thinking down the right track?

One of wikis good features was to see directly from the Cabalists' Nodelet if they were modified since the last visit or not, thanks to the asterisks.

Now with the Scriptotium, we could use the Newest Nodes or the prettiest Recently Active Threads (thanks again demerphq, you made a really good job), but... ...the Scriptorium had been forgotten from NN User Settings!

More precisely, the list hasn't been updated and is still containing a "Site Manuscripts".

May be with a little help from our devils?