Elections

elections@lists.squeakfoundation.org

128 discussions

Just to make sure we all agree on the goal
by Ken Causey 30 Dec '05

30 Dec '05

I'm subscribed to this list, but as a current Board member it doesn't seem like a good idea for me to actively contribute to this process. However I do want to me sure we are all clear on one thing, the primary (at least first) goal: This team's first and foremost goal is to design a process and policy on how new Squeak Foundation board member's are selected/elected to replace retiring members. I hope we all agree on that. Once that goal is more or less covered then I'm quite happy for this group to pursue other goals. But that is the one thing that is needed soonest. Ken

1 0

RE: [Elections] change the name?
by Peter Crowther 29 Dec '05

29 Dec '05

> From: [...] Lex Spoon > If people prefer to keep the current > subgroup in power and then go from there, then how about > simply renaming > the group from "Squeak" to something like "Islanders Squeak"? Speaking personally... I'm here to try to keep one community rather than several - to the extent that there still *is* one community; to a large extent it's de-facto forked. That means I'm trying to exert pressure both ways. I want SqF to represent the broader body of Squeak users, including me for what use I make of the system. That means (to me) ensuring that SqF is representative of the broader body, which it isn't at present. The alternative is to accept the fork, at which point I'll leave this mailing list and head over to Craig Latta's side of the world. > Anyway, any organization called simply "Squeak" or "the Squeak > Foundation" should surely strive for broad membership from existing > Squeak enthusiasts. If that's to be the name, then be prepared for a > harder problem.... Quite. - Peter

1 0

Re: [Elections] Re: Who votes? how does voting work?
by Lex Spoon 29 Dec '05

29 Dec '05

Daniel Vainsencher <daniel.vainsencher(a)gmail.com> wrote: > Like I said the last time you posted this list, the barrier against > these people under SqP is practically non-existent. Just make them > users, certify them, and send them their password. With about 20 minutes > of your time, the problem is solved. Let me know, I'll certify people I > know from that list. You describe here a theoretical way to define the community using Squeak People. It remains theoretical, though. Squeak People has had over a year in action now and has yet to provide any reputation at all for the majority of people I have collaborated with on Squeak projects. Most dramatically, it doesn't even give a reputation to the guy who formed the project. How much tweaking will it require? How much work will people have to put into making reputation designations? Further, why is the reputation system approach preferable, even if we can tweak it up enough? Membership and rank will fluctuate as the reputation flows shift around. If the system is anything like the current algorithm, then applicants will get their rank depending on a 20 off-the-cuff reviews instead of 1-3 careful ones. And that's at best -- it is still theoretical whether a reputation system will work even to give cursory rankings that are in the ball park. Also, there is still no answer on a critical question for SqP's algorithm: who gets the initial root reputations that then flow through the system? I guess that, right now, Cees has simply hand picked some people? > On who proposes referenda, a seconding mechanism would be a fine > alternative. So one person proposes, one seconds? Proposer gets to set > the date? > > And a critical matter - do we need a lower bound on voter turnabout for > a proposal to pass? if not, we probably want a lower bound on voting time. A mere seconding might be enough, but it's impossible to say until we try. An additional requirement that seems helpful is to require d weeks of discussion (2 weeks? 4 weeks?) before a proposal can be submitted for real. Assuming full members play nice with each other (and in the end, we have to make that assumption to some extent!), a preliminary fielding on a mailing list would frequently make it pretty clear whether it is worth a vote. Regarding time, a minimum time seems important--one month, perhaps? Referenda are fundamentally slow; it's not a mechanism for fast turnaround, anyway.... -Lex

1 0

5-item list for initial membership
by Lex Spoon 27 Dec '05

27 Dec '05

I propose here some tweaks to the list I posted earlier, in response to comments that have been made and to having thought on it some more. First, the email-list posting route would require 3 posts, not just 1, and posts to any world-wide Squeak list would count. In particular, squeakland's list would count. Also, I agree with Daniel that Squeak Source should count as a vehicle for posting 1000 lines of code. So the new list would be: 1 posted code to a Squeak bug tracker 2 posted 3 times to squeak lists, including squeak-dev and squeakland 3 made 1000 lines of Squeak code publically available, including [ENH]'s, SqueakMap, and Package Universes, and SqueakSource 4 assembled an original etoy with at least 3 lines of script in it 5 published a paper based on Squeak 6 gave a talk to 5+ people based on Squeak I believe that making an etoy should not be considered hacking one's mebership. Anyone who cares to learn how the tiling system works and then posts something is a real Squeaker, doesn't it seem? I've added the word "original" to the list now, to prevent people from copying. Also, maybe we should require that, for all of these items, only *past* works count? This is for the initial membership, you know.... Second, after processing the above list, there could be a followup round where existing members can add new members. We could say it requires 2 "signatures" to include a new member in this way. The goal is that, so long as the 5-item list includes at least 2 people from any segment of the Squeak community, that segment can pull the rest of the segment in. This would be a one-time event, just to get started. It seems good to err, for this initial list, towards having too many people rather than too few. Finally, all these membership computations should be recorded publically somewhere on squeak.org. If someone does something fishy, there should be a record of it. Just picture it -- wouldn't it be a little weird for some Election Team to pop up and say "okay, here's who's in and who's out" without any explanation? Thoughts? -Lex

1 0

Re: [Elections] Election Team Kickoff
by Lex Spoon 23 Dec '05

23 Dec '05

As I posted earlier [1], I don't consider the current "organization" to be legitimate at all. People who have watched this situation over the years might notice that the "guides" were supposed to be temporary, and that the "castaways" were supposed to be temporary... but nowadays, the "coordinators" now seem to consider themselves enshrined by default? I warned the castaways that this would happen, that they themselves would come to think of themselves as leaders given a continuing power vacuum. Despite declarations that they do not actually consider themselves self-styled leaders, etc., [2], things are the same 10 months later. The castaways web site still lists the original "all your base belong to us" email as their mission statement. I would suggest the Debian Constitution [3] as a great starting point for the Squeak community. It has worked well for them, and they have a similar organization to the Squeak group. Here's an article I wrote earlier on the idea, back when I was burning 5-10 hours per week to help with Squeak organization issues (time, I fear, I no longer can contribute): http://people.squeakfoundation.org/article/45.html The first change to think about is to elect leaders every year or maybe two, without term limits (open source volunteering is inherently limited anyway!). I also like the idea we've explored of having a release manager, and would further suggest that the release manager gets elected, too. Elections provide accountability. Overall, the current setup is illegitimate and is ill-advised anyway, despite the quality of the individuals involved. For a healthy community, there's no better time than the present to improve our organization. -Lex [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/088316… [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/088335… [3] http://www.debian.org/devel/constitution

2 2

RE: [Elections] Election Team Kickoff
by Peter Crowther 30 Nov '05

30 Nov '05

> From: [...] Brent Vukmer > If one of the current coordinators stepped down in > January, how do you think we should go about building > a list of candidates, and choosing one? Candidates require at least the following attributes: - Willing to stand for co-ordinator; - Have the trust of the other co-ordinators, at least sufficiently to be approved if elected; - Have the trust of the Squeak community, at least sufficiently to keep the co-ordinators as a whole trusted by the community. Nice-to-haves include: - Willing to put the effort in once elected; - Know something about Squeak. Given that gaps in the ranks can happen relatively quickly, given how mercurial some folks on the list can be, the Team should probably have some candidates that it has already sounded out: would they be willing to stand, and would the co-ordinators be willing to accept them? I'd suggest keeping two people as 'reserves' - this is a secondary activity for almost everyone, so one might be unavailable at a crucial time. > I'd like to hear your thoughts about what we might use from the Debian and Apache governance methods. I'm far less familiar with these than I should be. Anyone got some pointers to documents? - Peter, de-lurking

1 0

Election Team Kickoff
by Brent Vukmer 30 Nov '05

30 Nov '05

Welcome everybody! The Election Team is currently: Benjamin Pollack Lex Spoon Masashi Umewaza Daniel Vainsencher I have a few other folks I've asked to join the team, but I think it's time to kick off team activities. So, let's start figuring out how new guides/coordinators should be chosen. In the short term, that means figuring out how this team should choose candidates. If one of the current coordinators stepped down in January, how do you think we should go about building a list of candidates, and choosing one? Keep in mind that the existing coordinators want to approve the candidate we choose. Longer term, we need to come up with a means for the community to choose candidates. I'd like to hear your thoughts about what we might use from the Debian and Apache governance methods. Thanks, Brent

1 1

Election Team Kickoff
by Brent Vukmer 30 Nov '05

30 Nov '05

So, let's start figuring out how new guides/coordinators should be chosen. In the short term, that means figuring out how the Election Team should choose candidates. If one of the current coordinators stepped down in January, how do you think we should go about building a list of candidates, and choosing one? Keep in mind that the existing coordinators want to approve the candidate we choose. Longer term, we need to come up with a means for the community to choose candidates. I'd like to hear your thoughts about what we might use from the Debian and Apache governance methods. Thanks, Brent

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Elections