Launchpad itself

Bug #306378
Comment #3

Comment 3 for bug 306378

Revision history for this message

floid (jkanowitz) wrote on 2009-09-25:

Beating a dead (or already-acknowledged) horse here, but someone else's Slashdot comment - happens to be on a thread about a certain famous Ubuntu backer's commitment to cleanroom usability testing, yay! - echoes this issue and maybe explains it more succinctly: http://tech.slashdot.org/comments.pl?sid=1381337&cid=29535709

Fair-use quote:

8< - - - -
Re: STFU needs to be heard. (Score:5, Insightful)
by jc42 (318812) on Thursday September 24, @09:12PM (#29535709) Homepage Journal

> I always get asked, "How did you get good with computers?" To which I reply, "I was just able to read."

Well, the computer industry is slowly learning how to deal with people like you. More and more, they are implementing the "no documentation at all" standard. In the near future, it won't matter that you know how to read, because there will be no document anywhere for anything.

Actually, for Microsoft and Apple stuff, they're pretty much there now. Most of their new stuff has no written documentation at all. Their one remaining problem is that there are online forums where people actually write about such things, and google can quickly find them for you. But MS and Apple are working on ways of confounding that approach.

So soon you'll have no choice but to ask around to find out how to do something. If you do this via email or IM, your message will be hidden from others, so they won't be able to read the results.

I just wasted a number of hours trying to help a friend figure out how to deal with an incomprehensible Vista error message that makes logins totally fail. There are several thousand questions about the specific message online, and it appears that several hundred people have managed to fix it. But so far, none of the discussions we've found actually say what they did to fix it. So we've apparently hit a brick wall, despite all the bandwidth taken up by discussions of this particular problem. This illustrates how the MS community is learning to hobble those who can read, and ensure that there is nothing useful online on the topic.

Lessee; do I need a ;-) here?
8< - - - -

Back to me, restating my thoughts:

Big difference (in my mind) between a publicly-editable "KB" and Questions/Forums:

* a "KB" enforces deduplication in the same manner as a bug tracker, avoiding the above-described signal-to-noise problem.
(That comment happens to describe a Microsoft issue; Microsoft actually has a KB, like many projects/companies, and it can actually be useful if the KB editors have identified and worked out a solution for a given issue.)

Big difference(s) between my idea of a "KB" and a Wiki:

* More metadata, encouragement or requirement for "applies-to-version"/"applies-to-package" tags means better searchability and truthiness;

* Single-sign-on through Launchpad, so everyone subscribed to whine about bugs can also document workarounds, best-practices, improve on others' documentation, etc (erm.. separate wish, but in the meantime, maybe Launchpad should offer OpenID and the Ubuntu Wikis and Forums should accept it? Unless it already does now, been a while since I checked!)

* "Last approved version" vs. "Most recent version" per-topic is a more workable social approach to collaborative editing; avoids the "misincentives" to lock-down a Wiki; avoids the reversion-wars that can prevent an article from evolving healthily on one that does accept public edits. (Same model as the "stable" / "development-branch" approaches to software development. But people who can write good documentation are not necessarily people who enjoy using git for document-management. KBs are the blog-engines/content-management-systems of collaborative technical documentation.)

It occurs to me that you could basically reuse/repurpose a bug tracker for this directly - just use status to track 'work-in-progress' / 'discussing' / 'approved' / 'obsolete'. Only problem is that links would be fragile as old "articles" become 'obsolete' and an editor could only tack comments onto an 'approved' article (creating an 'approved' thread) instead of fully editing it. But 'approved' threads containing only *useful* information would still make it faster to find solutions / learn best-practices. :)

Beating a dead (or already-acknowledged) horse here, but someone else's Slashdot comment - happens to be on a thread about a certain famous Ubuntu backer's commitment to cleanroom usability testing, yay! - echoes this issue and maybe explains it more succinctly:  http://tech.slashdot.org/comments.pl?sid=1381337&cid=29535709

Fair-use quote:

8< - - - -
Re: STFU needs to be heard. (Score:5, Insightful)
by jc42 (318812) on Thursday September 24, @09:12PM (#29535709) Homepage Journal

> I always get asked, "How did you get good with computers?" To which I reply, "I was just able to read."

So soon you'll have no choice but to ask around to find out how to do something. If you do this via email or IM, your message will be hidden from others, so they won't be able to read the results.

Lessee; do I need a ;-) here?
8< - - - -

Back to me, restating my thoughts:

Big difference (in my mind) between a publicly-editable "KB" and Questions/Forums:

Big difference(s) between my idea of a "KB" and a Wiki:

* More metadata, encouragement or requirement for "applies-to-version"/"applies-to-package" tags means better searchability and truthiness;

* Single-sign-on through Launchpad, so everyone subscribed to whine about bugs can also document workarounds, best-practices, improve on others' documentation, etc (erm.. separate wish, but in the meantime, maybe Launchpad should offer OpenID and the Ubuntu Wikis and Forums should accept it?  Unless it already does now, been a while since I checked!)

* "Last approved version" vs. "Most recent version" per-topic is a more workable social approach to collaborative editing; avoids the "misincentives" to lock-down a Wiki; avoids the reversion-wars that can prevent an article from evolving healthily on one that does accept public edits.  (Same model as the "stable" / "development-branch" approaches to software development.  But people who can write good documentation are not necessarily people who enjoy using git for document-management.  KBs are the blog-engines/content-management-systems of collaborative technical documentation.)

It occurs to me that you could basically reuse/repurpose a bug tracker for this directly - just use status to track 'work-in-progress' / 'discussing' / 'approved' / 'obsolete'.  Only problem is that links would be fragile as old "articles" become 'obsolete' and an editor could only tack comments onto an 'approved' article (creating an 'approved' thread) instead of fully editing it.  But 'approved' threads containing only *useful* information would still make it faster to find solutions / learn best-practices. :)