%META:TOPICINFO{author="NickNicholas" date="1048776720" format="1.0" version="1.6"}%
%META:TOPICPARENT{name="Administrative"}%
You may also wish to look at [[BPFK Guidelines: Short Version]], by Main.RobinLeePowell.  Although it is quite unofficial, it is much less frightening.

---

---+ Procedure

Based on the outlines given in [[http://www.lojban.org/wiki/index.php/Mini-dictionary][my manifesto on the wiki]] and [[http://www.lojban.org/llg/baseline.html][the board statement]], the procedure for defining a paradigm in the BPFK shall be as follows.



	1 For the given paradigm, a commissioner designates themselves as *shepherd* for the paradigm, by emailing the [[Main.NickNicholas][BPFK Chair]]. The shepherd has the responsibility of formulating the initial definition of the cmavo in the paradigm, of tracking all previous discussion of the cmavo, and of incorporating criticisms and any emerging consensus into the definition. In other words, they start, sustain, and end the discussion on the definition of the cmavo in the paradigm; that definition becomes their responsibility. If the task proves too much, they can delegate parts of the task at their discretion, but are still responsible for ensuring that all necessary tasks are fulfilled.
	1 The BPFK chair posts the shepherd's name on the [[Polling]] page on the Twiki, and the [[http://www.lojban.org/phpbb][Shepherd Announcements phpbb forum]] , and grants them moderator priviliges to the [[http://www.lojban.org/bpfk][phpbb]] forum for their paradigm.
	1 The shepherd familiarises themselves with the CLL explication of the paradigm and the particular cmavo within it. This necessarily forms the starting point of any definition work.
	1 The shepherd searches the entirety of lojban list ([[http://www.wiw.org/~jkominek/lojban/][old]], middle [Apr-Nov 1998], and [[http://www.yahoogroups.com/group/lojban][new]]), [[http://www.yahoogroups.com/group/jboske][jboske]], the (php) [[http://www.lojban.org/wiki][wiki]], and all other pertinent technical fora, for all past *debate* that have been conducted on the semantics and the grammar of the cmavo. They should take note of the issues brought up, the distinct positions stated, and the consensus position that has emerged (if any).
	1 The shepherd surveys past *usage* of the cmavo, bearing in mind the controversies raised in the past, as well as any issues they feel should be raised now. This means that they scan over lojban list, jbosnu, the irc logs, JL, and all other pertinent corpora for all instances of use of the cmavo that might offer data from usage for or against any proposal.
	1 The shepherd authors a document on the Twiki for each cmavo in the paradigm. That document serves as the starting point for BPFK discussion, and is termed a *definition page*. The definition page starts with an elaborated dictionary definition of the cmavo, concentrating on the semantics. It then expands on the grammar of the cmavo, including how it interacts grammatically and semantically with other cmavo and selma'o. Where the shepherd feels a non-trivial issue in the semantics or grammar has not been brought up to date, they are free  to include their own proposals in the document -- provided that the design principles of Lojban are respected.
	1 For every issue where there is deviation from the existing baseline (and CLL in particular), or where the proponent is contributing their own innovation, that issue must be decided on by a *[[Polling][poll]]* among the BPFK membership. Non-members may participate in any discussions, but are barred from voting in the poll, on the grounds that they have not made the commitment to follow BPFK discussions at the level needed to make an informed vote. 
		1 Each poll is accorded its own page on the Twiki. A poll page should be hyperlinked back to the definition page for the cmavo, with a succinct link ("[Poll]") inserted in the spot where the issue is raised. The definition page should also contain at its conclusion an index of all polls attached to it. An example definition page is given at [[Nau]].
		1 The formulation of the poll must be preceded by documentation styled after the *techfixes* of yore: it must include a description of the baselined status quo =("Current Language")=, the proposed =fix= or emendation, and a =rationale= for the change or addition. 
		1 Using the structure proposed in the [[http://www.lojban.org/wiki/index.php/Elephant][Elephant]], the rationale should be posted separately from the definition page. (As discussed below, they will currently not appear on the twiki at all, but on phpbb.) This means that: 
			* the definition page becomes the _Issue_. (It presupposes the affirmative position for all positions raised, because the shepherd is writing the definition; but the definition page is understood to be a starting point for discussion, not an endpoint --- the shepherd will need to keep editing it.)
			* the polling page becomes a _Position_.
			* The rationales and counter-rationales pages become _Arguments_.
		1 Where a proposal has already been proposed in the past on another forum, the shepherd's description of the proposal must be accompanied by supporting *documentation*, in the form of hyperlinks to the mailing list threads and documents where the issue has previously been raised. This is so that other commissioners can access and peruse those threads, to form their own opinions on whether prior community consensus has been respected in this formulation, and whether the fix is well justified. This material should reside on the polling page for the particular position, and can be referred to by commissioners posting rationales both for and against; so it needs to include *all* past discussion on the issue, pro and con.
		1 Wheresoever there is extant Lojban usage relevant to the proposal, the techfix documentation on the polling page must also give a listing of all such *usage*, preferably with hyperlinks, giving counts of instances supporting and contrary to the proposal. Further breakdown by era and author may prove necessary. This material too can be referred to by the rationales for and against, and should thus be placed on the polling page.
		1 For the time being, the generation of techfix/polling pages will not be automated; shepherds are expected to use a *[[Polling Template][template]]* on the Twiki instead. They are expected to adhere to its format: full rationales and presentations of the status quo must be presented, and the poll must present only three options: yes, no, and abstain. Failure to adhere to these guidelines will render the poll void.
	1 The presentation of prior debate on the cmavo must be *full and impartial*; shepherds are working not only to further their own views, but to document the past debate fully. Thus, revisionists must use the canonical position as a departure point, and must present fully its strengths as well as its weaknesses. Conversely, fundamentalists must present -- and address -- the inadequacies in the canonical position pointed out in the past.
	1 There are three fora for BPFK work. It is important that they be kept separate to avoid confusion. 
		1 Formal and documented statements of positions (definition pages, techfix proposals on polling pages) belong on the Twiki, as standalone documents of record. The BPFK Twiki is intended to be a forum for structured presentations of proposals only. In particular, the authoring of pages shall not be incremental; this makes it impossible for commissioners to keep track of the current form of proposals and their authorial responsibility. The Twiki pages are to be treated as static. These positions must not be responded to in an unstructured way; if one finds a flaw in an argument for, one should post a rebuttal as an argument against, along with all other arguments for and against -- but outside of the polling page itself. Any response to this rebuttal needs to be presented as a new rationale in turn. 
		1 All debate should be taking place on *[[http://www.lojban.org/bpfk][phpbb]]* instead of Twiki. In particular, the arguments for and against a particular position will be posted on phpbb, rather than the Twiki. This is where the true discussion of the issues takes place; the definition pages are more like the "records" of recent memory, and will be modified in light of the ensuing discussion. The twiki is where the shepherd lays down (and revises) the law on the cmavo; the phpbb is where they make their case, and others make the case against.
		1 If having the arguments on phpbb proves untenable in the future, existing arguments will be migrated back to Twiki. Since cross-referencing of arguments is necessary, each argument needs to be *numbered consecutively*. If they are migrated back to the Twiki, they will be separated on the same page with a horizontal rule; but arguments for and against should appear on separate pages. 
		1 *Arguments must be easy to find*. Any argument posted on a phpbb Arguments topic must bear its incremental number in the posting subject: each posting must thus be titled =PRO #n= or =CON #n=. (For easy browsing, I recommend commissioners color-code their arguments, red PRO and blue CON.) Arguments pro and con are made on a single topic on the phpbb, which must be titled in a way corresponding to the polling page, as =_cmavo:_ Arguments: _Poll Name_=; e.g. =nau: Arguments: Sumti Tcita Here-now Description=. The very first post to an Arguments topic must be neither a PRO nor a CON post, but an anchor back to the Twiki, phrased as =Refer to poll on [URL]=. The moderator of the topic (the shepherd), who posts this header message, needs to ensure it is labelled in phpbb as 'sticky' -- that is, it appears on the top of each page of topics. For illustration, see [[http://www.lojban.org/phpbb/viewtopic.php?t=8]]
		1 If arguments are migrated to the Twiki, commisioners can append their arguments, but must not edit previously formulated arguments. In phpbb, where the arguments are currently to appear, commissioners should not postedit their arguments; the forum itself will keep track of authorship.
		1 Administering debate on an issue -- the *meta-forum* -- also belongs on the [[http://www.lojban.org/bpfk][phpbb]] forum. For instance, this is where requests for clarification of arguments and positions can be made; where polls are announced; and where anti-shepherds get decided (see below.) Such meta-talk must be kept separate from any arguments on polls; these will be in separate topics, and restricted to formal presentations of arguments. The moderator is entitled to prune informal posts out of the Arguments threads, as off-topic, and onto general discussion threads.
		1 More open-ended issues, which require free-style debate, should be raised on the *jboske* mailing list. Free-style debate is not recommended, however, given the complexity and volume of the issues involved.
	1 The responsibility for the content of any page rests with the author of that page, and any adjustments to the page that emerge as necessary through discussion must be undertaken by the author. (If arguments are migrated to the Twiki, authority for any argument remains with its author, and all arguments must be signed.)
	1 If a commissioner requests that a particular issue in the shepherd's proposal be *brought to vote*, the shepherd must create an additional poll page to that effect, hyperlinked as with the other poll pages from the definition page on the cmavo. 
		1 If the request concerns an innovation, the shepherd is obliged to provide a status quo and fix proposal for their innovation, and should post an argument defending the innovation. The opposing commissioner may supply a refutation as is normal with arguments. 
		1 Conversely, if the request is for an innovation which the shepherd has not proposed -- that is, if there is something else the commissioner wants changed in the language -- then the shepherd must decide whether they agree with the request or not. If they agree, they present the proposal as with the other techfix/polls. If they disagree, they must allow the techfix/poll to be authored and attached, but they are released from the obligation of authoring the proposal themselves -- in which case that is the opposing commissioner's responsibility. The shepherd is always free to post arguments against the proposal.
	1 On releasing the definition page, the shepherd makes a *call* on the phpbb for arguments to be made on the Twiki, for each position raised. The deadline for arguments shall be at the shepherd's discretion, as it will vary according to the complexity of the issue; but it should by default expire with two weeks of no new postings made to the php Arguments forum. The shepherd then calls for polls to be voted on for those positions; again the deadline is at the shepherd's discretion, but by default shall be a week. Commissioners can change their votes before the deadline expiration.
	1 Coherent *naming* of pages in the Twiki must be adhered to, to allow information to be accessed and classed readily. In particular, any pages discussing a cmavo or selma'o must have their title begin with that cmavo or selma'o. (The Twiki address space is case-sensitive.)
	1 The shepherd *administers the phpbb forum* on their paradigm, as moderator. If the issues being discussed become inordinately complex, the shepherd may at their discretion split the forum into distinct fora, specific to particular cmavo or to particular areas of discussion within a cmavo. The titles of fora and discussion should also be readily identifiable.
	1 Once the discussion document has been posted on the Twiki, the shepherd shall post an "executive summary" on the *[[http://www.lojban.org/jbovlaste][jbovlaste]]*, as a brief definition. It will be at the discretion of the dictionary editors to decide how much of the BPFK work will end up in the dictionary proper, how much in a CLL supplement, and how much online without entering into book form. The shepherd is responsible for entering at least a bare minimum into jbovlaste; if a choice needs to be made, the priority goes to the cmavo semantics, rather than its grammar. Non-trivial examples should also be entered into jbovlaste, preferably from actual spontaneous usage. jbovlaste is not a valid forum for the BPFK to deliberate on the merits and failings of particular proposals, however much that ends up happening for lujvo. The forum of record for the BPFK remains Twiki (content) and phpbb (meta/rationales), and splitting discussion off into multiple fora impedes the BPFK getting its work done efficiently.
	1 A definition may encounter significant *opposition* (requiring at least two commissioners unable to accept the proposal as a whole, or at least in some crucial details of those put to poll). Recall that the BPFK operates by consensus, not majority vote; the objection of two commissioners is sufficient to demonstrate that consensus has not been reached. If the shepherd cannot reconcile their definition with such opposition from other commissioners, then the BPFK chair, in consultation with the participants in the debate, shall designate an *anti-shepherd* to formulate an alternate complete definition document for the paradigm. The anti-shepherd will be expected to follow the same steps as the shepherd, and to link in to their proposal all existing poll pages. Once the counterproposal is formulated, there shall be a global vote on which of the two proposals better reflects BPFK opinion on the paradigm. This is intended as a last resort measure, however, since it deviates from the pursuit of consensus.
	1 Two negative votes are sufficient to *defeat* a proposed innovation; if this occurs, the shepherd has the responsibility either to withdraw the innovation (in a way that does the remainder of the definition as presented least violence), or to moderate it to satisfy the opponents' concerns, by placing a new description of the issue in the definition page, and a new poll attached to it. It is not the intent to present rival solutions for selection in a poll; that works against establishing a clear consensus. If two rival solutions emerge, however, it is appropriate to conduct informal and non-binding straw-polls on their relative popularity on phpbb.
		1 Proposals must always be phrased with the vote for innovation being in the *affirmative*: it must be easy to impede innovation, rather than difficult to defend the current standard. 
		1 The *minimum number of votes* required for a vote to be valid is three; there is no requirement that all commissioners vote on an issue. 
		1 Where the notions of *majorities and minorities* become relevant, they are deemed to be the majority or minority of commissioners who have voted, not of the entire BPFK.

---+ Ideology

	1 The BPFK is entrusted with the task of elaborating the definition of cmavo, while maintaining backward compatibility with the existing cmavo. 
		1 *Elaboration* in semantic or grammatical specificity is therefore always a legitimate goal for commissioners to pursue within the BPFK. Indeed (in what is intended as an unabashed departure from prior policy), I believe as BPFK chair that "Let Usage Decide" is no longer an acceptable default for Lojban semantics. Letting Usage Decide has already led to [[http://www.lojban.org/wiki/index.php/Humpty-Dumpty][humpty-dumpty]]ing, confusion about semantics, and divergence within the community. The policy was intended to allow language elaboration to occur in a "natural" way in a robust, post-baseline, large language community; but both ideological and practical issues make it necessary to fill in now gaps previously "left to usage". 
		1 As a result, if a commissioner advocates that the BPFK should *Let Usage Decide* some issue, they must supply an explicit rationale why; "Because that is the Lojban Way" is not an adequate rationale. The BPFK shall explore elaboration, rather than "organicism", as the Lojban way, to the extent that it is feasible -- even though clearly it will not be possible to specify everything, and there will inevitably remain aspects of the language to be determined by Usage. (In particular, Lojban stylistics cannot be prescribed by the BPFK, although some trends in a Standard Lojban Style may already be noted.)
	1 Elaboration includes supplying explicit means of grammatical or semantic *disambiguation*, where such are not currently available.
		1 The *[[http://www.lojban.org/wiki/index.php/Grice%20Salvator]["Grice Salvator"]]* is not an adequate argument against such a venture, although violation of the design principles of Lojban is. 
		1 Elaboration can also involve more *formal statements* of the definition of cmavo. Individual commissioners' unfamiliarity with details of logic or formal semantics does not render such a pursuit illegitimate, although the proponents have a strong moral (and practical) obligation to explain their proposals in terms accessible to non-specialists. 
		1 Elaboration also includes the resolution of *inconsistencies* in the existing baseline, the elimination of which remains the *first priority of the BPFK*.
	1 The second priority of the BPFK is *maintenance of backward compatibility*. Formulations in CLL in particular may be annulled only when CLL is *"broken"*: that is, 
		* where there is internal contradiction (including with the machine grammar, which is deemed part of CLL), 
		* violation of design principles of Lojban (including syntactic and morphological ambiguity), 
		* or overwhelming disconfirmation from usage. 
		* While *logical analysis* will not have a primary role in advocating breaking compatibility with CLL, it can legitimately have a primary role in motivating elaboration of the CLL prescription -- as can usage.
	1 The *design principles* of Lojban have been spelled out to some extent already, but will need to be spelled out further. 
		1 Lack of *morphological and syntactic ambiguity* is a design criterion. So is the ability to *resolve semantic ambiguity* by providing additional information, whether lexically or grammatically. 
		1 Lojban also has certain *established ways* of dealing with grammar -- employing an LALR1 grammar, resolving morphology using certain algorithms, assuming an extensional classical logic as underlying the language -- which are essential to its definition, and therefore the baseline. Going outside these established approaches is a legitimate task of exploration for Lojbanists, and the results may end up a better fit than the current mechanisms are to Lojban (or to Lojban as it will end up being used). However, these alternatives may not supplant the current mechanisms in their definitional role. To do so would underline the established baseline more radically than the BPFK has a mandate for: *the BPFK has a mandate to flesh out the design of Lojban, not to redesign it*.
		1 So the fact that Lojban is based on *classical predicate logic* should be considered a definitional trait of the language. Insights from classical logic are, as a result, legitimate grounds for any argument on Lojban grammar. 
			1 The *conventions* of classical logic do not have the same binding status on Lojban, but where Lojban does things differently from logic, some justificcation will be expected. (Refer to the [[http://www.lojban.org/wiki/index.php/quantification%20and%20the%20meaning%20of%20ro]["Importing ro"]] discussion for an illustration of such an issue.) 
			1 Insights from *other traditions* in the analysis of language and reasoning, such as contemporary formal semantics and non-traditional logics, are also legitimate, provided that they do not usurp classical predicate logic as the definitional basis of the language. 
				1 For example, any treatment of Lojban gadri needs to accord primacy to extensions rather than intensions, notwithstanding the primacy of intensions in Montague grammar: the metalanguage of Lojban as defined in CLL is explicitly extensional, and to revise that would require discarding whole chapters thereof. 
				1 Likewise, though Lojban can accomodate fuzzy logic, the default logic of the language is categorial and truth-conditional.
				1 The fact that alternative frameworks may be more elegant than the baselined Lojban framework is not a sufficient rationale to discard that framework: inelegance does not constitute brokenness.
				1 Brokenness, however, _does_ constitute brokenness. For instance, the failure of current standard Lojban to differentiate between the number of entities sought is a problem requiring a remedy -- although not necessarily a Montagovian remedy.
		1 Similarly, an alternative *BNF or YACC* LALR2 grammar may have the same descriptive adequacy as the current YACC grammar, and may even have greater explanatory adequacy, as it will likely produce a more intuitive description of the language. While the current baseline remains in effect, however, the BPFK has no authority to replace the YACC grammar with a completely different grammar formalism. (As it stands, the BPFK has an uphill battle even in revising individual parser rules.) So while the Lojban community needs and must support alternative formalisations (as seen in the mass adoption of [[http://go.to/jbofihe][jbofi'e]], based on the semi-official EBNF grammar), the definitional formalisation remains unchanged. In the case of grammar, that definitional formalisation is the official, YACC-based grammar.
		1 Likewise, alternate formulations of the Lojban *morphology rules* are welome; but where defined rules of Lojban morphology exist, such formulations cannot supplant them. A separate morphology commission (vlataipla fuzykamni) has been constituted by the Board, reporting to the BPFK chair.





-- Main.NickNicholas - 23 Mar 2003
