Re: "unofficial GOP proposal" organization of GLISS discussions

[David Kastrup]

Marc Hohl <address@hidden> writes:

> Am 05.10.2012 18:34, schrieb Janek Warchoł:
>
>> i find it hard to keep up with our GLISS discussions.  I've also
>> heard that the amount of technical details, digressions and
>> "multithreadedness" stops some people from participating, as they
>> don't have enough time to read long conversations carefully.

I would want to venture the opinion that there is no substitute for
reading a conversation before putting forward an opinion.

A discussion is not a shouting match.  If a point has been carefully
made and reasoned, there should be no necessity to keep remaking and
rereasoning it in order not have it drowned out in the clutter from
people who can't be bothered getting acquainted with the context before
chipping in.

Yes, this makes it harder to contribute, but it increases the likelihood
of making a _useful_ contribution.  Also it does not help the motivation
of those people who have taken the effort of making a well-reasoned
point if they find that this effort has been quite futile.

>> Therefore i suggest to visibly separate discussing problems from
>> discussing solutions.
>> Currently we are mostly discussing ideas for syntax, i.e. "let's have
>> syntax X doing Y".  I suggest that for several weeks we shall focus on
>> "i find syntax W confusing" and "i find notation Z
>> difficult/inconvenient to express in current syntax" instead.  We
>> would add syntax problems that we identify as issues to the tracker.

I don't think that the tracker is necessarily a good place for "fuzzy"
feelings like that.  It would make sense to let them mature in
discussion into more concrete problem descriptions before putting them
in the tracker.

If you take a look at the tracker contents, you'll see that an issue
that has not seen an activity for a few weeks is quite likely not to see
activity for a few years.  Having a concrete, identifiable problem
description makes it more likely that it will get picked up at some
point in future again.

>> After we've finished gathering them, we'll sort the issues and *then*
>> we would discuss how to solve them.
>
> I second this in principle, but I fear that it would not be that easy
> to separate discussions about "defects" from those about syntax
> ideas in every case.

Well, my own problem with that is that our resources, and that includes
our attention span, are not unlimited.  There has been a lot of detailed
and partly rather exhausting (and ongoing) discussion on a recent set of
additions that can currently be labeled as \hide/\omit\single\undo.

The discussion was focused around concrete proposals, concrete code, and
concrete use cases.  The solutions we arrived at were a mixture of
"bikeshedding" in the form of agreeing on the best form of naming some
constructs interspersed with generic mechanisms evolving from the wish
of _avoiding_ finding new names for something that can be constructed
systematically.  Much of the process was shaped in a back-and-forth
between me as the code writer/proponent and potential documentation
writers (James, Trevor) in need of semantics that they were able to both
understand and explain, with occasional user views and questions from
Janek, Marc, Graham and others.  At any point of time, only very few
people were active here, but I like the results achieved in that manner,
while the process was rather cumbersome.

Now separating the problem-finding and solution-finding and coding
processes will render the whole procedure less effective of actually
moving towards a good _set_ of solutions fitting a problem space that
has been incrementally extended in order to offset problems stemming
from the solutions of only the original problems.

>> Why do it this way?
>> - we'll see the big picture better
>> - we'll be able to schedule the discussions about solutions, so it'll
>> be easier to participate in them
> +1

I don't really think we can "schedule" discussions about solutions when
much of the discussion can only be done in the light of actual changes
being written and tested.

>> And perhaps most importantly: when someone posts a syntax *idea*,
>> there's a chance that syntax experts will reply "omg wtf?! this won't
>> work".  This leads to frustration.

The problem is almost never an absolute "this won't work" but rather "I
don't see that this would come at an affordable price".  The price falls
into two categories again: upfront price (somebody has to do the actual
coding) and followup price (everybody has to live with the consequences
and side effects).

A non-coding user has no means to do anything about the upfront price,
and will rarely have the overview over the followup price.

>> On the other hand, if we discuss our *problems*, syntax experts can
>> just answer "it would be reasonable to solve it this or that way" -
>> and voila! less frustration.
> +1

I don't see the point in discussing discussing all too much.  It spends
time and does not really lead anywhere.  Let us just see where the
recent user poll on the national lists led with regard to problems.

-- 
David Kastrup