History: Old BPFK Procedures

Source of version: 16 (current)

* ((BPFK Community Work)) ! OBSOLETE 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. ! Outline of BPFK Procedures 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)) !! Member Responsibilities * Each ((BPFK Members|member)) chooses zero or more ((BPFK Sections|sections)) ey would like to preside over. * The ((BPFK Members|member)) is given a Tiki page for the ((BPFK Sections|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 ((BPFK Members|member)) has sole write access to eir ((BPFK Sections|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/]. !! Voting * 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. !! Checkpoints * The jatna will define (presumably with some sort of community approval) checkpoints from time to time. * ((BPFK Checkpoints|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 ((BPFK Checkpoints|checkpoint)) is complete. * Completeness of a ((BPFK Checkpoints|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 ((BPFK Checkpoints|checkpoint)) is not ready. Failure to do so will cause the vote to be ignored. * When the community has voted the ((BPFK Checkpoints|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 ((BPFK Checkpoints|checkpoint)), and all the passed proposals are considered to define Baseline LLG Lojban. Note that all proposals in ((BPFK Checkpoints|checkpoint)) sections must pass for a ((BPFK Checkpoints|checkpoint)) to be complete. * Progress to the next ((BPFK Checkpoints|checkpoint)) then begins. Lather, rinse, repeat. * Please note that a particular ((BPFK Sections|section)) can be opened more than once. In particular, a future ((BPFK Checkpoints|checkpoint)) can re-open a ((BPFK Sections|section)) if a problem with the previously approved proposal is discovered. !! Proposals * 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.