From lojbab@lojban.org Fri Oct 12 05:27:47 2007 Received: with ECARTIS (v1.0.0; list llg-members); Fri, 12 Oct 2007 05:27:48 -0700 (PDT) Received: from eastrmmtao105.cox.net ([68.230.240.47]) by chain.digitalkingdom.org with esmtp (Exim 4.67) (envelope-from ) id 1IgJbz-0007Ja-Bh for llg-members@lojban.org; Fri, 12 Oct 2007 05:27:42 -0700 Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071012122705.ZNWD5742.eastrmmtao105.cox.net@eastrmimpo02.cox.net> for ; Fri, 12 Oct 2007 08:27:05 -0400 Received: from [127.0.0.1] ([72.192.234.183]) by eastrmimpo02.cox.net with bizsmtp id zQT21X00K3y5FKc0000000; Fri, 12 Oct 2007 08:27:04 -0400 Message-ID: <470F688A.2050209@lojban.org> Date: Fri, 12 Oct 2007 08:28:58 -0400 From: Bob LeChevalier User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: llg-members@lojban.org Subject: [llg-members] Re: LLG AGM 2007: New Business References: <20070918181955.GW10667@nvg.org> <20071010000942.GZ10376@digitalkingdom.org> <20071011190654.GO13890@digitalkingdom.org> <470E9480.3000307@lojban.org> <20071012022955.GG13890@digitalkingdom.org> In-Reply-To: <20071012022955.GG13890@digitalkingdom.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 X-Spam-Score-Int: 0 X-Spam-Bar: / X-archive-position: 394 X-ecartis-version: Ecartis v1.0.0 Sender: llg-members-bounce@lojban.org Errors-to: llg-members-bounce@lojban.org X-original-sender: lojbab@lojban.org Precedence: bulk Reply-to: llg-members@lojban.org X-list: llg-members Robin Lee Powell wrote: > If you wish me to despair less, you must show me that this situation > will be resolved in the forseeable future. Telling me that I'm > missing the point of the BPFK is no good: I already know, and I'm > very nearly past caring. Telling me you will confront me with > legalities is no good: it simply increases my despair, because if > legalities will be used to slow the process of something that is > already this slow, we will literally never finish. > > Show me another way. Show me something other than the future I see > before me, which is another 5 years of trying to respect the > baseline in front of newbies when my own writings use xorlo. As I understand it, what has been happening is that whenever some checkpoint becomes contentious, the few people who are paying attention exhaust themselves in argument without resolving things, and then everyone goes away until you manage a new push to action. Yet supposedly all we have left are boring sections about which there are few issues. Why then aren't they getting written instead of trying to resolve what people are not ready to resolve. It is the pressure to resolve issues (usually under a time limit, since they are only raised as part of a checkpoint discussion), rather than to get the documentation of the status quo done, that causes the repetitive stagnation. Documentation of the status quo is boring, I know, because I am the one who never got the dictionary finished. But it needs to be done to properly consider, much less resolve, issues. The original intent, as I understood it, was that we were going to document the baseline as is, and document a set of change proposals to that baseline (I had envisioned when byfy was founded that these would be documented in the manner that we came up with for baseline change proposals http://www.lojban.org/publications/formal-grammars/techfix.300 or some appropriate modification thereof. I will note that nearly all grammar baseline change proposals that were written up in that way were adopted without a helluva lot of contention. If it was entirely unclear what the baseline had to say about an issue, the checkpoint writer was going to merely do his best to document usage and whatever CLL had to say, and propose something that would reflect these, while noting that the issue in question needs further scrutiny. Anyone who has done software maintenance should know how configuration management works, and all I've ever proposed is a version of traditional configuration management of an existing product. Yes, it is bureaucratic (i.e. heavy on procedures and paperwork), but by making a procedure bureaucratic it DOES get done eventually, and is generally accepted once it has been done because everyone knows that there was more than sufficient deliberation. (I see what is currently being done as more akin to software development, which is deadline driven, and often leads to embarrassing mistakes that creep in under deadline pressure. We don't want to be issuing patches to a new baseline). If this had been done from the start, then a long time ago we should have had, with almost no debate at all, a draft for every section, and a whole bunch of questions, issues, and change proposals to be considered, all of which would be decided upon as changes to the *complete* draft. There should have been no contention in writing those draft sections. There should have been no actual decisions being made except by the person writing each section. There should have been no debate-and-decision on *any* issue until *all* the sections had been drafted, though there might have been informal questions questions and discussion raised on drafts so that they could be dealt with later. People seem to be unwilling to hold off debates until the baseline is documented as best can be, and thus we get bogged down in almost every section. The solution, it seems to me, is to return to this original idea, have section leaders document the baseline, and write up their position on each issue in detail. No voting yet. Allow *several weeks* for people to review all the sections and issues, with the goal being to make sure that all issues have been identified. Someone identifying a new issue has the obligation to write it up as an issue in whatever the approved format is. (Right now, the obligation seems to be the rather steep one of reviewing and of coming up with alternative proposals on a checkpoint that I probably haven't even looked at until it is announced, and to do so within a week or so.) Then move into a second phase where issues (not sections) are discussed and voted on in the manner that we are currently using to vote on sections. When there is no consensus, put it aside and move on. When all easily decided issues are decided, then go back to the contentious ones. Hopefully there will be relatively few such issues, and in the context of a more or less complete set of materials for all parts of the language, the pressure is on people to come to some sort of consensus which might involve some horsetrading on issues across a wide swath of the language (e.g. "I'll accept xorlo, if you accept my preferences on these other issues"). I find it easier to imagine being able to consider and vote on a single well-documented issue in the context of a full set of documentation, under the sorts of time limits that we've had for byfy checkpoints. Voting on sections, I find more difficult. Then give section leaders time to incorporate the decisions in their sections (they might have been doing this already while other issues are being decided). Once that is done, approving each section, and then approving the whole should be relatively trivial. I suspect that some of what I would like to see may already exist. Draft proposals may or may not already be out there for all the remaining sections we have not debated, and we are presumed to have been reviewing them all along. But because I am not a wiki person, and in general work *offline* (and Nora even more so - she does most of her Lojban work on the train to and from work), I don't even look at sections until they are announced as ready for discussion, at which point I download them, print them out, and read them, and with a timelimit of only a few days, I seldom form an opinion worth posting before the discussion has moved on. And the fact that NO changes are being written up as formal baseline change proposals means that the onus is on me to try to figure such things out, which usually means plowing through all the discussions. lojbab