Marc Hohl <m...@hohlart.de> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
