One of our esteemed monks yesterday proposed to let the cpan:// shortcut type (or "pseudoscheme") have meaningful behavior when written with no parameters ([cpan://]). Seemed reasonable enough, but I don't feel that cpan:// should be special in this regard; so I'm proposing that all shortcut types be similarly extended — or at least those for which some such reasonable behavior can be identified. Specifically, I propose that the following PerlMonks pseudoschemes render as the corresponding link in the parameterless case:

Note that the specific link texts shown above are merely the default; per the usual operation of shortcuts, explicit link text, if given, overrides the default.

Pseudoschemes not listed above either:

1. are special in the parameterless case (e.g. localtime, pad)
2. don't have obvious useful semantics in the parameterless case (e.g. http, id)
3. are aliases of pseudoschemes listed (e.g. docs, kobe)

I propose that any/all occurrences of the term "unmoderated" in site pages be replaced with "unapproved" — for example, in User Settings, the setting currently labeled "Show Unmoderated Content".

The issue is that, specifically in PerlMonks terms, moderation != approval; and more generally, content being moderated does not carry the same meaning as being approved. I would argue that, in fact, moderation usually carries the sense of something done to undesirable content to make it go away. That's not quite how it works on PerlMonks, of course; but even so, the terms are not synonymous. And the bottom line is that there's no reason to use an arguably somewhat inaccurate or ambiguous euphemism ("moderation") in place of the straightforward "approval".

I'm planning on making all the relevant changes myself; but I figured I should raise it up for discussion first, in case anyone objects.

SiteDocClan have the ability to create alphafaqlets, which are like normal sitefaqlets except they are only visible by SiteDocClan. The idea is to let the author "submit" the FAQlet to the rest of the Clan for review before it goes public.

I believe this feature would be more useful if draft FAQlets could be reviewed by more people before going public. Therefore, I'm proposing that AlphaFAQlets be visible to the entire Cabal.

I would simply have written a patch for this and let it go through the normal patch review/ignore process; but the change involves modifying a node field, rather than patching code.

Update: as of Nov 10, 2006 at 19:00 UTC, this has been done. Thanks, tye!

I have the cleaner for the PerlMonks backup dumps ready in some way, but I have some questions remaining on the tables which are needed for Everything operation. Especially the various approval tables escape my understanding - which of these tables are necessary?

What follows is the relevant excerpt of the config file I use to drive the process of copying/purging/passing the tables from the MySQL mysqldump files into a fresh dump file which is cleaned of sensitive data. I hope it is self-explanatory - "output" copies the CREATE and INSERT statements, "drop" removes the CREATE and INSERT statements, "purge" only copies the CREATE statement.

output approval (approved_id,user_approved,whenapproved,status)
output approvalhistory (approves_id,user_approves,whenapproves,section
+_id,action)
output approvalstatus (approved_id,user_approved,whenapproved,status)
output approved (user_id,node_id,action,tstamp)
#output approves (approves_id,user_approves,whenapproves,action,sectio
+n_id)
drop approves

drop backup_scratchpad
drop backup_user

# What is protouser?
drop protouser
# ???
drop rating

# These seem to be more used
drop testpolls
drop testpollvote

# The stuff in the tomb is gone for mortals
purge tomb

#version.version_id
#version.version
drop version
[download]

Any hints on what other tables can be dropped are welcome too.

I'm looking at nodesWithinDays because I'd really like to be able to alternate colors sorta how we do for the chatterbox. However, I see we set each row's class to "node-from-#####" based on who wrote what. I'm proposing that we change it such that alternating rows get the "highlight" class, and the actual td's get the node-from-##### class. This may break the expectations of a few odd people, but I don't see how we can do background colours any other way.

Instead of just submitting such a patch, I would at least like to gauge the acceptableness of this to both the users at large, and the gods who would apply it. Something tells me not to bother, although I have to admit that being able to tell who wrote what really easily has been bothering me for quite some time, especially when some of the node titles are really long. And narrowing the width of my browser just for the Newest Nodes page seems a bit annoying as well.

I was thinking it would be nice to be able to enable another user to act as ones proxy in limited circumstances. The way it would work is that the user would send a special private message to the proxy account, stipulating what resources the proxy may access on its behalf. So for instance i might want to let im2 send public chatter on my behalf, so i would do something like:

/msg im2 permit:chatter
[download]

and then when im2 when to send chatter on my behalf op message would look to see if there was a message like that from me, if there was, then it would be allowed. By deleting the message from the users inbox the permission would disappear. A bit of added infrastructure would allow sending the right message, and of putting it in the archive inbox automatically, and not in the deleted as normally happens.

It seems a simple way to provide this type of functionality, and it doesnt compromise our user communities resources.

Certain sections have categories, including (but (not?) limited to?): Tutorials, Code Catacombs, and Categorized Questions and Answers. Wouldn't it be cool if they all shared a common set of categories? If they did, then an enhanced synergy among these sections becomes an intriguing possibility.

Update
Take a look at the categories which currently exist in those three sections:

There's something about this discrepancy that I find inelegant. Wouldn't it be nice if we could sync up the set of categories in each section, and keep them in sync going forward?

Update2:
I'm thinking it would be nice to have a category-centric view which cuts across the sections — or rather, ties them together. For example, if someone is interested in CGI Programming, they know where to go for tutorials, for FAQs, and for code samples/solutions.

I guess, when you come right down to it, the sections, as they're presented, are table-centric, which is to say, low level, but not necessarily natural from a user's perspective. Imagine a site doc with an index with entries like so:

• CGI Programming tut faq code

Fortunately, what I'm proposing doesn't involve any site code changes. Just some coordinated efforts among the Pedagogues (for Tutorials), Janitors (for Code), and QandAEditors.

I recently fixed the wp:// link handler so that it goes to wikipedia's search function (which is smart, like PM's Search box, in that it goes directly to the matching page if there's only one).

This led me to thinking about other shortcut types as well. As a result, I'd like to make the following patches to handlelinks settings:

• add e2:// which goes to http://www.everything2.org/
• add imdb:// which goes to http://www.imdb.com/ (the "internet movie database")
• add c2:// which goes to The Wiki
• change jargon:// to go to the source, http://www.catb.org/~esr/jargon/html/
• change dict:// to go to http://www.dict.org/

Someone in the cb also suggested adding a shortcut type for del.icio.us. Could be fun, but I personally don't see much utility in it. Opinions?

What kinds of updates do we want to end up setting this field?

Obviously user edits to the doctext (for types including document). IMO changes to the title should also set it, as should changes to fields of non-document types (e.g. snippets). I'd also want Q&AEditor/SDC/janitor/pedagogue changes to set it. I don't care one way or the other whether hitting "Update" without having changed anything updates it. The field should probably be set the same as createtime at node creation (currently, lastedit often varies from createtime by one or more seconds because node and document are updated separately), not zero. Any other updates should IMO not set the field.

Implementation notes (some of which depend on things I say above that others may disagree with):

Having the lastedit field in document doesn't work for non-document types, or for having it match createtime, so it should move to node. I'd make it a datetime field, instead of a timestamp, since we don't want the magic autoupdate behaviour that timestamps have (though I think that only happens with the first timestamp field in the table). Also note that apparently timestamps are changed to return by default as strings as of MySQL 4.1. When the new node.lastedit field is added, it should be set the same as createtime.

Then the following changes should be enough:
Everything/NodeBase.pm (insertNode): add -lastedit => "now()"
Everything/HTML.pm (gotoNode) and handle_node_edits: fetch now() and set $NODE->{lastedit} to it before calling updateNode

When looking at places that list patches like regular posts (such as the Patches section of Newest Nodes, if you have it enabled), you see that the 'title' fields of patches contain generic, generated text, consisting of the name of patched node, with " - (patch)" appended. E.g. "monktitlebar - (patch)".

Would it be possible (or rather, how hard would it be) to have the text of links to patches use the 'Reason' field (as displayed in the Patch Lister) rather than the 'title' field?

(A rather limited-scope change for this effect could be implemented at around line 64 of nodesWithinDays. A global change for this effect could be done in linkNode, which is at around line 741 of Everything/HTML.pm.)