Go server admin behaviour?
It seems that Go server admins sometimes show quite some authoritarian behaviours...
This page intends to collect such behaviour, with the intention to convince such admins to reconsider their behaviour.
It looks like this can become a controversial page: but the information is freely available and can be found by anyone looking for it; it is assumed that this is a current page, i.e. describing situations that have not been rectified since.
"Freedom of speech" seems to be a recurring phrase in such issues. Agreed, deliberately insulting and disturbing rooms just for the fun, or for any deeper motive, could be a motive for booting people. But how thin is the line between absolute power and summary execution?
A hypothesis is that admins get so ofter confronted to such an amount of "disturbing" human behaviour, that they will more and more easily ban people, maybe for the wrong reasons. Also, they will be confronted to human nature in manners that normally "real-life judges" have to face, and are prepared for. Admins might not.
Maybe booting power should never be given to individuals, but to a group of mature people, to ensure that no personal "character traits" affect boot decisions: http://en.wikipedia.org/wiki/Separation_of_powers
- no server should ever ban anyone for referring to any other server in a reasonable discussion. Not confirmed, to be checked.
- John Tromp being banned by tweet - but why exactly?
- see also KGS Worst Admin
- KGS Censorship
- KGS booting people...
- thread on RGG
- Karl Knechtel/FailureOfTheECR
- KGS Rooms / Policy Discussion
- What to do about Mr. Cat ?
- related to a ban decision that - IMO - is controversial. Also shows how posts are hidden based on unclear criteria.
- Intransparent moderation
GoAndEconomics made me think that there must exist other analogies to reach people right from within their speciality. This page could collect/link to such analogy pages.
Promising pages, found searching for "analogy" (not always relevant):
This page intends to group ideas to promote Go.
I usually try to start with the stone counting teaching method, especially with kids; however, I wonder if this really avoids issues around the atari go teaching method, where players might focus too much on capturing stones. I will almost invariably check if the newcomer has already played chess or checkers, for me an indication that this person must be capable of handling the Japanese counting method (the idea being that this person is able to get a grip on a more abstract concept).
- teaching - top level pages (they need restructuring)
KGS Teaching Protocol?
A typical problem on pre-audio KGS when teaching is that pupils tend to ask questions while the teacher is still (maybe painstakingly) typing something. Another problem is that a teacher might go forward in a game at such a speed, that a ppi cannot catch up, and must know of a way to interrupt an explanation and say which move (s)he would like to see (avoid "yes, that move - no, the previous one - yes..." etc) This page tries to propose a way of efficiently communicating via a Go server when no audio channel is available (it is likely that this page will become obsolete in the future...).
See also HusTeachingMethod
As far as I know, there is no formal description of how to review a game. Also, the SGF format has only limited support for reviewing.
- reviewers introduce themselve in the first node(s) (as well as in the reviewer properties); each comment should be preceded by the reviewer's nick/initials, enclosed in brackets. remember the SGF "reviewer" property as well. don't use the "I" form when referring to players/sides. Use Black, White instead.
- be aware of difference between child/sibling variation styles of SGF editors. See http://www.red-bean.com/sgf/user_guide/#variations
- SGF: hyperlinking references to board position: currently, several ways exist to refer to board positions from within comments: coordinates, markers, variation labels, node names. Often, variations are labelled automatically, referring to them risks breaking the link when variations are reshuffled/added/deleted. Using coordinates avoids this problem, but it is more hard to follow (well, I guess one gets used to coordinates after a while...). although 1-move depth variations could be used to show alternatives, upper case letters should be used instead; variations should only be used if effectively followed by moves. referring to variations is tricky because some SGF editors might represent variations with numbers, other with letters (and yet others with user-selectable aphanumerics). Maybe best is to refer to variations by their coordinates?
- Update: mark the variations with letters and refer to your marks, not the ones from your editor.
- Coordinates are fine when debriefing over the phone. Nowadays editors have plenty of marks to refer to the board; so, use coordinates only when absolutely necessary, because it takes some brain power to convert (anyway) to a board position. also, one can easily make a mistake in noting down a coordinate.
- to be thought over: how to review games with someone without a common language (or even common character set). Must be possible, if symbols have a well-defined meaning.
- at this time, reviewing (for me) means a first phase going over moves and listening to my feeling to see if a move is what I would have - or certainly not - played.
- in a second phase, how about trying to find the point of no return?, where one of the players should have given up, as there was no way to win any more from there.
- similarly, it might happen that there exist a last break-even point? (i.e. current situation is even), beyond which one side starts winning. Difficult to work with, a projected score will swing around violently all the time, so there might not really be an even point. But tracing back from a game's end, there is always a point where both players were even (for the last time) and after which the winner is known. Might not have much value if pro players continue to swing a few points around jigo until the very end (What is the value of knowing that the even point was two moves before the last one; but for lower kyu levels, I guess the situation where a player is winning long before the end of the game must be common). Could be an interesting concept to study.
- turn-based playing: have the pupil initiate the review with comments, this will make the teacher easier to select the appropriate level of review, adds extra stuff to discuss, motivates the pupil.
- tutor mode (a MultiGo feature where you can only advance when clicking on the right move) is nice when trying to understand teacher moves: the program won't let you play anywhere else than the recorded move.
- when White creates an SGF from a (memorized) game, she should rotate the board (if possible) so that the bottom left coordinate is T19 when starting to record moves. When Black will open the SGF, he will find the situation as he played it. Of course, Black could also rotate the board. But maybe not all editors are capable of doing this, so if White's can, everybody will be happy.
- make sure you are using Black's perspective when using geographical locations like up, down, left, right (as the board could be rotated by the reviewee). Coordinates or symbols avoid this problem.
- metric: how often does the initiative switch from one side to the other (hypothese: high count=violent game? could be measured as e.g. the sum of distances between a player's reply and the opponent's move)
- spare beginners from deep reviews and many recommendations: make a complete review, but present only the best two or three advices.
- beware of referring to move numbers: a server might number moves differently in its interface from what the SGF editor sees.
See also: Symbols
Reasons Against Playing Go?
This page lists some not-so-trivial reasons why some people do not want to play Go.
One of the reasons that made me create this page is seeing bright people reject the game for various - in my eyes sometimes stupid - reasons. And also to identify reasons what keeps people from trying the game, and maybe find ways around those "blockades".
I know at least someone who apparently does not want to continue playing Go because the rules are not as simple as one would initially try to make newcomers believe. As a result, Go is rejected as a game without clear rules.
I still make newcomers believe that it is a very simple game, even while being aware of all those different rulesets (and having a faint idea why there are several rulesets) that are a *disgrace* to Go.
When asked why they don't want to play the game, various people already replied that it would absorb them too much, so they prefer not to start at all: they know themselve, they say, they know that if they dive into the game, they will [have to] spend all their time in it, and that's not what they want to "suffer". As if owning a sports car is useless if one cannot drive it around [all the time] at high speed.
Someone I know doesn't want to play the game because it gives too much stress.
prejudice, preconceived ideas, afraid of the unknown...
- first learn a decent game such as chess and then the rest, etc.
and finally, some trivial reasons - just to complete the list. Some of these reasons are perfectly acceptable, some are the real reason for someone not liking the game, but instead a reason above might be forwarded instead.
- "Don't like it"
- not attracted
(please add your inputs!)
In various places on SL, wishlists keep popping up.
To the irritation of some deshis, who don't always see the value of such lists. True, such lists do not always have long-lasting value. Let's take DGSWishlist as an example. In the end, what one wants, is to have concepts implemented. Now, if different Go servers would have to implement a similar wish, one would find a duplication of wishes for each instance of a Go server littered throughout SL.
So wouldn't it be better to centralise wishes, make sure they are generic, and let designers implement concrete wishes on their server? A problem is that some servers have features that are not present on other servers, therefore those wishes would not always be relevant. A well structured generic wish list should contain all wishes from every possible server; a server-specific wish should be converted into a new wish, and then add the wish that was missing in the generic description.
Pages could exist for e.g. servers, clients, editors, analysis software, (Go playing) programs, etc.... This approach would be far more interesting and last longer, as a generic X would maybe never get implemented, but the richness of features would give loads of ideas for (new, emerging or existing) developers.
BTW - this idea might be totally unfeasible, that's why I put it here...
(Not yet sure if this is worth adding to the related pages, so I put it here first. If anyone feels like there is any potential in an idea, feel free to move it to the Variants page.)
- This game on DGS brought me to another idea: the first to make a living group loses the game. Probably for small boards only.
- intersections receive a weight that is taken into account when counting. a question could be whether this weight should also be transferred to prisoners taken from those intersections, or maybe a parallel grid should exist for prisoner weight.
- extension of the toroidal board idea: tile an (NxM) goban to produce a toroidal playing space. Then, introduce a "shear" by sliding two adjacent tiles X points along a common edge in one direction. The resulting tiling gets a sheared appearance. Now apply a second shear operation of Y points along the other edge (i.e. in the other dimension): a XxY sized "gap" will appear and serves as a secondary goban.
- when playing on-line on mobius/toroidal boards, the board would re-centre every time on the played move, requiring the player to adapt to the shifted board situation all the time: especially difficult in blitz games.
- a radical variant (using a server) would be to have both players play simultaneous moves instead of in turn; each conflict would be resolved by bidding prisoners, the winner (who invested most prisoners) occupying the conflict intersection, the loser receiving a compensation in the form of prisoners:
- each player secretly selects a number of prisoners, or
- each player bets an increasing number of prisoners; then,
- prisoners are exchanged, or
- loser receives the difference in prisoners from the winner
- see also BidGo
- IGS tried vote games
Based on http://www.msoworld.com/mindzine/news/orient/go/special/gostone.html
- on a key chain
- physics experiment: in vacuum, a Go stone will drop as fast as a feather
- attach to the next interstellar bound space probe, as a message from Earth to the aliens
This page lists (my - feel free to add more, but expect my veto as long as it is under my home page) ideas that might be implemented on SL. The advantage of this page is that pruning of e.g. GuineaPigsFeedback will not get rid of possibly interesting ideas.
- extend the footnote concept to true HTML bookmarks (URL#bookmark) to provide the possibility to point into a particular spot in a page
- The way to specify headings seems wrong: ! should be 1st level, !! second, etc... Maybe each page should be inspected on the deepest level present before deciding what heading to associate with !, !!, etc... Actually the current behaviour encourages bottom-up page creation (collect subheadings into larger headings while plodding along), but not top-down (add subheadings to existing text). Maybe a kind of macro could be created to expand to reorder existing headings: when using e.g. -!!, this means that all other headings need to be bumped up one notch, and the current paragraph must become level 2. (to be reviewed, explanation not clear to me, though the concept is)
- possibility to search in page histories/deltas (as long as this is still available), not only in current pages
- possibility to link to headings (without risking to lose a link if headings are moved around a page)
- A Favorites/Bookmarks folder, similar to the watched pages concept. My watched pages list is too big to use on a daily basis. The next step that could be expected is to be able to structure the Favorites...
This page would serve for discussing and collecting tools and concepts to be used during analysis as well as during play and to discuss ethics, future and possibilities of this extension to the human mind (Go playing using assistance software, not to replace human decision making - the borderline is very fuzzy, yes).
Although technically already feasible (and in some extent already in use), I think in the future a separate type of online playing might exist, where consenting players are assisted by software while playing.
My approach might tell more about my lack of Go knowledge (or a naive view of things) rather than introduce new ideas: do I underestimate the possibilities of such software, will it never really be useful? Maybe I will change my mind as I dig deeper into Go, only to find how foolish I was to reflect on this matter? Comments about this are welcome as well.
Some question to debate over:
- is this (ethically) permitted?
- What will be impact on the game of Go?
- Does it make sense to advocate against computer assistance during play?
- The borderline with true Go-playing software, where the move decision is taken by software, is very thin here; how do we subdivide this domain into "acceptable" tools and "not acceptable" (in this context, as the use of any tool is already unacceptable in the "classic" sense); what tools are available?
- can advances in technology (processing speed, memory...) make this cyberGo unacceptable (i.e. it should never be acceptable that of two people playing cyberGo, the one with the better machine would have the edge - maybe a weak argument...)
Some notes: (sorry for the mess)
- manual features (Player decides on values)
- persistent concepts (are not linked to a move, cannot be stored in current SGF versions):
- persistent concepts are stored in their layers that can be switched on/off
- symbols can be added and deleted
- (visual representation of) status of groups; alive-dead-weak-strong groups
- confirmed territory - points (help counting during the game) - neutral - undecided
- allow to classify potential playing points with a prio and/or value; drag the label to another classified point to reshuffle priorities; supported by special variant to variations concept aimed at evaluating the value of a point (what if Black plays first/what if White playes first => resulting value)
- automatic replies
- manually built game tree to explore variations
- automatic features (mainly counting stuff)
- automatic ladder detection, life & death of groups? - probably not acceptable
- present groups with 1-2-N liberties left -> ko threats, atari, double atari threats; Benson's Algorithm
- strength and liberties of friend/foe contact groups, in relation with own group status
- influence function - see also voronoi?
- Adjusted Length Analysis
- ModularThinking support
- evaluation areas can be automatically created by taking the smallest involved area over all subbranches? counting (evaluation) is possible inside such an area: all groups inside it are assumed to be alive unless marked dead by the player.
- databases, dictionnaries of any kind are not acceptable?
- window tracking: the cyberGo application monitors and mirrors the current user board (presented in another application window). the idea is to be able to use this app together with any Go client.
(features that should be present in a Go editor)/list of all possible features...
- variations, SGF merge of different reviews of the same game
- ko indication (MultiGo hasn't)
- playback features
- highlight a square (as in Kombilo), show move history only inside/near that square
- possibility to switch between SGF sibling style and children style
- playback in constant interval or using the stored time
- highlight an area of interest for investigation in variations, be able to count the result in that area. The area is typically created at the root of a set of variations, and allows to compare the results of those variations in the leaf nodes
- all stones are alive except when encircled and no life?
- the border of the area is equal to the border of the board).
- anywhere in a tree, the user can assign a value ( http://www.red-bean.com/sgf/properties.html#V) to a node. Variations that have a value downstream can then easily be compared, sorted and presented in the SGF editor.
- maybe the area could be calculated automatically given the root node of a set of variations: if all variations explore a local fight, the software is capable to identify the area that is involved over all variations. the software could show the result area with the stones that participated in the process (all variations overlaid on top of each other), and the user can flag if necessary those stones that should not be part of the area, after which the software recomputes the area.
- highlight/dim,territory, live/dead/dependent groups
- SGF 3-way merger and diff tool (to highlight comments added by contributors)
- GMP net module - use your favorite editor against GnuGo, or againt anyone across the net.
- switch colors (to play Pyjama Go)
- provision for Stone Counting Teaching Method (for absolute beginners)
The noisy net?
Internet tools and technologies make it increasingly possibly to launch new and seemingly sexy and attractive sites. Kids could launch bulletin boards, even entire sites such as Facebook etc. We see more and more Go servers pop up, often with features similar to those found in existing sites.
While this is interesting, there are some major risks.
- several similar servers compete for users; good servers experience difficulties because of losing users to those new servers.
- developer effort is duplicated
- owners have no backup plans; as a result, when the site disappears, all efforts and information stored by users go down.
- owners have no plans to cope with problems: eg sites are launched on free servers, and be abandoned soon afterwards (or also because it was a test only).
- a relentless pressure from users asking yet new features, making code more brittle if not well designed
- weak developers will leave security holes more open to hackers
Possible solutions to the issue
Of course one cannot interdict creating new content on the web.
In daily life, one typically also has access to various competing stuff (newspapers, TV channels, shops, ...). I guess communism is a state where such things are regulated.
Also, web sites will not last forever; clinging to a dying site makes no sense.
- site creators could log an entry on this page, explaining what went wrong so that future generations can learn from it.
- Site designers (typically L19) could try to make sure that their content can be exported to a simple format, so that new sites can integrate the information.
- Sites should attempt to create new content, rather than try to replace existing sites.
- Developers should try to avoid working alone on a site. Obviously this doesn't count for a site that seems to contain brilliant ideas (but I guess many owners initially think they have a brilliant idea...) Open source software ought to reduce the likelihood to lose a project forever - at least someone else can pick it up.
- How about not trying to make everything look integrated: for example, on SL, use a phpBB forum site for discussions and SL pages for knowledge... Think of Unix philosophy: use small, specialised and efficient tools that complement each other, rather than one tool (eg Emacs) that does everything and might become a maintenance nightmare. On the other hand, 3rd party tools can lead to security holes (see goproblems.com / 2008 December 27 Hacking Incident).
- When a site is listed on SL, the page should also contain links to related pages
The ease to create SL pages is just another example of how easy it is to create noise (yes, I am guilty too)