Plan for discussions

[Graham Percival]

Spent yesterday wandering around Kloten, the "old town" part of
Zurich, and looking at stain-glass windows.  Spent this morning
walking along Uetliberg, a series of hills right next to the city.
Travel advice: skip the city and culture, just go straight to the
Alps.  Ok, maybe Uetliberg isn't high enough to qualify as "alps",
but the basic idea is the same -- cities aren't worth the trouble;
the vertically-based wilderness is the place to be.

Anyway.


We need an avenue for structured discussions.  Technical questions
have a firm "right" or "wrong" -- a piece of code either leaks
memory or it doesn't; a slur either collides with a finger or it
doesn't.  That type of discussion needs no special handling; in
the very worst case, anybody involved can simply run the code and
see the same results on their own computer.  (or if the code runs
differently, then the discussion can/will usefully shift to
investigating the cross-platform problems)

But policy and "human-computer interaction" questions lack
objective answers.  How often should we have stable releases?  It
depends on how we view the software, what kind of assurances we
want to provide to users, what kind of reputation we want, etc.
Depending on what we choose, we may have more (or fewer) questions
on the mailing list, more (or fewer) new contributors, more (or
less) morale of the existing developers, etc.  There's no
obviously correct answer, and even if we agreed on all the factors
we should consider, every person involved would give different
weights to each factor.

Even worse, we don't have a firm plan on how to deal with these
questions.  My impression is that we don't mind postponing
something if there's a clear reason to do so, as long as there's
some assurance that it will be done -- and ideally, an exact date
at which it will happen.

So here's what I propose: in the summer we'll re-start the Grand
Organization Project discussions, and also start GLISS.


In June, we will begin GOP2 discussions with the same format as
last year: I will post an initial "discussion email" which opens
the topic, gives an overview of the options and their benefits and
costs, and possibly includes a tentative suggestion.  (this may be
written by somebody other than me, but I will still schedule the
discussions as well as check that a topic has enough info such
that we can have a reasonable discussion about it)

The discussion will last for one week to ideally reach consensus,
then I'll summarize the discussion and the current proposal.
There will then be a second week for "second thoughts" or
additional debate.  If everything has settled by the end of the
second week, we accept that proposal; if not, we'll either extend
the discussion or abandon/postpone the proposal.

There's some doubts about some of the policy decisions we made
last year, either because a topic didn't gather enough interest
and "slipped in", or because we have more information now than we
did last year.  For that reason, we'll revise everything.

First two questions:
0. we are a GNU project.  (not open to debate, just a
re-affirmation of fact, plus a longer examination+discussion of
exactly what that means)
1. release policy -- when should we have a stable release?


In July, we will begin GLISS, almost certainly in the same format
as GOP.  Initial Discussion questions will try to be as general as
possible -- for example, instead of arguing if we should have
\hideNotes vs. \notesHide, we will discuss the general question of
noun-verb vs. verb-noun command names (a third option would be to
decide to have no general policy on this issue and treat
everything on their own individual merits, but I hope we don't
take this decision because that leads to a ton of discussions).
Hopefully we can settle a good chunk of questions at once in that
manner.

My supervisor for my Masters degree often noted that HCI
(human-factor interaction) conferences have the nastiest
discussions in all of Computer Science -- if you're at a
conference on data structures then people are really nice and
positive and try to give useful advice to each other, whereas HCI
discussions tend to rip each other apart.  I've noted a similar
thing in music academia -- the more subjective the subject, the
more personal the participants take the debate.  It's an
understandable human response that is seen in any number of
venues.

For that reason, I'm going to try to keep the GLISS discussions as
focused as possible.  That's why I'm reserving an extra month
before starting it.

- Graham