Someone: ... for the partnership it is important, as each one is liable to the other. We can't have 90% of the group decide over 10%. It's too dangerous. Every *partner* needs the right to veto. Alain: Yes, but not on everything. Anthony: Remember, we're all liable for everyone else's actions in the partnership, and I, for one, will not be a part of ANY such agreement where I can have a decision I do not consent to forced upon me. Alain: If a decision/vote is taken that exposes any or all of the FreeCard partners to any liability whatsoever and/or changes the Partnership Agreement, then this decision/vote must be unanimous. ---------- Anthony: IMO, this does not mean that every piece of code checked in most receive unanimous consent, but rather that agreeing on the person(s) to decide on and check in that code does. Adrian: And to decide on who to delegate duties to, we can still have a majority vote to select one person, but then submit them to the partners for final approval. It would work very much like the Australian and British parliamentary system where a bill must be passed by two houses of parliament. (The american equivalent is congress to president, but with a lot of presidents). I think we can make this work. Alain: A majority would be sufficient for me, in this case. ---------- Someone: I just don't see how you can reconcile the two statements: either every partner has a veto on everything or some actions can be taken even if a partner objects... which is it? Alain: Your binary formulation almost sounds inevitable but there is a third alternative that comes to my mind upon reading this. There are 2 categories of issues in my view. (1) Fundamental issues that we cannot compromise on, or be out-voted on, and (2) the strategies, tactics, means, day-to-day stuff that we are not likely to always agree on but that leave the general framework intact. Alain: Category-1 issues are fundamental issues like "we are open-source" which should be enshrined in our partnership agreement and then be changeable if and only if the partners unanimously agree. A radical change from free and open to commercial and proprietary, for example, cannot be put to a majority vote. ---------- Someone: The action would be to delegate the power to certain person(s) who would retain that power under conditions so-and-so (probably 'so long as there is no objection from any partner'), and operate under procedures so-and-so, and unamity would be required on that delegation. Alain: Why is unanimity required in this case? Alain: What are we delegating? Allow a proxy to vote for us in our absence(s)? Where work is concerned, people contribute what they wish, in the manner that suits them. Partners are not bosses. ---------- >Partnership votes shall be conducted via e-mail. Alain: I for one have often suggested that it would be better if we used a Web-based voting form. More structured, easier to set up decisions with complex tradeoffs, etc. In time, perhaps other FreeCarders will wish this too. So lets not put such a tactical detail into our constitutive partnership agreement. >To assure authenticity, each partner is to include >their date of birth and mother's maiden name as >evidence of their identity. Alain: The spoofer probably knows this information too, so this would not be a very reliable authentification procedure. PGP is probably the best we can do without going overboard on this tactical detail. Furthermore, privacy, encryption and authentification should only be required in special cases. Why don't we vote in the open and perhaps even assume that no one will steal our vote. How likely is it that someone will spoof us, given that there is no money involved? >In the event a vote is given without such confirming >information that vote shall not be deemed as valid. >In such case it shall be interpreted that the partner >has not voted. However that partner shall be free to >rectify their vote, by resubmitting their message with >the proper identifying information. Alain: We want to remain as flexible as possible. Uli: Rob, you're mixing up partners and associates. There are partner-level-decisions and associate-level-decisions. Partner-level must be unanimous, while associate-level can be majority. Alain: I substantially agree with this formulation, except to say that partner-level decisions don't necessarily have to be unanimous. Only the really fundamental issues require unanimity. However, given the probable difficulties of evaluating what is fundamental versus what is not, I might have to accept your formulation after all. Uli: If an associate-level decision touches the realm of the partner-level, partners should be able to veto it ... if it includes possibly changing the license, it becomes partner-level. Alain: Agreed. Uli: ... What code is to be used, is usually associate-level... Alain: It depends, I say. High-level design decisions must be adhered to when coding stuff, at least at the API level of abstraction. Adrian: I'm not suggesting that we should change anything of course, lets see how things work with unanimity first. Rob Cozens: There is a problem with the "lets see how things work first" approach. Alain: I have to agree with Rob on this one. We need to look ahead a little to avoid the mistakes that we can. And we need to do it now, while we are still a small humble group that gets along quite well. __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://messenger.yahoo.com
