From owner-freebsd-hackers Tue Jan 21 13:32:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA15177 for hackers-outgoing; Tue, 21 Jan 1997 13:32:22 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA15169 for ; Tue, 21 Jan 1997 13:32:16 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA20003; Tue, 21 Jan 1997 14:15:55 -0700 From: Terry Lambert Message-Id: <199701212115.OAA20003@phaeton.artisoft.com> Subject: Re: Commerical applications (was: Development and validation To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 21 Jan 1997 14:15:55 -0700 (MST) Cc: terry@lambert.org, joerg_wunsch@uriah.heep.sax.de, hackers@FreeBSD.ORG In-Reply-To: <19120.853823290@time.cdrom.com> from "Jordan K. Hubbard" at Jan 20, 97 09:08:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Since you seem to be so motivated to change things, however, rather > than just advancing these byzantine and ultimately useless statements > of the obvious (Readers Digest version for those who have fallen > asleep at this point: "I think you're doing something wrong, my > ``evidence'' clearly shows it, stop doing that") why don't you instead > try and suggest practical solutions? Well, until now, people have been more interested in defending the current social system instead of analyzing it ("My Country, Right Or Wrong!"). This is actually the first time I have gotten a response to one of my requests for discourse. > You say we're too ossified yet you also agree (I hope) that quality > control and not letting just any CS undergrad who only learned to > spell "C" last month hack the kernel code is a good thing. What > system would you propose in its place? If this system also involves > that additional tools be implemented, an indication of your > willingness to write those tools should the proposal be accepted would > also be apropos. A weighted democracy would be one open-ended growth soloution, as long as parametric changes could be made within the system. I have suggested this before. A trivial napkin drawing version: 1) There is a vote server for the group 2) When you join the group, you begin accumulating "vote tokens" on the server, up to some high water mark. 3) Anyone can call for a discussion on a topic relevant to the group; this is done by phrasing it in the form of a resoloution 4) Discussion ensues 5) At any time in the discussion, there can be a call for votes to either make a binding vote on the topic, or to discontinue the topic 6) After the call for votes, a timer is started 7) Anyone who wants to can vote for or against a vote taking place; this vote does not take a token. 8) The call for votes timer expires. If there is a simple majority, a vote is initiated for the topic; if not, the topic is discontinued 9) When a vote is initiated, another timer starts 10) People can vote for or against the resoloution. They can "spend" up to 3 vote tokens on either side of the issue. They can not "spend" votes they do not have. The person who proposes the resoloution must propose it with at least one vote token committed to it in the case it comes to a vote. 11) The voting timer expires. Each vote token is counted as one vote for the purposes of establishing a simple majority as to whether or not the resoloution is adopted by the group. 12) The group agrees, by virtue of self-selection at the time they join the group, that all votes will be binding on the group. This is called a "Modified Swiss Democracy Based Private Law System". Possible preterbations which may or may not be desirable to ensure homeostatic balance: A) Initial membership entitles you to some number of tokens, credited when you join the group, with appropriate safeguards against repeat joiners. B) Idle timers to diminish the effective power of non-voters; of you have joined the group, but do not participate in a single vote in a set period of time, your vote tokens are reduces to some low watermark. C) Accumulation of "request for discussion" tokens to limit the number of discussions D) Simultaneity limits on the number of votes/discussions which may be concurrently taking place. E) Automatic adjustements to watermarks based on percentage membership of the group rather than arbitrary fixed values. F) Timer values. I propose 2 weeks for CFV, 2 weeks for V. G) Ability to change the value of your vote up H) Ability to change the value of your vote down (I would recommend against this one because of "market timing" phenomena). I) Disincent calls for votes by the caller losing the commited vote tokens even in the case that the topic was discontinued. J) Up the number of tokens possible to use on a resoloution to some number larger than 3. Clearly, this system would tend to self-squelch blusterers, and it would quickly become obvious who was or was not one. It would also give control of control over to the group rather than allowing the centralization on ossification of template control structures. It also does not have the obstructionist problems that the Usenet voting system has, since it is automated. This removes a lot of structural power from the hands of the core team, so it is unlikely to be well liked there, even though it does not remove their ability to be leaders by proposing innovative and technically superior ideas. If the ideas are obviously superior, they will get the necessary votes, at low cost (one token instead of three). If they are dubious, the vote cost will go up as they are more hotly contexted. People put their tokens where their mouths are. I would be willing to write the tools should this proposal be accepted, or help write them if I'm not trusted. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.