KGSWishlist/ Discussion1

Sub-page of KGSWishlist

Table of contents

[100]

Motivation

rubilia: Am I the only one feeling that KGS Wishlist is getting out of hand, despite of the structure introduced about eight months ago? It seems too hard to find already filed requests, compared to how easily just another one is added. I doubt wms can really overlook it anymore.

(Sebastian:) I agree! And this is not just a question of if wms can overlook it - each time a normal user can't overlook it, we are likely to miss out on a good suggestion - or, worse, the list may even grow by an ill-informed contribution out of context.

A year ago the whole wishlist fit on one page and was about as long as today's /GeneralUI alone. It had some headlines, but even with them it was, as one deshi put it, "unreadable". (This was remedied by the big cleanup, starting with TJ introducing topical headlines on Oct 16, 2003.) By contrast, /GeneralUI contains no headlines at all - it is even less than unreadable! Each subpage needs to be structured into sections that should typically fit onto a screen. Unfortunately, I don't have a lot of spare time to contribute significantly this time.

Currently, we have the following subpages:

Some of these represent whole chapters with several subchapters that users should browse before entering a new wish, and some represent single wishes that have been moved out of their chapter because their discussion has become too long.

rubilia: For now, I can see mainly five distinct levels the KGSWishlist consists of:

  1. the main entry page, KGSWishlist
  2. the chapter pages, currently kept as subpages of KGSWishlist
  3. the sections, currently being mere sections of chapter pages
  4. the particular wishes, currently embedded into
  5. various subsequent wish topic discussions.

I agree that we probably don't need pages for both 2. and 3.. Since the main page can bear to list chapters and sections as well, whilst the content of sections contributes most to the inflation, I also think we better make sections pages than chapters.

Doing so, there're still four levels left to deal with. Unfortunately, we can't create sub-...-sub-pages at SL. Maybe we should "outlink" one level: either at top, making the section pages main pages, or at bottom, spreading the wish discussions over several discussion pages, or even both?



[200]

Attempts

(Sebastian:) I think, a good way to exploit what SL offers would be:

rubilia: Here's my sketch of what the structure could be changed to:

1. KGS Wishlist

The main page. Its most important function would be being a guide. It should list and shortly describe all chapters and sections, and introduce to the use of the wishlist.

2. KGS Wishlist - section title

The section pages. They'd be the real wishlists. Maybe on top of every section page a few lines should explicitly appeal to add nothing but wishes, preferrably concisely worded. No comments, no "me too"s, no further discussion. If groups of related wishes appear, create TOC and headlines appropriatly.

3. KGS Wishlist - section title/discussion
. . KGS Wishlist - (section title)/wish37discussion

The discussion pages: one general one per section, and separate suppages (of section pages) for longer discussing one particular wish each.

I think of a wishlist as a feedback interface, with the information flow clearly directed FROM the users TO the developer(s). For the sake of efficiency, it should not get overloaded with other stuff, like issue workarounds, ongoing discussions about already clearly rejected or otherwise illusive requests, user-to-user help or whatever.

I wouldn't mind seeing something like
"The reason why I don't like A, is ... " -
"Hm, but by A, X gets very easy, that's why I'd prefer it to B."
...
...
in a discussion page to a particular wishlist section, since that is discussing about the content of the actual wishlist, which belongs to it like MiaiValuesList/Discussion belongs to MiaiValuesList or Basic Endgame Theory/ Discussion to Basic Endgame Theory. For instance, adding contradicting wishes to a list hardly improves it's use, so people should be given the chance (at least) to achive some degree of consent outside the actual list.
However, as soon as a topic gets longer than appropriate to such a general section discussion page, it should be moved to either a distinct subpage of that section (which is my preference - sorry, I don't get the benefits of moving out you talk about) or an own main page.

To sum it up, I'd like

(See /discussion2, please.)

Should wishlists (formerly called "sections") be subpages or normal pages?

[300]



Should we distinguish between page names for wishes and wishlists?

(Sebastian:) I see the following benefits for distinguishing them:

(While it is sometimes not obvious to distinguish a big wish from a disorderly wishlist (example: KGS Issue - Escapers), I think there is much to be gained if we maintain that distinction. I would like to model our understanding of "wish" along the lines of the [ext] IEEE definition of "requirement": "(1) A condition or capability needed by a user to solve a problem or achieve an objective." If we can agree to subsume the whole escaper problematic under the one condition/capability/objective: "Minimize the impact of escapers in a fair way." then this would be one wish.)



Should smaller issues be on a page of their own?

([Sebastian:]): Agree that we should make search as effective as possible. But I think it already is. (Discussion continued on /discussion2)



Guide Wording

rubilia: Beside of the restructuring discussed above, the introduction supposedly should enable a better balance between encouraging to contribute and emphasizing the necessity of counterchecks:

What about

  1. "Check thoroughly if the feature isn't already there. If you miss something rather obviously needed, better ask people at KGS first instead of adding a wish here."


and

  1. "See KGSPlans for what wms plans to add in the future. Adding a wish to KGSWishlist won't help anything if it's already about to get realized.", for example?

(Sebastian:) The first text is great - I'll put it into the main page.

[22] The second text, however makes me aware that we have a similar issue as with the /FAQ page: We should not put the onus on every user to search through yet another list - it's simply not going to happen, that's just the way people are, and we can't force them. We have two realistic options: Either wms agrees to make a comment in the Wishlist when he decides to grant a wish (and delete it iff he implemented it) or some dedicated deshis look for wms's changes in KGS Status and do that work.

I'll put that sentence there for the moment, because it is better than the existing sentence, but I hope we can remove it soon.

rubilia: Man, you're fast! I didn't intend those sentences to get into use right away, but just to start discussing some ideas, actually. :) Anyway, it supposedly hasn't got worse, no need to worry.

Beside of being too one-sidedly encouraging (most of which has been fixed now), the whole introduction mainly looks too talkative to me. I don't think an average KGS wishlist user is aware of what is written there.

(Sebastian:) Agree, some of it could be more terse. But in general, I think it's not so hard to read, because people can easily skip to the headline that suits them. And the information should be written somewhere. Except, of course, if we discontinue using the referred pages, or sort them into our structure. In addition to, as discused above[22], getting rid of the need to link to current and future plans, we could also give up pointing people explicitly to KGSFirstTimeUserExperience - in almost a year we had not a single first user write something there. This could become just another "KGS Issues" page and be linked from the wishlists it touches.

rubilia: Right, the same think I.


This is a copy of the living page "KGSWishlist/ Discussion1" at Sensei's Library.
(OC) 2004 the Authors, published under the OpenContent License V1.0.
[Welcome to Sensei's Library!]
StartingPoints
ReferenceSection
About