On Sun, 2010-04-04 at 17:22 -0500, Shaun McCance wrote: > 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. Sounds good. > > > 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. Great. > > 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. I didn't mean for comments closed as "duplicate" to have a dup number associated with them — there's no need for that kind of level of detail. I merely thought that having a "duplicate" status would be more informative than closing all duplicates as "invalid", or something. > > > 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. Thinking about it some more, having the comments translated through the system makes sense. My alternative was for each comment to be translated manually (by whoever's going through the comments e-mailing it to gnome-i18n), but I realise that's just going to create more work for no gain. > > > 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. Couldn't the opt-in for sending usage information to the comments server be the same as the one for downloading comments? i.e. You get three options: * Don't do anything with the server * Download comments only * Download comments and upload usage information The default would be the first option. Regards, Philip
Attachment:
signature.asc
Description: This is a digitally signed message part