Hi,
As a technique of fighting spam, has the <a> link tag "rel=nofollow"
been considered? The major search engines won't use links tagged this
way to rank pages. Among others, Slashdot and some of the major blog
engines use this technique, but RubyGarden currently doesn't seem to.
I apologize if this has been discussed and shot down already :)
http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html
http://en.wikipedia.org/wiki/Nofollow
--Aran
On 5/17/06, John Gabriele <jmg3000@xxxxxxxxx> wrote:
On 5/17/06, Conor Hunt <conor.hunt+rails@xxxxxxxxx> wrote:
> I had one idea to help with picking out good comments. Include a vote
> up / vote down mechanism for comments. Then it is easier to pick out
> comments that hit a certain threshold (either up or down) for
> inclusion or exclusion.
Sounds like a good idea. You might even consider having a
"voting_weight" score as part of each user's account. So, if their
comments get rated highly, then their votes will count for more.
Doesn't seem to hard to implement -- just make sure users can't
vote-up their own comments. ;)
(Note: in this post I've referring to the folks who add comments as
commentors, and the folks who scoup them up, put them into source code
files, and commit them to the Ruby source code repo as committers. I
refer to the Rannotate Ruby docs site as RA-Ruby.)
Another idea to make life easier on the committers: when a commentor
clicks to add a comment, it would likely be wise to have the resulting
text field accept RDoc marked-up text. With comments stored as RDoc,
it becomes trivial for a committer to access that same RDoc'd text so
they can:
1. copy-and-paste it into their editor,
2. use their editor to add a comment marker (#) to the beginning of
each line, and then
3. save and commit the file.
An added bonus to that is that it gets more people familiar with RDoc
markup. More people writing RDoc's is good! :)
Conor previously wrote:
> [snip] Maintainers only have to go through the comments when
> they are updating the official docs, which is on their schedule.
> I don't think they need to continually be monitoring.
If I was a committer, I would not try and go through the whole site
getting a big "doc release" full of updates together on a schedule.
Instead, I'd do it piecemeal. Pick a module every few days when I've
got some time, and see what the commentors have to say about it. If it
looks like there's some good comments, maybe it's time to update the
docs for that particular module... Hmm... wait -- it gets better.
In fact, if you're rating comments, then it's only a small step from
there to sum all the comment's ratings for a given module and rank
them on a separate page of the site (The "ripeness" page -- ripest
modules go at the top). This way, a committer with some spare time can
take a quick glance at the ripeness page, scoot over to a module
that's ready for the picking, and update the docs for that module.
Hm... you'd have to then have a comment-specific flag that indicates
if the comment has been assimilated (by some committer) into the
source tree. If it has, then it shouldn't count as part of the
ripeness. Once the RA-Ruby site freshens its content from the official
source, the comments flagged as already being "picked" should be
removed from the site (or possibly archived in the compost_heap).
Finally, it might also be nice to have a top-commentor's ranking page
(Top RubyGardeners!) and also a top-committers ranking page... just
for fun -- for bragging rights. I know seeing my name in lights would
encourage me even more to get some good docs in there.
---John
|
