In brief, my notion is that one symptom/by-product/whatever occuring when pm is overloaded/slowed-for-whatever-reason, users tend to experience inadvertent creation of dup posts.

Perhaps this note will intrigue a more highly skilled dev to confirm (and fix?) or refute my suspicion.

The idea would be to create a section, rather like Perl Monks Discussion, but which would be accessible (both read and write) only to pmdev, for the purpose of discussing ... well, anything pmdev wants to discuss internally. This is to get away from using the wiki for such discussions, since — as has been pointed out on several occasions — wikis are not a good medium for discussion. Looking at the history of wiki rollovers, it's clear that a lot more has gone on in the pmdev wiki than any other, and undoubtedly most of that volume was for discussions.

What do y'all think of this idea?

It would be pretty easy to do. The steps involved would be as follows:

1. Clone pmdevtopic into pmdevroot as a subnodetype of pmdevtopic, setting Creator=Updater=pmdev.

2. Make a pmdevroot display page like so:

<p><i>
  [% linkNode $$NODE{author_user}; %] has initiated the following pmde
+v topic:
</i></p>
<p>
  [{parselinks:doctext}]
</p>
<p>
  [{editinvote:Your Topic}]
  [{shownote}]
</p>
<p><center>
  Back to [% linkNodeTitle('Pmdev Discussion') %]
</center></p>
[download]

3. Make a new section superdoc like so:

[{get_sitedoclet}]
[{newlistapproved:pmdevroot,perlquestion approved linktype,Pmdev Discu
+ssion,15,navbaron,showall}]
[{addnewform:pmdevroot,Initiate Pmdev Discussion}]
[{showhints}]
[download]

4. Other ancillary things, such as adding awareness of the new section/nodetype to Newest Nodes (for pmdev only, of course).

It might be nice to name this new type "pmdevtopic", but that nodetype name is already used, by root posts of the Inner Scriptorium. We could rename that nodetype, to something like "manuscript" (in keeping with that section's name), freeing up "pmdevtopic" for the present purpose. tye says that such a renaming would take about 12 patches.

Note that the reply node type already exists: pmdevnote.

The following list details (IMO) the steps necessary to move from plaintext passwords to storing hashed passwords, and also moving the infrastructure (password resets, initial sign-up etc.) to accomodate hashed passwords. All steps can be taken without interruption. I'm not sure if my approach of using hashes for "activation" and then resetting the password only when that "activation" hash is submitted, together with the appropriate user id in the appropriate timeframe is sensible.

Discussion of the approach and/or the other changes is very much welcome, as is a discussion of what I named things. I'm bad at naming things, especially.

1. Table pending_activations ("new user entries", "password reset entries")
   1. user_id (for password resets)
   2. username (for new user signups)
   3. activation_hash
   4. expires default now()+12hr (MySQL 5.0, which we use, does not allow functions for default values :()
2. Add a password hash column to the user table
3. superdoc: activate_user( Int $user_id, Str $activation_hash )
   1. check user_id+activation_hash in pending_activations

      select user_id from activate_user 
              where user_id = :$user_id 
                and activation_hash = :$activation_hash
                and expires > now()
      [download]

   2. generate fresh password
   3. hash = &generate_password_hash( $USER, $passwd )
   4. store fresh password in user table
   5. store fresh hash in user table
   6. store fresh password in $USER
   7. send login cookie that's valid for this browser session
   8. display fresh password to user
   9. display link to "Log me in and give me a permanent cookie" (expiry=never)
4. htmlcode: generate_password_hash( $USER, Str $passwd )
1. generate hash from password+username+secret sauce
5. htmlcode: generate_activation_hash( $USER, Int expiry )
   1. generate random hash

      INSERT into pending_activations
              user_id, hash, expiry
      [download]

   2. return hash
6. User settings user edit page:
   1. hash = &generate_password_hash( $USER, $passwd )
   2. store hash in user table
   3. set cookie to hash
7. Everything/HTML.pm#::confirm_user

       $hash = &generate_hash( $USER, $passwd );
       # ... confirm via hash
       my $ok = $hash eq $USER->{passwd_hash};
       # if the hash-compare failed and the user still has a password, us
   +e that:
       if (defined $USER->{passwd}) {
           ... confirm via passwd
       }
   [download]

8. htmlcode: generate_activation_link( $USER )
   1. hash = &generate_activation_hash( $USER )
   2. return abs_url($settings{site_url}/?node_id=activate_user;user_id=$USER->{id};hash=$hash)

9. Activation

   1. add hash column to user table
   2. populate hash column by generating the hash from the passwd if it's not NULL
10. new user mail (975)
    1. don't display password
    2. display activation_link resp. change the template to generate the activation link
11. Password Mail (2514):
    1. don't display password
    2. display activation_link resp. change the template to generate the activation link
12. Deactivation of passwords
    1. set passwd to NULL
    2. remove code for storage of passwd from activate_user()
    3. drop passwd column from user table after all users have been migrated (select count(user_id) where passwd is not null) == 0

Update: Corrected node links, added topics as per ig's reply below

Further Update: Found out that MySQL doesn't support functions in default values. Changed names to fit reality.

Recently I compiled an annotated list of all of the database tables used by the PerlMonks website (see PerlMonks Data Model). bobf has expressed an interest in collaborating on it with me and I think that is a wonderful idea. In fact, we'd like it if we had an entire collection of pages that pmdev's could add remove, and edit as a group without godly intervention.

As anyone who checks the data model on my extra scratchpad will note, it is nearly at the 64K limit and there is still much information to add. It badly needs to be broken up into subsections, each with their own page. And of course those pages need to be communally edited. It would be even better if (a) we could see an edit history of all edits with undo, redo ability (b) we could assign pages to multiple categories and have category lists auto-generated (a la mediawiki). We have found both those features extremely useful on large collaborative documentation projects (including the mediawiki documentation itself!).

A collaborative environment for pmdev documentation could also be used for much more than just the annotated data model on my extra scratchpad. The documentation for pmdev is scattered in many places, including the wayback machine. A collaborative documentation environment would let us consolidate the existing documentation into an internally consistent corpus and make it easier to keep it up to date.

The ideal environment for collaborative pmdev documentation may require some work. In the meantime, bobf and I are eager to get to work and we already have some things that come pretty close to what we need. As an initial first step, we were wondering if we could copy the infrastructure used by SiteDocClan to create a set of internal pmdev documentation parallel to the public site documentation?

This would involve creating the following new nodetypes:

• DevFaqlet:: similar to sitefaqlet. These would be used for group edited documentation pages. pmdev's should have full rights to add, delete, and update the pages. Deleting is important because leaving around irrelevant documentation can be very confusing. When pages are broken down into subpages, one doesn't always get the arrangement right the first time. It is important to be able to reorganize information easily without leaving the old not-so-good organization lying around. The cabal should have read access.
• DevFaqlist: similar to faqlist. These would be used to thematically group devdoclets. pmdevs should also be able to add, remove, and edit these lists at will. The cabal should be able to read them.
• DevFaqstring: similar to faqstring. Again, pmdevs should also be able to add, remove, and edit these at will. The cabal should be able to read them.

Using existing infrastructure also has another advantage. As we begin working on documentation together, our ideas about what we really need will take a firmer form. Once we have more experience working together, we can reopen the issue and discuss requirements with more clarity.

Best, beth and bobf

<b>This node:</b>
createtime: `createtime`<br>
&#91;id://`id`]
[href://?node_id=3333;parent=`id`|replyto] 
[href://?node_id=`id`;displaytype=xml|xml] 
[href://?node_id=`id`;displaytype=raw|raw] 
[href://?node_id=`id`;displaytype=viewcode|code] 
[href://?node_id=`id`;displaytype=edit|edit] 
[href://bare/?node_id=`id`|bare] 
[http://prlmnks.org/rss/`id`.xml|rss] 
[href://?node_id=`id`;displaytype=edithistory;limit=25|rje] 
[href://?node=`title` sitedoclet|doclet] 
<a href="`url`" id="page_url">url</a> 
[http://corion.net/perlmonks/`id`.xml|orig.xml]
[href://?recipient=`id`;type=strangedoc;node=message%20inbox|inbox]
<br>
<form method="post" action="?" enctype="application/x-www-form-urlenco
+ded">
Search in code:
<input type="hidden" name="node_id" value="157620">
<input type="hidden" name="sexisgood" value="submit">
<input type="text" name="searchterms" size="40" id="codesearch">
<a href="/?node_id=157620;searchterms=`title%`">or "`title&`" directly
+</a>
</form>
<br>
type: &#91;id://`type_id`|[id://`type_id`|`type_title`]] [href://?node
+_id=106927;whichtype=`type_id`|Node lister]<br/>
parent: &#91;id://`parent_id`|[id://`parent_id`|`parent_title&`]] [hre
+f://?node_id=`parent_id`;displaytype=xml|as xml]<br/>
root: &#91;id://`root_id`|[id://`root_id`|`root_title&`]] [href://?nod
+e_id=`root_id`;displaytype=xml|as xml]<br/>
author: &#91;id://`author_id`|[id://`author_id`|`author_title&`]] last
+here: `lasthere`; lastupdate: `lastupdate`; 
[href://?node_id=6364;user=`author_name`|writeups]; 
[href://?node_id=434853;editor_user=`id`;filter=only;Wi=1;SDC=1;Ped=1|
+author's RJE]; [msg://`author_id`|/msg]<br/>
lastedit: `lastedit` (doc; null) (pretty much just [wiki]s)<br>
<!--
nodeupdated: `nodeupdated` (node; null) (used for patches)*<br/>
*code exists to update <tt>nodeupdated</tt> when a node's hit count is
+ updated.<br/>
-->
<br>
group: `group` 
<br>
[download]

Updated with planetscape's suggestion and some other ideas; deleted cruft; rearranged.

Currently, the edithistory (i.e. that data displayed by Recent Janitorial Edits) is only used for logging edits to the document content of nodes (under certain circumstances). There are several other kinds of janitorial actions which do not get logged — for example, moving a node to a different section. I know there've been times when I wished this other kind of info was logged in the edithistory.

I made one change recently in this direction; it could be called a proof of concept: if you move a node using the Moderation Nodelet (which, btw, is deprecated in favor of the Approval Nodelet), this gets logged.

So, what do we think? Should we log more janitorial event types besides node content editing? If so, what types should we [not] log? And why?

Update: Here is a list of the possibilities:

1. Approve for section
2. Unapprove for section
3. Approve for front page
4. Unapprove for front page
5. Move (root) to other section
6. Reparent (make it a reply of another node)
7. Promote (convert a reply into a root)
Added 2015-07-07:
8. Unconsider. Capture the details of the consideration; otherwise they'd vanish without a trace. (user, reason, date. maybe votes?)

IMHO, we almost certainly do not want to log #1 and #3, as those are far too numerous, and of relatively little importance. And at any rate, the info on a node's current approval status is already being stored elsewhere.

I am suggesting that all of the usergroups' (primary) wikis be renamed to be consistent with the formula groupname wiki. This will make it much easier for users to link to wikis, as the names will be completely predictable.

The wikis which would be renamed are:

There are a few places where links might have to be updated, e.g. in the various nodelets, and probably a few places in the site doc. Other than that, would such changes have any impact which would make doing so a less than good idea?

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.