History: Old BPFK Procedures

Source of version: 11

! 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 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. 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/]. !! 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. * 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. !! 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.

History

Enable pagination rows per page

HTML diff Side-by-side diff Side-by-side diff by characters Inline diff Inline diff by characters Full side-by-side diff Full side-by-side diff by characters Full inline diff Full inline diff by characters Unified diff Side-by-side view HTML diff Side-by-side diff Advanced

Information	Version
Tue 13 of Apr, 2010 06:27 GMT rlpowell from 64.81.66.169	16
Mon 18 of Dec, 2006 17:48 GMT Eppcott from 209.220.229.254 Added wikilinks	15
Fri 15 of Dec, 2006 16:59 GMT Eppcott from 209.220.229.254 added link to Mini-Dictionary	14
Fri 14 of Jul, 2006 21:26 GMT rlpowell from 64.241.242.18	13
Wed 14 of Dec, 2005 20:37 GMT rlpowell from 64.241.242.18	12
Wed 14 of Dec, 2005 20:37 GMT rlpowell from 64.241.242.18	11
Sun 14 of Mar, 2004 09:12 GMT rlpowell from 67.101.149.154	10
Wed 28 of Jan, 2004 21:20 GMT admin from 198.6.50.31	9
Sun 18 of Jan, 2004 21:43 GMT rlpowell from 64.81.49.216	8
Fri 14 of Nov, 2003 18:15 GMT admin from 198.6.50.33	7
Thu 23 of Oct, 2003 22:22 GMT admin from 63.96.169.98	6
Tue 21 of Oct, 2003 04:19 GMT rlpowell from 64.172.182.79	4

Select action to perform with checked... Remove OK