It's been many years since this was written; we're ignoring it for
now because of changes in circumstances, and some day it should be
revamped. - Robin Powell, 12 Apr 2010
Background document: See section 2.2. Manner Of Operation in the Mini-Dictionary page on which Nick Nicholas goes into the background and nature of the Language Definition Committee in depth.
Please read the whole thing before commenting. Please comment using the 'discuss' tab. Thanks. --rlpowell
Just for the record, if I happen to respond to something you said as 'admin' instead of 'rlpowell', that doesn't mean I making a Weighty Pronouncement or Giving Orders or anything. It just means I forgot to log out as admin. My bad. --rlpowell
- Each member chooses zero or more sections ey would like to preside over.
- The member is given a Tiki page for the section, upon which ey writes an initial proposal of the detailed meaning of the word or words in that section and examples of usage. No pre-requisite work is required, but utterly senseless proposals will likely result in the jatna finding someone else.
- The member has sole write access to eir section page.
- All discussion on proposals should occur using the discuss link, not the comments link.
- Please, please use the reply button in the forums (aka the discuss link) when you are replying to a particular person's post. This may not look important now, but trust me, it is.
- All members should be subscribed to wikichanges and wikidiscuss. Use the mailing list interface at http://www.lojban.org/lsg2/.
- A poll is attached to the proposal page, where people vote to indicate their approval of the proposal. Voters may change their vote at any time. Voting 'yes' on an un-finished or incomplete proposal is solely a statement of general approval.
- The proposal may change at any time; it is up to the voter to insure that they are informed of changes so that they may change their vote, either by using the "watch this page" button or subscribing to the WikiChanges list.
- Votes against a proposal must be accompanied by an explanation of the perceived problems. The goal of the BPFK is to perfect Lojban, and we can't do that unless all members share their points of view and describe what, if anything, they see as wrong with a proposal. Such an explanation should be public unless there is a really, really good reason to keep it private, and if it is kept private you must inform the jatna.
- Failure to explain No votes will be considered obstruction of BPFK business, and will be grounds for removal.
- Votes on non-administrative issues are consensus minus 1.
- Votes on administrative issues are 2/3 majority. A vote on an administrative issue may be called at any time by any member, and everyone, including the jatna, is bound by them. The jatna strongly prefers that you take any problems up with him first, however.
- The jatna will define (presumably with some sort of community approval) checkpoints from time to time.
- Checkpoints will have a focus, and hence a list of sections which will be checkpointed. Work done in sections not relevant to the next checkpoint will be ignored (although you're welcome to do it).
- No votes or proposals are final until the checkpoint is complete.
- Completeness of a checkpoint is determined by a consesus minus one vote, with the exceptional feature that every member that votes "No" must also state the way in which the checkpoint is not ready. Failure to do so will cause the vote to be ignored.
- When the community has voted the checkpoint completed, the jatna will lock the pages, and confirm with every member that their vote on each section they voted on is correct, given the final state of the proposal.
- When that is done, the pages get moved to an archive for the given checkpoint, and all the passed proposals are considered to define Baseline LLG Lojban. Note that all proposals in checkpoint sections must pass for a checkpoint to be complete.
- Progress to the next checkpoint then begins. Lather, rinse, repeat.
- Please note that a particular section can be opened more than once. In particular, a future checkpoint can re-open a section if a problem with the previously approved proposal is discovered.
- A proper proposal should be amazingly detailed, and should refer to previous discussions where at all possible.
- It is assumed that an initial proposal will be pretty weak by comparison to a final proposal, and that all members will help flesh out the proposal and help to create consensus.
- Examples should, as much as possible, be drawn from actual usage. The Corpora page is helpful there.
- Part of a shepherd's job is at peruse previous discussion (on the mailing list and whatnot) for previous controversies or discussions WRT the cmavo in question. This dovetails nicely with the search for examples, except that the search for discussion should include the name of the selma'o as well as the cmavo themselves.
- Things that should be including in proposals (but not necessarily in every proposal):
- Expanded cmavo definitions. This should be considered a top priority in all sections where it is relevant (which is just about all of them), because the current cmavo definitions suck.
- Proposed new cmavo, with justifications.
- Expanded gismu definitions, if deemed necessary.
- Proposed new gismu definitions, if deemed necessary.
- Proposed grammar changes.
- Examples of usage in every fashion that the items discussed in the proposal could feasibly be used, especially of cmavo. I'm serious about this: lack of examples is one of the major places the current cmavo list falls down. There needn't be an example for every single cmavo, but there certainly should be an example for every class thereof.
- A Changes section collating all the ways the proposal deviates, or seems to deviate, from the current status quo. If it is unclear whether a part of the proposal deviates from the status quo, put it here anyways.
- An Impact section listing the expected impact of the stuff in the Changes section, to the best knowledge of the shepherd. "Does no invalidate any existing usage; no impact expected." is perfectly acceptable for this section.
- Given the extensiveness of that list, it should probably be noted that the jatna has absolutely nothing against any change that preserves past usage intact, and will very likely consider blindly voting against a change that preserves past usage to be wilfull obstructionism, which he doesn't like very much.
- On the other hand, the jatna thinks that invalidating past usage is a very, very bad idea.
- "Blind voting" is defined as "voting based on an issue which is not directly germane to the proposal at hand, rather than the merits of said proposal", and the jatna doesn't like it very much either.