KGSWishlist/ Discussion1

Sub-page of KGSWishlist

Table of contents

[100]

Motivation

blubb: 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:

  • FAQ
  • File Handling
  • Fischer Discussion
  • Game Handling
  • General UI
  • Social
  • Social Section
  • Technical
  • Web
  • Discussion
  • Hotkeys
  • Minimizing Rank Drift
  • Rated Games of Any Size
  • Unsorted

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.

blubb: 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:

  • Deprecate pages for chapters, such as / Game Handling. The only content they offer beyond their sections is the short outline, which should be only kept in the main page. (Duplication of information only leads to inconsistencies.)
  • Prepend the page names with a clear identifier. Prepending has the advantage that pages will be together in the search display.
  • Restricting the content of the wishlist pages to actual wishes promises huge readability improvment. Of course, proper linking to the corresponding discussions becomes very important, then.
  • Leave only the wish itself in the section page - just enough for other readers (who may want to enter a similar wish) to recognize it. Move all discussions, implementation proposals and clarifications into either the corresponding section/discussion page, or if consisting of more than a few paragraphs, in a destinct discussion page for the particular wish.

blubb: 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

  • KGSWishlist... main pages to be "structure" pages (including sections, being the actual lists of wishes) only, and
  • to have the wishes discussed - as long as they don't become issues - at subpages only.

(See /discussion2, please.)

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

  • (Sebastian:) I think you're right, normal pages are better. Benefit of subpages is that they can be kept in a TOC+ macro. Benefit of a normal page is that we can have a discussion page and assign individual properties to the page.
    • blubb: So we agree about level 1 and 2? These parts look well separatable from level 3 (and the wish vs. issue question), which some uncertainties are left about. What do you think about doing that change independently in advance? It might ease thinking further a little. Or do you have any concerns?
    • (Sebastian:) We agree. No concerns that would keep us from implementing it.

[300]

  • Arno: is it just me, but I'd rather those pages were sub-pages. And the thought of having a discussion page for each cluttering RecentChanges does not thrill me. Essentially these pages are discussions themselves. Where is the need for discussing a discussion? After all you can split the page in a top (structured) part and bottom (unstructered utterings with footnotes) part.
    • dnerra It's not just you. I would rather see them as subpages, too.
    • blubb: Please, for a reasoning why it seems necessary to (at least) Sebastian and me to switch the wishlist from a discussion- to a pure lists of wishes style and to have all the talkative stuff at other places, see the first chapter. What do you think of it? - Also, it would be interesting to get some feedback from wms as the actual addressee of that whole wishlist mess.
    • blubb: About the recent changes affection - sure, the number of pages increases by that, but the frequency of edits? Currently, quite a few wishes get filed again and again (and removed occasionally, too), just because it's so onerous to see if something is already there.



Should we distinguish between page names for wishes and wishlists?

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

  • The reason why we're proposing this change is that we desperately need to make it easier for users to find where their wish belongs, and if it has already been written. A clear distinction makes it clear which pages people will look at. Iff it's a wishlist, it is part of the outline on the main page - it should be as simple as that.
  • Wishlists have a different format, as you described in 2. above. Keeping their names different will help enforce that distinction.
(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.)
  • [3059] It will be easier to maintain. We can e.g. search for all pages containing "KGS Wishlist" and check if the outline on the main page is consistent with the existing pages.[3059]
    • blubb: I take your point as "better not to use an identical prefix for both wish topic discussion and wishlist structure (main entry page, sections) pages, since a section is something very different from a wish". But how does this affect the structure we need? It doesn't seem any more difficult to maintain the wishlist if it's structure is consistently given by all main pages, while the topics are discussed in subpages. We can simply search for all main pages containing "KGS Wishlist" in order to check the entry page outline. I admit, it would be nicer if we could make every subpage yellow-looking like discussion ones. That's somewhat flawy, but I don't quite think anyone will start a discussion at a wishlist section or even set up a wishlist inside a section/wish51discussion or section/discussion page, once the structure is established. See [0202]
    • (Sebastian:) I now agree with you that maintenance should not be an issue. However, I still think that it is very likely that people will continue to write their opinions into the wishlist proper, if we don't teach them otherwise. It will at least help a little bit to tell them: "Please don't write discussions into "KGS Wishlist" pages". - let's continue this on /discussion2.
  • We need a category for KGS Issues anyway - an issue does not have to be a wish (e.g.: KGS Issue - Firewall), however, it might easily result in a wish or two.



Should smaller issues be on a page of their own?

  • blubb: I think, pages like KGS Issues - issue48 could be used exeptionnally for particularly stubborn lengthening discussions, but I'd rather see them among "KGS Wishlist - " actually (if they need to be a main page at all). KGS Issues might better suit already repudiated topics than ongoing discussions about "active" wishes.
    • (Sebastian:) Why? I only see benefits if they are pages of their own, and I don't see why we should impose any restraint there. Take e.g. KGS Issue - Kogo's Joseki Dictionary. This is a nice, self contained page. Most people who read it will probably appreciate that it is not buried amidst tons of other issues.
    • The main advantage is that this would give us a unique identifier for issues, which would be safe from restructuring of the wishlist. (The current way of doing this by bookmarks isn't safe. We already lost most of our bookmarks when we divided KGSWishlist into subpages.)
    • ;:blubb: The advanced search gives us a rather good way to globally search the KGSWishlist. I think mixing up the page names, as to call "wish" topics "issues", wouldn't improve but incumber convenience. [0202] A global search provides a valuable alternative to the handmade list structure - not only for wishers but also for list maintainers. I think we should try to make is as efficient as possible, as well, and not rely on the guide page only. Who seeks something in the wishlist and nowhere else, should be able to find the matches and nothing else. By (un)checking "including subpages" one could easily either search the entire KGSWishlist content, including discussions, or the actual lists of wishes only.
([Sebastian:]): Agree that we should make search as effective as possible. But I think it already is. (Discussion continued on /discussion2)
  • blubb: I don't see why to concentrate on _issues_ when restructuring the _wish_list. They're just different things, even though not quite distinct.
  • (Sebastian:) Actually, When I first introduced the term "issue" I meant it not as something else, but as a generic term covering wishes as well as what we now have come to call "issues". I would be very happy if we had another term that combines both.
  • blubb: The same applies to wishes vs. bugs.
  • (Sebastian:) You can make that distinction, and wms chose to do so. I know software companies who keep them in the same database and treat them the same way. (As one developer once said in the group status meeting: "Ich habe letzte woche wünsche und bugs eingebaut".)



Guide Wording

blubb: 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.

blubb: 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.

blubb: Right, the same think I.


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