On Mon, 2010-04-05 at 09:40 -0500, Shaun McCance wrote: > On Mon, 2010-04-05 at 00:28 +0100, Philip Withnall wrote: > > On Sun, 2010-04-04 at 17:22 -0500, Shaun McCance wrote: > > > On Sun, 2010-04-04 at 22:45 +0100, Philip Withnall wrote: > > > > 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. > > Well, they can be marked "resolved". The reason I allow users > to submit their email address, even though we don't display > it, is that we can send them a quick message when we resolve > their comments. I think "duplicate" is only useful if we can > identify what it's a duplicate of, and send the user the same > response. > > Although, I've been thinking that resolved comments might need > to be marked with a version number. That way they still show > up on older versions of the page that don't have our fix. In > that case, maybe it is useful to mark duplicates so that only > one of them shows up. Are there any situations where the fix wouldn't make it to the version of the page which has the original comment? Any changes to the documentation should really be committed to the relevant branch, as well as git master, so I can't see why any comments should be left on any versions of pages once they're resolved. Are there any use cases for the comments system which would produce comments which wouldn't need to be resolved (in whatever way) by modifying the documentation? i.e. Are there any types of comments which should always be visible on a page? If there aren't, the system could just be a fancy interface to Bugzilla, automatically putting together a bug report with details of which part of the documentation needs to be changed. That said, that would make creation of a navigation metrics-gathering system a little harder. > But with versioned resolutions and duplicates, we're approaching > bugzilla-like complexity. This is going to require more thought > to address all these issues in a simple way. > > I think, however, that most of this can be added server-side as > the need arises, without affecting the external API. So maybe > we just start simple and grow as needed. Yes. That way, Bugzilla, Launchpad (for Ubuntu's documentation) or some custom server can be used on the server side without problems. > > > 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. > > That might work. I think "upload usage information" needs > some extra explanation, but if the dialog is too full, I > fear it will be intimidating. Maybe some sort of disclosure > or on-demand help balloon. Sounds good. Philip > -- > Shaun > > >
Attachment:
signature.asc
Description: This is a digitally signed message part