Re: Proposal for a comments system



On Sun, 2010-04-04 at 22:45 +0100, Philip Withnall wrote:
> On Sun, 2010-04-04 at 16:08 -0500, Shaun McCance wrote:
> > To reduce spam, we can require a particular User-Agent in
> > the HTTP request. This won't stop anyone who wants to spam
> > our system specifically, but it will block general-purpose
> > spambots.
> 
> General-purpose spambots could still operate through library.gnome.org,
> if we're going to have commenting enabled there. Perhaps a CAPTCHA could
> be used for the library.gnome.org interface?

Sorry, I actually meant to address that, but forgot. That's
exactly what I was thinking. Don't do any human test on the
comments server, but do have a CAPTCHA for any public web
interface that submits to it, like library.gnome.org.

> > People with accounts will be able to log into the comments
> > server with a web application. They will be able to close
> > comments with a status like "resolved", "invalid", "spam",
> > or "troll". Closed comments won't appear anymore. I don't
> > think we need to be stingy about giving out accounts. If
> > we could somehow tie it to git accounts, that would make
> > life easier for us.
> 
> Would closed comments still be stored for reference purposes (like
> closed bug reports)?

Yes, I'd keep them in the database. I probably wouldn't
focus on browsing closed comments in the first revision
of the web admin interface. But the data will be there,
so we can add features as we go along.

> Probably also need a status for "duplicate".

There will surely be duplicates, although hopefully
people will tend to read comments before submitting
new ones. But I think it might be too much overhead
for admins to hunt dup numbers and mark things as
duplicate.

> > Comments are per-page, and also per-language. Translators
> > will be able to translate comments into English. These will
> > be tied together on the server, so that when we close the
> > translated-into-English comment, the original is closed as
> > well.
> 
> What's the purpose of having per-language, translated comments? As I
> understand it, comments as you are proposing them are basically mini
> bug-reports about the documentation, and are all meant to be resolved
> through updates/extensions/improvements to the documentation. If that's
> the case, why would the comments need translating?

If we look at this just as a comments system, where
users are helping other users by providing their own
experiences and insights, then it's important to let
them comment in their own language and to view other
comments in their own language.

But as you point out, this also serves as a simple bug
reporting system. I fear non-English comments will just
stagnate if documentation people can't read them. So we
have translators translate them to English so that we
can address them and close them.

> > There are a number of benefits to doing this. We get real
> > user feedback on what we're writing. That's huge. Because
> > Yelp will have to ask the server for the comments for each
> > page, we also get some metrics on which pages are visited
> > most. And people tend to use things more when they're
> > directly engaged.
> 
> Could we have some more detail on these ideas for page view statistics?
> Should there be a way for people to opt out of their usage of help pages
> being logged? (Don't know why anyone would, but it should be
> considered.)

That's a good question. Here's what I was thinking on
the more technical side: Pages would declare a comments
server in the metadata. When Yelp loads a page, if it's
never connected to that server before, it shows an info
bar asking if it's OK to get comments from that server.
So you'd only get nagged once for gnome.org, but then
if you loaded a page provided by Ubuntu, and Ubuntu has
a comments server running, you'd have to OK ubuntu.com.

I would actually *love* to get real usage information,
like the click paths people take to a page, or search
terms people use. But it's borderline evilish to send
that information without an extra opt-in that tells
users exactly what we're sending. And that's just not
the sort of opt-in you can feasibly ask for in help.

-- 
Shaun McCance
http://syllogist.net/



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]