Elections January 2006

elections@lists.squeakfoundation.org

11 participants
36 discussions

RE: [Elections] Checking in / next steps
by Peter Crowther 11 Jan '06

11 Jan '06

[Not a great email to read. Long and political, and I apologise for that. However, I think there are the seeds for several relevant discussions in here, as well as my usual musings and general dross.] > From: [...] Daniel Vainsencher > Many are stating it, but do you (or someone else) mind actually > *arguing* why the elections are an urgent priority for this team? Let's try the following as straw men. What do folks think? 1) The current leaders said they'd allow elections on a specified date. Those with integrity will at least wish to do what they said they'd do. Any without such integrity should be removed from office before their lack of integrity can do further damage. 2) We have a community that is fragmented and fragmenting further. I conjecture that: one of the reasons for this is the way in which the current leaders came into power; a second is the way that some subset of them have chosen to use that power without much consultation (yes, I will state event(s) and name(s) that I consider to fall into this category if you wish to enquire further); and still another is that the current leaders appear to be unworried about the fragmentation, which will tend to accelerate that fragmentation. Every day this situation remains unaddressed is another day of the community slowly fragmenting. We don't have the person-power for that! 3) Some (at least two) leaders wish to stand down. They signed up for a tour of duty of a specific length; we should not prolong that. > As I see it, Squeak has managed reasonably well with unelected > semi-officials. Speaking personally, I disagree - see 2 above. However, I'm aware that my opinions on this are contentious. > there are several reasons to invest time (a couple > of months, > not a year) in having smooth tools for voting (including on > elections): > 1. If its smoother, more people will participate. Relevant if the opinions of the lazier participants would change the outcome; irrelevant if they wouldn't. Do we have any feel for how smooth something has to be in order to get an acceptable level of participation? For that matter, what *is* an acceptable level of participation? 100% is unrealistic, unfortunately. We see somewhat under 50% in local elections in the UK... > 2. A good system (especially in the sense of using good tallying > algorithm) will be more trusted by people, therefore making any > elections done be more meaningful. Can we firm up what 'good' would mean, in the sense of both system and algorithm? To me, a good algorithm: - discards the fewest votes in reaching its conclusions; - has known and preferably well-described properties to which we can refer; - May prefer a set of candidates for which most people vote (Condorcet does this) or may prefer candidates with a wide constituency (STV tends to do this). We need to decide which property we'd prefer. A good system: - is automated, not manual; - is demonstrably independent of any candidate in the election. > 3. A fully automated system will allow any voter in the community to > raise issues, rather than just the officials that can do the required > manual system in a non-automated system. It will also have to allow automated definition of who forms the community, otherwise it isn't fully automated. This is, I think, the source of Lex's and my differing points of view; we have different opinions about whether, and how, this can be automated. > 4. Whatever system we come up with should be tested in production on > non-critical decisions (web site layout, whatever) before it > is used to > decide elections that give people official positions that we are not > used to having in the community. Yes. To me, this indicates that an off-the-shelf system should be preferred, as such a system would give more time for such tests and would also come with certain assuances that others have tested it in production. > 5. An election is a part in a system. What are we electing > people for? > what decisions can the elected make beyond others? for how > long are they > elected? holding an election without considering these questions is > meaningless. We will need discussions of this on squeak-dev (even if > guided by some proposals from this team), and we will then need to > decide on one of them. > > This is the most important point - we need to make the whole > system one > that the community is happy with, not just the list of > people. This will > not happen on a deadline just because that's what fits some > preconceived plan. Indeed. However, if this is part of our [your - I have recently been reminded that I am not a member of the team] remit then this team is at best poorly named and badly under-resourced. I'm going for an initial guess of 'the current board structure, but candidates may run with the express intention of changing that structure', 'as now' and 'I'll walk out of the community if it's longer than a year, and things are moving so fast that I'd much prefer to see an interim government of 6 months' respectively as my own answers to the above questions. I strongly suspect that we'll see candidates coming forward whose sole aim in standing is to try to change the way Squeak is controlled; I would argue that any system we put in place should allow change in this way until we get the arrow pointing in roughly the right direction. Once we know roughly what's wanted, we can start to firm up the structure*. > You're right - our goal is not building tools. And in my opinion, our > goal is also not "to have an election". Our goal should be > social, and about involving the community. ... in what? Tea and cakes and polite agreement that The World Isn't What It Should Be and that Something Should Be Done, and then everyone toddle off home with the vague unease that maybe something more should have happened just then? We can stop this and go home tomorrow by saying "we have decided how to bootstrap the election process. Here you are, folks. We are bootstrapping it by mailing squeak-dev and stating that we have decided that the wider community should come up with the details of Squeak's governance. There you go, folks, you can take it from here, we've finished." We'd be laughed out of court. I agree that any system we construct will require ratification by the community. How does one do that, though? We have no defined process for it; we need to bootstrap the process. We could use the system to ratify itself, but that has dangers - at one extreme, we pick (say) Alan and say "You have command. All you need to do is ratify it by saying so, because you have command." At another extreme, we stagger around forever trying to work out a process for ratifying the pocess for ratifying the process for ... for ratifying the process for deciding the decision-making system. I suspect our initial choice of system, within a wide range of options, will be a non-event. The community will get a system that works at somewhere between 80% and 90% of what it could do; and that will be good enough for the community to use that system to decide to move to a system that is more closely aligned to its wishes. People will simply accept it as an initial system, as it's a step forward from where we are now. If we choose to set the system in tablets of stone and hand them down from on high... that's a different matter. Squeak attracts a very divergent community by its nature; imposing a mechanism and asserting that it will be fixed for all time will give us the grandmother of all arguments on the main list. Let's do something that will work well enough for a period. [Aside: have you ever played Nomic (http://www.earlham.edu/~peters/nomic.htm)? If not, you may wish to dig out a set of the rules (http://www.earlham.edu/~peters/writing/nomic.htm#initial%20set) and read them. Most instructional for a debate of this kind.] - Peter * But then, I'm somewhere between anarchist and individualist at heart - I maintain that societies are aggregates of individuals and that it is the individuals that define the way in which society reacts rather than the other way round. The Squeak community appears to exhibit this behaviour more strongly than many other communities, I suspect because it attracts intelligent and individualistic people to its exquisite personal computing environment.

2 1

RE: [Elections] A simple SqF board elections solution using SqP
by Peter Crowther 09 Jan '06

09 Jan '06

> From: [...] Cees De Groot > Is Condorcet the way to go? I looked a bit on Wikipedia, Condorcet > seems to be for electing a single person as far as I could tell... There are variants for electing multiple people. All require a completion rule. http://www.cs.cornell.edu/andru/civs.html allows a choice, including its own deterministic rules; we should pick a rule ahead of time. > I have setup a project called Agora (gosh what an original name) > that's basically waiting for the definitive decision on the voting > system to use. It'll be hardcoded for this election, to make > everything easier :) I'd love to. However, I wonder whether we outsource this one, in the interests of getting reliable software in the short period we have? > BTW - there's another little task for this team - the candidate list > still has two vacancies. And in order to let the voting system make > any sense, it'd be good to have more candidates than seats, of > course... In a previous email, I suggested gathering candidates from the community; candidates would require separate nomination and seconding. This could be done in parallel with voter registration, if we were short of time; nominations and secondings that turned out to be from non-voters would be excluded when voter registration had finished (but I'd suggest candidate registration continues a little longer so that candidates who suffer from this have the option to find alternatives). Again, we could do this via a Web site, or we could do it via an archived mailing list. For this election, the archived mailing list may be easier to set up... - Peter

1 0

RE: [Elections] A simple SqF board elections solution using SqP
by Peter Crowther 09 Jan '06

09 Jan '06

[NB there is a suggestion for a Web site that may make our lives easier at the bottom of this message] > From: [...] Ken Causey > I'd like to float this as a solution to the quickly > approaching vote for the 2006-2007 Squeak Foundation Board. I note that. Comments inline. Once again, apologies for lateness. > 1. Solicit for people interested in sitting for the 2006-2007 SqF > board. This would be made up of 2005-2006 board members still > interested in serving and any new prospects. Exactly how you (the > Elections team) handle these selection of new prospects is up to you. We need to decide this pronto. I propose that we allow anyone who can get nominated and seconded to stand. We need three pieces of information then: the agreement of the candidate, the nomination from the nominator, and the second from the seconder. I'd require the existing Board members to go through the same process, i.e. they are *not* automatically included in the election. I'd also suggest that any individual may only nominate or second one candidate, but that may be rather contentious. > We specify a SqP rank > (apprentice or journeyman, this is open to debate) that is > eligible for voting. Use of SqP rank is contentious. I don't think we have any way of resolving that contention and achieving consensus. I also think that the established mechanism for doing that (kick the decision upstairs) is inappropriate in this case. I genuinely have no idea how we proceed past this impasse. > However I think even if the 'process' is done > outside of public > view that exact data used is public and anyone that cares to make a > snapshot of the people page at midnight GMT on the 7th can verify the > data generated. We'd need to snapshot the 'raw' ratings - who rates who as what - to ensure transparency, but yes. > b. Each listed member is given a fraction value to designate his or > her desirability to the voter. The top listed candiate is > given a value > of 10/10 or 1. The second listed candidate is given a value of 9/10, > the third 8/10, the fourth 7/10, and so on until the 10th listed > candidate is given the value of 1/10. If the voter does not list all > candidates then the listed candidates are given their > appropriate values > as above and all other non-listed candidates are assumed to > have a value > of 0. > > c. A running count is maintained for each candidate as the > votes are > processed summing the fraction value in each vote for that candidate. > > d. The 7 board members are selected by taking the 7 candidates with > the highest sums. A comment is posted as quickly as possible on the > 15th of february with the total sum for each candidate and > listing the 7 > new board members. This is a very uncommon voting mechanism. Can we use something more common? Variants of Condorcet, proposed by Lex and used by Debian, appear to be appropriate for the election of multiple candidates to posts; we could use something like http://www.cs.cornell.edu/andru/civs.html to run our election for us if we could identify our list of voters. > This mechanism is completely transparent and can be rechecked > by anyone at any time to verify the results. Indeed. For recording and counting votes, however, I'd settle for a system where the system's owner has no interest in tampering with the result. The Web site referred to above has this property. - Peter

2 1

RE: [Elections] A simple SqF board elections solution using SqP
by Peter Crowther 09 Jan '06

09 Jan '06

> From: [...] Lex Spoon > Any organization has some members with clout who can use that > more than the formal > bylaws would indicate. Going with the reputation approach > means that this not only happens, but is primary. Indeed. And we're sending this email through a server maintained by one of those members with clout, which also hosts the main mailing list, the Web site and a bunch of other stuff. If we're going for the whole 'but I don't trust the roots' thing, shouldn't we also angle to move all of the community's resources to neutral hosting? And who should have access to those? And so on. This may seem similar to a 'slippery slope' argument (http://www.nizkor.org/features/fallacies/ - a generally useful resource). I'm using it to illustrate a point that we probably have to trust some people, all of the time, with some responsibilities. In the case of the current reputation system, we only need one unbiased root (out of four at present) to ensure that relevant accounts are certified. By contrast, any biased root or (transitively) any of the people they trust, down to the limits of the system, can let in new relevant accounts. Speaking entirely personally, I'm willing to accept the risk of all of the present roots being biased. I consider the chances of systematic bias across all the roots to be low in practise; I consider the consequence if they are (a reduced number of people being trusted) to be acceptable *because* I would expect systematic bias to be noticed by the community and the alarm to be raised as a result. Thus far I've not seen (to my knowledge) signs of systematic bias, and I've not seen anyone raise the alarm that this *has* happened, merely that this *could* happen. Ultimately, I'm a pragmatist; I consider that "the best is the enemy of the good" and will settle for a system that merely has few flaws. By contrast, I consider that admitting voters by requiring them to fulfil objective criteria is brittle. The construction of the criteria is paramount. Pretty much whatever we do, I believe we're going to draw relatively broad distinctions with the criteria. As a result, we're going to get some false positive voters and some false negative non-voters if we just use the objective criteria. And if we add in a 'or anyone else the Voter Registration Sub-Committee deems eligible' clause as part of the criteria, then all the focus is on bias within that sub-committee. I believe that given typical human behaviour, this scheme has *more* flaws than using a reputation system - there are more points at which it can break. If we could draw up the criteria perfectly, I'd be happy with it; but I don't believe that we can do that within the time we have. All personal opinion; please consider it as such! My aim in this message has been to set out why I believe a reputation system is not perfect, but is less bad than a system of objective criteria. - Peter

1 0

RE: [Elections] Re: Who votes? how does voting work?
by Peter Crowther 08 Jan '06

08 Jan '06

> From: [...] Daniel Vainsencher > Sent: 01 January 2006 19:43 Daniel, what's the date on your machine? Is something off with its conversion to Gregorian somewhere? > It might not be good enough for money handling or legally > binding stuff, but it probably is for all kinds of decisions the > community is trying to make now. Quite. > Do you mind updating the minnow page to > reflect these requirements? Done; sorry for the delay. I've hacked with some headings, now that we have more content in there - sorry if that's an issue. > Here I don't quite understand your intention. Do you mean to > extend SqP itself? Ideally. > note that it is not Squeak, so some Squeakers won't hack it > directly. <shrug>. And? A system is a system is a system. I've CC'ed Cees into this. Cees, what's SqP written in and how easy is it (in your experience) to change? > Anyway, I think the first thing is to make sure we can live with the > initial requirements list, and then let move to > implementation. For that > I was going to ask on the Squeak list for volunteers, unless > one of you > wants to tackle it yourselves. In the case where someone else > is doing > it, there's no point in making too many implementation decisions now. I could do it quickly but not in Squeak, or in Squeak but slowly - I'm not sufficiently familiar with any of the Smalltalk Web frameworks to use them effectively. My day job is almost entirely Microsoft web application hacking (for my sins - but it pays the bills!) - Peter

4 6

RE: [Elections] Re: Who votes? how does voting work?
by Lex Spoon 07 Jan '06

07 Jan '06

> , then within a few weeks -- a > > month tops -- > > there would be a list of members that could be frozen as the initial > > set. This would be a list that everyone should feel good > > about, because > > the rules of joining are objective and because the membership > > applications are all handled publicly. > > (Having handled online elections on a MUD for many years) How does one > deal with the community of punks who decide to object to everything? If we have an objective list, then such objectors--should they turn up--just make idiots of themselves. I'm not talking about policy proposals. I'm talking, did this guy or didn't this guy post 1000 lines of code? The objective list of criteria is key for this approach. A nice side benefit is that the list becomes subject for discussion over time. For example, I've seen multiple discussions on Debian lists about people who intuitively seemed like Debian Developers--and that, without consideration, many people would have automatically opted in--but who, after discussion, everyone agreed did not meet the objective criteria for membership. If there's no list of criteria, then these discussions aren't as effective. You and I might agree on one list, while another person has different criteria.... On the flip side, there is a word for leaders promote into power whoever they feel like. It's practically the definition of corruption. It happens, but I don't see why people are eager to make it the primary process. > Who gets to review them and decide that they should be excluded from the > list of folks who may object? We ended up moving *away* from an > object-list approach for voting to pure positive voting No one. I made a typo -- I meant "objective list". My experience with Debian is that if the list is reasonably objective, then--after discussion--there is literally unanimous consent on whether new people meet the list or not. That's an organization with about 1000 members. > > Second, have people really thought about what it would be like to live > > under such a system? Membership would be granted and denied > > based on a > > dozen or more off-the-cuff reviews instead of 1-3 careful > > ones. That's > > a recipe for superficial decisions -- it will promote populists over > > quiet doers. > > Not necessarily. The algorithm used here merely determines whether the > reputation flows to an individual, not how strongly. Also, don't forget > the laws of large numbers. With a large community of reviewers rather > than a small community, the peers and admirers of such quiet doers would > typically ensure that they were included. Well, see above. I am talking about the quality of designations more than whether some people get left completely in the cold. Very productive quiet guys could doubtless get some kind of rank in a reputation system with casual reviews. However, almost certainly louder people will get promoted faster and higher. The opposite is the case when membership has objective "doing" criteria. > However, it's a lot of work for the committee, and it requires an > impartial committee. To turn round the 'who are the roots' question: > Who would you choose to form that committee, Lex? It doesn't matter. The current election team would be fine. Or the board could even designate the team. If there is any controversy over the decisions they make, then the system has failed. Experience with Debian suggests that these decisions are not controversial. What is controversial is what goes on the objective list. But that's unavoidable. At some point you have to decide who is in and who is out. I'd like that decision to be based on things like "the person uses Squeak" instead of things like "the person is approved by existing members". > > Is there any experience we can rely on for using reputation systems to > > define membership? Maybe some of the worries from the previous > > paragraph do not emerge in practice? > > I don't have enough experience myself to answer that. No one else has jumped in, either. The objective-list plus reviews approach is tried and true and frankly very boring. But isn't boring a good quality for bylaws? -Lex

1 0

Re: [Elections] A simple SqF board elections solution using SqP
by Lex Spoon 07 Jan '06

07 Jan '06

Ken Causey <ken(a)kencausey.com> wrote: > 2. On Feb 1 post an SqP article announcing the upcoming vote and clearly > stating the voting mechanism and requirements. We specify a SqP rank > (apprentice or journeyman, this is open to debate) Okay, guys.... I really don't understand why this is popular, unless it's because people are very used to thinking this way. You do realize that the algorithm is set up so that people at the roots get lots of control over membership, while people further away get very little? The system isn't set up to average all the designations. Instead, roots get lots of clout, and they can choose to pass on some of it to others. Any organization has some members with clout who can use that more than the formal bylaws would indicate. Going with the reputation approach means that this not only happens, but is primary. -Lex

2 1

RE: [Elections] Re: Who votes? how does voting work?
by Peter Crowther 07 Jan '06

07 Jan '06

[Long, and late. Sorry.] > From: [...] Lex Spoon > It is clear to everyone, I think, that the current set of > SqP-certified > people does not correspond to the set who should get to vote. The set is incomplete. So are the sets on that web-site or wiki over there --> that we're using to run the votes - in fact, they're even less complete, as that list isn't started yet. So SqP is further ahead than any other solution that's been proposed, because it has *some* content. > So we can't "just use SqP". SqP as it stands at what date, though? We will need to tell our constituency about any voting system, and we will need to give them time to register. I would hope that would generate a spate of registrations, no matter what system we use. > Before telling you my reservations, please remember that the > object-list > approach is about as KISS and as reliable as imaginable. Indeed. > Assuming everyone plays nice Always a dubious assumption in a community of any size. , then within a few weeks -- a > month tops -- > there would be a list of members that could be frozen as the initial > set. This would be a list that everyone should feel good > about, because > the rules of joining are objective and because the membership > applications are all handled publicly. (Having handled online elections on a MUD for many years) How does one deal with the community of punks who decide to object to everything? Who gets to review them and decide that they should be excluded from the list of folks who may object? We ended up moving *away* from an object-list approach for voting to pure positive voting, as the noise in the system was dealt with more effectively by that scheme. We also ended up shunning them as a a larger community, something that an automatic reputation system will tend to note without further intervention. > A big open question is who are the roots? Indeed. Cees quoted some names to me (not sure whether on-list, I can't find the email). They looked reasonable, and - key point - were not all folks who are themselves up for re-election. > What do the pro-repsystem people want to choose, here? I'd like a set of careful, gregarious, active people who don't regularly appear on the mailing list with axes to grind. There may be a trade-off there. Tim and Cees would be two of my top choices. Possibly Daniel. As a counter-example, I'm too far on the fringes and too often on one side of an argument to make a good root. > Second, have people really thought about what it would be like to live > under such a system? Membership would be granted and denied > based on a > dozen or more off-the-cuff reviews instead of 1-3 careful > ones. That's > a recipe for superficial decisions -- it will promote populists over > quiet doers. Not necessarily. The algorithm used here merely determines whether the reputation flows to an individual, not how strongly. Also, don't forget the laws of large numbers. With a large community of reviewers rather than a small community, the peers and admirers of such quiet doers would typically ensure that they were included. > Also, reviews would not be archived. People would not > have a place to post their *reason* for their certifications. I'd distinguish 'would not' from 'can not at present'. If such a system were to be moved into something that could be hacked about more easily, then it would be almost trivial to include a text box alongside the rating drop down, allowing the rater to state why they were rating as they were. I would in this case want an explicit 'deliberate no rating' value in the drop down, however, so that a person could elect to record why they were making no decision about a person. > And they > cannot post negative reviews at all, right now. Mmm. I'd love to see this, but it's difficult to see how this can be done in a graph-based reputation system. In particular, how do you defend against the punks who rate everyone negatively xcept their peer group? What positive rating does someone require before their negative feedback is noted? And in what order does one evaluate positives and negatives? > (Even if they could, > who would put their neck out to do it?) Me, for one. I'm honest like that. > On top of these, don't people > worry that a reputation system includes people who pester a lot of > members but excludes shier folks who do not want to do that? No. See above re law of large numbers. I worry much more that a system with a small number of reviewers will overlook people. > Issues aside, there is the question of practical experience. > Aside from > communities where people pay to join, or where membership is wide open > to all comers, practically every community I know of uses the > defense-before-committee approach. It is not perfect, but it seems to > work well, and it is something that people understand. In particular, > it handily addresses all of the issues in the previous paragraph. However, it's a lot of work for the committee, and it requires an impartial committee. To turn round the 'who are the roots' question: Who would you choose to form that committee, Lex? > Is > there any experience we can rely on for using reputation systems to > define membership? Maybe some of the worries from the previous > paragraph do not emerge in practice? I don't have enough experience myself to answer that. - Peter

1 0

A simple SqF board elections solution using SqP
by Ken Causey 04 Jan '06

04 Jan '06

I'd like to float this as a solution to the quickly approaching vote for the 2006-2007 Squeak Foundation Board. I would like to suggest that we try this more or less as is for the upcoming election and then consider it, based on that experience, as a model for future elections. I think that we can implement a one time (at least) election mechanism that if not secure is 'transparent' (a reference to a discussion of security vs. transparency in elections by Cees): 1. Solicit for people interested in sitting for the 2006-2007 SqF board. This would be made up of 2005-2006 board members still interested in serving and any new prospects. Exactly how you (the Elections team) handle these selection of new prospects is up to you. 2. On Feb 1 post an SqP article announcing the upcoming vote and clearly stating the voting mechanism and requirements. We specify a SqP rank (apprentice or journeyman, this is open to debate) that is eligible for voting. Announce that voting opens just after Midnight on Feb. 7th and that voting eligiblity (account and ranking) must be met by Midnight GMT of Feb 7th and that a comment to the article posted soon after Midnight on Feb 7th will open voting and that votes placed before that comment is posted will not count. 3. At Midnight GMT on Febuary 7th, Cees and/or I will use a script that more or less instaneously lists all members with a rank of the desired level (for voting) and we post a comment to the article listing all of these members. These members and ONLY these members will be eligible to each place one vote. I say Cees and/or I here because for the moment he and I are the only ones I know of with direct access to that server to be able to run such a script. Cees may know other people and/or may be willing to give someone else access to do that. It's his server and up to him. However I think even if the 'process' is done outside of public view that exact data used is public and anyone that cares to make a snapshot of the people page at midnight GMT on the 7th can verify the data generated. 4. Between the time this comment is posted at Midnight GMT of Feburary 14th all members listed as having voting rights can post a single comment indicating their preference of board members. The preference is specified by listing all available candidates in order of preference from highest to lowest. 5. After Midnight GMT of Feburary 15th someone (preferably more than one person) will count the votes using the following mechanism: For this discussion let's assume 10 candidates are available for the 7 board positions. a. Each vote is comprised of an ordered list of candidates in order of desirability by the voter. b. Each listed member is given a fraction value to designate his or her desirability to the voter. The top listed candiate is given a value of 10/10 or 1. The second listed candidate is given a value of 9/10, the third 8/10, the fourth 7/10, and so on until the 10th listed candidate is given the value of 1/10. If the voter does not list all candidates then the listed candidates are given their appropriate values as above and all other non-listed candidates are assumed to have a value of 0. c. A running count is maintained for each candidate as the votes are processed summing the fraction value in each vote for that candidate. d. The 7 board members are selected by taking the 7 candidates with the highest sums. A comment is posted as quickly as possible on the 15th of february with the total sum for each candidate and listing the 7 new board members. This mechanism is completely transparent and can be rechecked by anyone at any time to verify the results. Ken

1 0

bug tracker for registration
by Lex Spoon 04 Jan '06

04 Jan '06

A bug tracker would be a simple and effective technology for registration book keeping. Each "issue" on the tracker would be one applicant. The initial "bug report" would be a person requesting to be registered along with their reasoning for thinking they should be allowed. Followups would be people saying what they have verified, found to be insufficient, or (rarely) found to be false. Status of an issue would correspond to a person's registration status: open - the person is under consideration or dispute fixed/accepted - the person is a member and gets to vote rejected - the person is not allowed Someone who is still "open" by the time of the vote simply don't get a vote. Too bad. If you have been left open by accident, you think, then go pester people.... The power to move a registration from "open" to any other status should probably be limited to some sort of registration committee. The choice of registration committee doesn't matter very much, so long as we choose reasonably honest people. I can't think of anyone remotely Squeaky that I wouldn't trust in that role. Using Squeak People rank would be one fine way to start, as would letting the current board appoint a committee. Note that the registration committee does not have to do the real verification work if they don't want. They are simply the final arbiters. They can perfectly well defer judgement to other Squeakers they trust, just like with harvesting bugfixes. The effort level should be much lighter than bugfix reviewing. Applicants are obligated to make their case easy to read if they want to get a vote. Reviewers are welcome to ask for more info and then ignore any person that does not respond. Overall, this approach does not seem like too much work, and the results would be a list of members that is objective and widely accepted as a reasonable definition of the Squeak community. -Lex

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Elections January 2006