Re: "unofficial GOP proposal" organization of GLISS discussions

[Janek Warchoł]

Hi,

some clarification:
Most importantly, i'm not saying that we should *force* separating
discussions about problems from discussions about solutions.  What i
mean is to have a different approach than we had till now.

An example of what i consider an ineffective way of discussing:
personA: let's have syntax X
personB: this seems like a bad idea for me, because of Y
personA: in my opinion Y is not that important, and we could do Z to
avoid it.  Anyway, i don't want to use current syntax V because it's
inconvenient!
personB: but Z won't work (...)
[30 emails discussing technical reasons why syntax X might or might
not be feasible to implement]
[no conclusion on what we should do]

Here's how i suggest to discuss things:
personA: i have trouble with syntax V (or notation N) because of this
and that.  I would imagine that syntax X might be a convenient and
intuitive solution from a user's POV.
personB: i think there might be problems with unambiguous
implementation of syntax X.  Let's wait until we have more
context/information; for now we'll add an issue to the tracker about
problems with syntax V (notation N).
[persons C, D, ... speak about their problems with syntax and have
them added to the tracker]
[2 months later]
personJ: hey, i've looked at the tracker issues about problems of
persons A, D and F and i realized that problematic syntax V is just a
subset of problematic syntax W.  Solution X proposed by personA won't
be enough to solve W.  How would you solve W?
[brainstorm]
[parser expert H announces an official proposal U that would solve W
(and thus V as well, without introducing problems present in X).
Since that's an official proposal, everyone looks at it.  In the end,
people either accept U or something better]
[everyone is happy :D]

On Sat, Oct 6, 2012 at 2:43 PM, David Kastrup <address@hidden> wrote:
> I would want to venture the opinion that there is no substitute for
> reading a conversation before putting forward an opinion.

agreed.  I'm not suggesting that we shouldn't read long conversations.
 I'm suggesting that we should try making long conversations shorter,
for example by dividing them according to the subject (i.e. discussing
what is wrong is one subject, discussing how to solve it is another
subject).

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

Absolutely!  I haven't meant that we should dump "fuzzy feelings" into
the tracker.  Tracker issues should be concrete descriptions of what
is wrong and why.
Because of that we shouldn't add issues directly to the tracker, but
first post them to the list (bug-lilypond??) and make sure to explain
what is wrong, why, give examples etc.

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

Sure, you have a point.  But i'm *not suggesting* that we do it this
way: "hey, people, on November 5 we'll be discussing X and you better
have some code to discuss!".
I'm suggesting something more like this:
discussionLeader: let's discuss no more than one solution each week.
What shall we discuss this week?
developer J: i have an idea on how to solve Q.
developer D: i was recently thinking about solving K and i have a working draft.
Leader: let's talk about K this week, since there is a working draft
available.  We'll get back to Q next week.

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

I understand.  "omg wtf?! this won't work" was just a thought abbreviation.

cheers,
Janek