[squeak-dev] More Candidate Questions

Ken G. Brown kbrown at mac.com
Wed Mar 10 20:05:14 UTC 2010


At 5:33 PM +0100 3/10/10, Bert Freudenberg apparently wrote:
>On 10.03.2010, at 14:47, Ken G. Brown wrote:
>>
>> At 10:58 AM +0100 3/10/10, Bert Freudenberg apparently wrote:
>>>
>>> Ken - I'm an engineer. Not a politician, not even a manager. Squeak to me has much more to do with friendship than politics. I'm not running for the board to gain power, but because friends help each other out, and in my mind the more experienced should take a larger burden.
>>>
>>> If you're looking for a politician, do not vote for me.
>>>
>>> - Bert -
>>
>> I too am an engineer and actually have almost zero interest in politics, so I think Colin is completely off the mark with respect to my intentions. The reason I asked my questions was in the hope that Candidates would respond in a way that I could determine who I wished to vote for. If this is politics though, I guess then I'm guilty.
>>
>>>
>> From this engineer's point of view, I don't think the way the Squeak Oversight Board (SOB) works is engineered very well at the moment, and I have seen ample experimental evidence that shows that.
>>
>> I want to see people on the board who are interested in engineering a solid SOB with clear and transparent-to-the-community 'Rules of Governance' or 'Constitution'. I think of this as the well defined and published-for-all-to see, API for the SOB with a good set of tests and checks and balances as well. This would hopefully ensure that next year's SOB would work the same or better than last year's, independent of the individual members at the time.
>>
>> If the SOB were a piece of software you were designing, I don't think you would preferentially make it a spaghetti-coded black box that was allowed to randomly do whatever it happened to feel like at any particular moment when you give it some inputs, and with no confidence that the next time those same inputs are given, that the results will be the same. I would also like to be able to easily look inside at any time to see how things are implemented, see how things are going and have been going. eg. financial accounts, minutes of the meetings. I would like to see a well engineered SOB built for the future with the best principles, in 'the best possible way'. I don't want to see the SOB built from the point of view of 'the simplest thing that could possibly work' and have to be redone every year.
>>
>> You may have noted Ken Causey's recent email in response to Gary Dunn <http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146122.html>. It seems that others are also unclear about the way the SOB works, even Candidates who will have to deal with it.
>>
>> If you or any other Candidates are for a well engineered SOB built for the future, while minimizing politics and legal mumbo jumbo, then my votes are for you.
>>
>> Ken G. Brown
>
>Now that sounds a lot more friendly. Thanks for putting it in terms I can understand ;)

Hey, I'm a friendly guy! :) With a good heart. Please take what I say in the best possible way.
My intentions are only positive for the Squeak community overall.

>
>The role and definition of the board is slowly evolving. We did not have anything like it for most of Squeak's history, though there were kings, dark ages, and self-declared dictators [1].
>
>Electing that gang of seven every year since 2006 somehow has worked out, even without explicit rules. Maybe joining the SFC enables us to evolve to something a bit more organized. E.g., the idea for a more explicit membership model that Craig listed in his campaign statement, I like that. In fact I brought that up as a possible model because I'm involved with SugarLabs, too [2]. We also borrowed the term "oversight board" from SugarLabs this year.

I haven't looked into the way SugarLabs is set up. Maybe that would be good. Hopefully the SOB can make a good decision with respect to going that way.

>As for a "constitution", I don't see how rigid rules or any other radical change (as demanded by some) would be helpful, nor find many supporters. The best we could hope for IMHO is putting the current practice in writing (though even that would be hard), and then gradually improving on that.

This would appear to me to be worth pursuing. Maybe Andreas's list of 'Release Tasks' <http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146246.html> could be put in there in a sub-heading.
And of course, how the SOB relates to the release team in particular, and teams in general would be good for all to see.


> Having it written down would be a Good Thing, in particular for newcomers, as long as it is not written in stone. But that would be impractical anyway ;)
>
>OTOH if indeed someone could come up with a "well engineered SOB" (assuming elegance and simplicity is even possible when designing group processes) I'd be happy to support that.

I think almost anything is better than the current situation as far as documenting what the SOB is, does, and how it is intended to operate.

Ken G. Brown

>- Bert -
>
>[1] Great summary by Göran: http://news.squeak.org/2007/06/30/squeak-tale/
>
>[2] http://wiki.sugarlabs.org/go/Sugar_Labs/Members




More information about the Squeak-dev mailing list