I've thought of this question before, and thought it would be a cool statistic, too: to know ++'s vs --'s of a node, although I would only think it a useful breakdown for one's own nodes, not ones written by others. And I've seen this answer ("join pmdev, write the patch!) before, too. After a brief Super Search, I found this node, pmdev user group, and am wondering - is this still the way to join pmdev?

In some ways, it would be nice if we could see the code prior to trying to join pmdev. That way, we'd know (or have an inkling of an idea) that we'd be overwhelmed, and be much happier in the areas of the site that way may think need improving. But, it is neither my site nor my code. Seeing that it is what it is, this is just an observation, not a complaint ;-)

Tanktalus,
Speaking completely non-authoratatively, I would suggest /msg'ing the pmdev group. There is a group inbox - several monks have become devils that way. WRT your comment about being able to see the source first - that is another issue that has been raised several times in the past (Super Search if you are interested).

Cheers - L~R

I can see it now L~R, 2000 queries about becoming a [id://pmdev] member! Does the [id://pmdev] group need that much help?

. o O (Maybe I should ask about joining!) O o .

. o O (No, they would throw me back for a better model!)

Paulster2


You're so sly, but so am I. - Quote from the movie Manhunter.

As far as I am aware, the Everything engine as used elsewhere http://everything2.com for example, keeps and displays a separate count of ++ and --. So, there's probably not much dev work, just some detective work and merging.

--
I'm Not Just Another Perl Hacker

Nope, not a lot of dev work at all. After following Limbic~Region's advice, I got to see the code (by joining pmdev). After about 10 minutes of searching and looking around, I figured out at a conceptual level what I would need to do, and I figured it would end up being about 5 lines of code added, and perhaps a couple lines changed. That's the easy part.

Next on the agenda is to do it and test it, then submit it. Discussions may break out anew, wars started, people killed. That doesn't concern me. I need to figure out how to test it. Nothing is worse than submitting an untested patch :-) The few CPAN modules I've submitted patches to have always been tested prior to even asking questions about them, let alone submitting them. I don't want to change that habit - at least, not quite yet. :-)

I'm hoping a few more minutes of searching will reveal how this is done, but that'll have to be done later, I've run out of time for this right now.

PS - so far, all the code I've looked at has been quite good. The only differences between how I code and how the code is written are in generally accepted contentious styles (e.g., "one-true-brace-style" vs other placements of bracing). Absolutely nothing has grated on me, so I'm quite impressed. :-)

Yes, making the presense of downvotes easier to notice and thus increasing the frequency of whines about downvotes would suck. The remaining code isn't hard to implement (most of the harder parts were done quite a while ago -- I think the updating of old nodes still needs to be done, and I'll do that after the new node cache is put into production).

A tricky part is designing how/when to present the information to provide some benefit while avoiding most of the potential problems (as I discussed in more detail previously).

- tye