KGSWishlist/OldDiscussion

Table of contents Discussion before 13 October, 2004 Motivation Attempts Should wishlists (formerly called "sections") be subpages or normal pages? Should we distinguish between page names for wishes and wishlists? Should smaller issues be on a page of their own? Guide Wording Discussion from 13 October, 2004 Should we distinguish between wishes and issues? Should we have a common element (prefix) in the name of wishlists and of wish_or_isues? Options for handling discussion of individual wish_or_isues Discussion from November 2004 Do we need to rework the KGS Wishlist? Go back Betting

Discussion before 13 October, 2004

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?

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

Discussion from 13 October, 2004

This page discusses how we should change KGSWishlist.

I'm starting a new page because the old one? has become so filled up with obsolete material and replies that are out of context that it's hard to keep the overview. This page only lists the open issues. I try to keep it out of the "I said - you said" paradigm by keeping all information in pro and contra lists. It doesn't really matter who wrote which argument.

We agree that

• we should distinguish wishlists from wishes;
• wishlists should be separate (main) pages;
• we should encourage putting smaller issues on their own page, since it provides the benefit of not relying on footnotes at the cost of no major problem;

The following questions remain open:

Should we distinguish between wishes and issues?

Pro:

• There are some issues that are no wishes (e.g. KGS Issue - Client Memory Consumption).
• There are some wishes that are no issues.

Contra:

• Most issues ("KGS Issue - *" pages) can be interpreted as a wish. Some people may say: "Asian fonts are an issue that requires a non-trivial workaround", while others may say: "We wish Asian fonts could be displayed without a workaround.". This is just a difference of personal style, which is irrelevant for our purposes.
• Many wishes in the wishlist are written because a user experiences an issue. A wish to "make it easier to resume games" can be stated as the issue: "there are some hurdles to resuming games".
• Wishes can inconspicuously become issues, e.g. if the wish "The result should be displayed in the table" is replied by "just widen your window, there it is". We can't expect people to rename a page in such cases. (Or to move the wish from the wishlist to an "Issue List".)
• It is easier for users - they need to worry about one less distinction.

Much of our differences are rooted in this disagreement. Maybe we should clarify this first before continuing with the rest. In the rest of the page I preliminarily use the term "wish_or_isue" where appropriate.

Should we have a common element (prefix) in the name of wishlists and of wish_or_isues?

This depends on the decision for the previous question.

Pro:

• It will be possible to search for

           title like "KGS Wish*" AND text like "*MyWishOrIssue*"

Contra:

• It is actually not necessary to be so exact in our search. It is enough to search for

           title like "KGS*" AND text like "*MyWishOrIssue*"

Such a search will typically not yield more than a couple pages, since there are less than 100 pages containing "KGS" in the title to begin with. Conversely, a more exact search is more likely to overlook relevant pages. The search couln't be any more effective than it already is!

• 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. Keeping their names different will help enforce that distinction.

Options for handling discussion of individual wish_or_isues

We agree that we don't want wish_or_isues to be discussed on the wishlist itself to keep that list clean. That leaves the following options:

Discuss them on the wishlist/discussion page

Pro:

• Fewer pages

Contra:

• Many individual discussions on one page => confusion.
• the connection between a wish in the wishlist and its discussion has to be kept by a footnote, which is not secure when pages get refactored.

Discuss them on a wishlist/specificwish##discussion page

Pro:

• There is a clear connection between a wish_or_isue and the list. This is good in those cases where this connection is unquestionable.

Contra:

• presupposes a clear subordination of a wish_or_isue to what we define as wishlist name. There may easily be discussions that relate to more than one wish, and the wishes may fall into different wishlists. In such a case, we would have to split the discussion by force.
• not possible to define keywords
• not possible to reroute page (alias)
• name gets more complex
• discussion not available with "discuss" button

Discuss them on the wish_or_issue page

Pro:

• easy

Contra:

• not so nice when factual information is mixed with discussion

Discuss them on the wish_or_issue/discussion page

Pro:

• clear distinction between factual information is mixed with discussion

Contra:

• adds another level of complication

IMO the appropriate would be to discuss them on the wish_or_issue page.

I had been concerned with the same work as you, for nearly one hour, when the display finally said "Attention: someone else might just be editing this page!". AarrgghH. I'll answer yours later. (Pretty good job, though!)

(Sebastian:) I'm sorry. On this page? I let the "seconds until edit warning for other users disappears" run down to 0 several times, but I never got any warning that someone else was working on it. This also happened on the /Discussion1? page, but i didn't change so much there except for some direct replies. If it was that page pls feel free to replace my version with yours. blubb: No, it was this one. ~__~ Perhaps the fact that the page didn't exist yet might have been the reason that no warning was shown to any of us? I don't know. Anyway, I got over it - not at least because this page looks fine now, nevertheless. :)

Anonymous: Keep the menu at the head of the Wishlist page. Some categories are too verbose and need to be broken up into smaller topics. One topic --- KGS server-wide go ladder --- needs to be added as a separate topic on the menu.

Discussion from November 2004

Do we need to rework the KGS Wishlist?

(Sebastian:) A month ago, blubb and I started a discussion? about what to do about the status of KGS Wishlist, which we feel is unmanageable. The fact that we get more misplaced and double postings than new wishes indicates that the list is too unwieldy for most deshis.

We worked out a concept to improve the situation (see attempts? and refinement). Since nobody objected within a reasonable comment time we started implementing the concept, and completed the first two steps (WME of KGSWishlist page and standardizing of "KGS Issues pages"). The increased proportion of KGS pages in RecentChanges, however, raised some eyebrows. When blubb started with the third step of standardizing the wishlist according to plan, Arno stepped in. His reply? (as well as the long discussion on KGS forum at SL discussion, which we found later) indicates that many people would rather reduce KGS related traffic on SL. By contrast, we believe that the amount of traffic reflects the need KGS users have. We regard it as a given and do not want to reduce it other than by reducing the need for it. Of course we respect Arno and do not want to work against his interest; we are well aware that KGS should not overstay its welcome.

Hence the question: What do our fellow deshis think?^[1] Should we

• just let the wishlist be and don't worry about the weeds or
• is it worth the effort, noise and increased traffic to render it manageable?

The point of this discussion is not to build a rift between KGS users and non-users on SL. The point is to obtain a clear decision for a situation which has become unsatisfactory for KGS users and non-users alike.

(Sebastian, 3 weeks later:) Nobody replied, so it seems nobody cares about this. In the meantime, a few people have added some new wishes, and unfortunately, since the pages are duplicated, some wrote their wishes in the old pages and some in the new pages. To avoid further confusion, we should get rid of the duplicate pages quickly.

If nobody protests I will simply request deletion of the new pages. I went through each page and copied the additions to the old pages. However, I can not guarantee that I did not forget a change. Therefore:

To those who added comments, wishes or votes to the new pages (the ones that are not subpages of KGS Wishlist): Please check if your change is correctly included in the corresponding old pages (the subpages of KGS Wishlist) so we can delete the new pages. If you're not sure if you changed the new page, check the page history of the new page.

(Sebastian, another week later:) Still nobody replied ==> discussion closed - files will be deleted.

[1] Maybe people could just vote by appending their pluses to the bullet points.

Dieter: I didn't reply because my user preferences strip recent changes from any page starting with KGS... And if I'm not logged on as Dieter, I simply disregard them anyway. However, the recent chunk of changes caught my interest. I tend to overreact when there's a sudden impact on SL. Time often proves that patience is stronger than anger - something a Go player should know.

(Sebastian:) Sorry, I don't understand what you mean. You don't think that my changes were motivated by anger, do you? That would be a misunderstanding. The versioning conflict needed to be fixed a.s.a.p. In three weeks, we already got so many changes that it took 2 hours to merge them.

Which of the two sets of files we want to keep is a different question. I should have mentioned that blubb and I discussed this off line and we concluded that the higher effort of completing the change (including manually changing all links from other pages to the files she created) would create more traffic and counter Arno's wish to keep KGS wishlist pages as subpages of KGS Wishlist and to keep KGS traffic low profile. However, I would be happy if we agreed that we want to keep blubb's pages and someone volunteered to change the links. Then, replacing the content of blubb's pages with the appropriate section from the pages I updated will be a minor task.

Dieter: No no, my anger. I should learn to be patient. Neve mind. Keep up the good job.

Moved from KGSPlans/Discussion:

%%TOC%%

Go back

anon: I miss the go back in demo games feature a lot, because as a weaker player you sometimes forget the last moves. So it's convenient to check the move sequence that lead to the current situation. I miss it even more if the 'teacher' (the guy having control) says something like 'this ko was set up 3 moves ago'.
So if possible, I vote for re-enabling this feature.

Hu: I would like to see it too. And disabling chat while "gone back" seems reasonable too.

Here is a related wish that may be suitable for transferring to the wishlist but is hardly even halfbaked: When teaching or reviewing, often the student or observers want to make a remark and have it attached to a particular move such as the last one paused at. However, the teacher often moves the focus before or just as the Enter key is pressed, so that the remark ends up attached to some other move, possibly an inappropriate move. I've thought about asking students to type a period to get my attention to give them control or a number to indicate a move to jump to so they can type the remark, but it could be cumbersome.

So it occurs to me in context of the "go back" issue being discussed that perhaps the student could "go back", attach the comment to the appropriate move, and have a "pending remark" button appear on the teacher's board that when pressed goes back to the move and makes the comment appear. Perhaps a ghost marker could appear in the Editing tools whenever the student is out of sync with the teacher.

The whole student teacher interaction could make even more interactive than currently by using schema such as these proposed here. WMS, you have already suggested some improvements such as having questions and remarks be filtered by the teacher or a moderator. Others have proposed ideas like drawing lines or shading on the board, and though there are SGF issues with that, it might lead to some productive avenues for increasing the already high level of pedagogical usefulness of the client. Some out of the box thinking could generate some interesting ideas and then some could be adapted into CGoban2 with modest effort.

The CGoban2 client can be used for real-time interaction but it can also be used offline as an editor to build a carefully crafted and commented tree for presentation back online. (I'm still hoping for Directed Acyclic Graphs!) It would be great to be able to edit and craft such SGF files interactively and cooperatively online.

One of the things about KGS that gives me the greatest pleasure is the wonderful interactivity of the teaching / review / demo capability, and I would be thrilled to see that developed to an even higher degree. -- Hu

Betting

axd: I think that Go should not be mixed in any way with betting related activities. (Makes me think of some Poker players, that won't play Poker if there is no real money involved.) I think the game is already rich enough, players should concentrate on strategy and tactics, not probabilities. That's for saloons.

(Sebastian:) When I read your comment, my first impression was that you generally oppose contemplating probability in Go. But I now see your point. “Play money” sounds a bit tacky. Bringing real money into the game (or even requiring it, as in your example!) would indeed smack of a saloon. But I think that the difference between play money and real money is clear (just imagine paying with play money in a saloon!), and I don't see any moral issue about betting per se. Money has given betting a bad reputation; maybe he could call it something else than “play money”.

Another possible confusion is that wms wrote “let players bet”. I’m not sure which of the following he meant:

• Players can bet on their own game (like the doubling in backgammon). This could help encourage people to resign games in which they have no chance of winning and reward winners of games in which the upper hand changed often. But I doubt that’s what he meant.

axd: people that do not have the courage to resign have to learn more about the game (such as when to resign), rather than place bets

• Players can bet like in Take a bet on life and death. This would be a good option for studying go.

axd: I wonder if "studying" is still appropriate in this gambling (as I call it) context. I would think that the idea is (try) to master (read: understand) the game, not to win a maximum of points. And what about bluff? All these elements stain the game. There is already enough thrill in the game.

• Kibitzes can bet. In that case, players wouldn’t have to be bothered by it. In fact, they should not even know when and what kibitzes bet on their moves. Games should still remain pure for the players.

Or do you oppose it because you have other wishes you'd rather see implemented? So do I. But if wms loves implementing it, it will be fun to give it a try. It certainly has potential.

axd: I personally have my doubts about the moral issues around betting (in whatever form). But indeed, there are also far more essential issues to deal with rather than introduce gambling as a game variant. Maybe wms might better first describe it in the variants pages. I bet there are more interesting Go variants to implement than this one...

Warp: I think that at least a feature where you can guess the next move (as has been proposed elsewhere) would be cool, even if it's not a betting system where you can win or lose something. Currently kibitz windows are sometimes flooded with people guessing the next move, and it would be nice if they could do that on the board instead of in the kibitz window (that is, people who have enabled the viewing of people's guesses would see numbers on the intersections of the board, ie how many people have guessed that intersection in particular; intersections with no guesses should not have any number, of course).

• DrStraw problem with this is that it would deny a lot of people the ego boost from visibly claiming that they guessed what move a 6d was going to make.

Peterius: Environmental Go is a sort of form of Go betting that could be added to KGS if the mood struck. At the beginning of the game there are these numbered tickets, one for each number I guess. At each turn, a player may choose to take a ticket for that ticket's amount of points instead of playing. So the point is that it helps one to develop efficiency. There are only so many tickets so one has to constantly determine what a move might be worth or whether they should just take a ticket. Personally, I'm a classical kind of person and like just plain Go, but its an interesting variant nonetheless.

Harleqin: wms is very reluctant in other fields to add any more complexity to the system. I find it very surprising that apparently there are no such considerations hindering this (imho) useless addon.

Tamsin: At the risk of sounding like I just don't know when to give in: wouldn't it be more popular (and no more difficult) to make Fischer time instead of adding a "play money" feature? Fischer time = a good idea that a lot of people want; play money = a dubious one that has not been cried for by many users.

wms, please don't be hard on me for saying the above, as I know that you're not keen on Fischer time and have said you're not going to do it, and we all respect that, but you've also shown that you're a reasonable guy who listens to the punters, so at least please allow us Fischer-time-afficionados to hope that maybe some time you'll change your mind. Thanks.

Also, a more personal point, it's already hard enough to find games at time limits that I enjoy, without having to find out that people are going to begin refusing games because I don't wish to bet on them. And doesn't the ranking system kind of already constitute a form of play money? If you win, you get more ratings points and the benefit of a higher rank and getting to play with more skilful players.

SirLyric: As much fun as playing BangNeki would be, with spectators betting on high-level games and all sorts of other stuff, intuition tells me that this sort of activity will only disrupt the spirit of KGS, and it feels like a poor idea to me.

SiouxDenim: It's interesting how people have read so many different interpretations into wms's mention of the doubling cube. My understanding was that the 'doubling cube' would increase the value of a won game in the rating system; the idea being that it would encourage you to count and to resign lost games. Suppose a doubling cube were used to double the weight of the game. Most people would baulk at playing on in a lost game if it was going to cost them, say, 64 normal losses. From the point of view of using a backgammon style doubling cube, a game is lost if you think you have <25% chance of winning, so several doubles might occur during the game as the balance shifts. (Of course some other multiplier than doubling might make more sense in Go. Doubling would have to be restricted for lowly players who have nothing to lose)