Fellow Squeakers!
(This is a LONG post, but VERY important so please read it!)
Now the group of people referenced earlier as the Squeak "board" has
come up with a mission statement and it is included below. First let us
give you all a quick background.
Background
==============
At OOPSLA this month Michael Rueger (being the only SqC representative present) talked with Göran Hultgren and others about forming something he coined a "board". The idea was to come up with a group of people that could essentially "take over" the responsibilities of SqC, especially taking care of releases and the update stream.
Since Göran Hultgren, Ned Konz and Doug Way have been quite active on the list recently - especially regarding SqueakMap but also other things he asked us if we would be interested in forming this little "group". We said yes. Then we were joined by Tim Rowledge, Craig Latta and Daniel Vainsencher so we are now 6.
Since I (Göran) had somehow ended up running around and talking to people about what this "board" is and what we should do, I also ended up being responsible for making it a reality. We thought that it would be good if we first came up with some form of "mission statement" about what it is we want to do and how. We also agreed that this little launch process would be best held off the list.
After we got home from OOPSLA we have been sending quite a lot of email around trying to create agreement on this little "mission statement". It has not been particularly hard actually!
First of all, since Squeak is much about having fun some of us noticed that calling this entity the "board" sounds profoundly boring, gives the wrong impression (dictatorship) and is simply not in the Squeak spirit of naming things. :-)
We have the Harvesters - which is a very good name. And we recently coined the Croqueteers for those of us typically getting lost in the enchanting world of Croquet. Cees de Groot deftly countered and said that the Mouseketeers would be a good name instead of the "board". But that could become a problem since it trademarked. We have been throwing "cool names" at each other but in order for this statement to get out we will let the community help us with this.
We want a name that is much more in the Squeakish spirit and somehow reflects our values and duties described below etc. After all, OpenSource is meant to be fun - not formal and boring!
Here we go - the mission statement for the... well, ok - my best shot will have to do for this statement - "The Squeak Guides" (formerly known as the "board") :-) :
Values of the Squeak Guides
================================
This was something Daniel Vainsencher brought up, and it is important. These are the values we stand by:
1. We want to encourage participation and cooperation by Squeakers of all levels.
2. We want to make Squeak viable in the longer term, which includes avoiding unneeded forks.
3. We want to grow the Squeak community and increase Squeak's visibility.
With these values follow things like openness, willingness to delegate and trust Squeakers to take care of parts of Squeak, making sure that Squeak moves in the direction of flexibility to avoid forks etc. Of course there are other values too but these three are quite important to note.
Duties of the Guides
========================
We have identified 3 basic duties of the Guides:
1. The Guides make sure that decisions are made when the community needs to make them. This doesn't mean that we make the actual decisions - they are as always mostly taken informally on the mailinglist(s), but the Guides should listen carefully, participate and act a bit like a "chairman" in a meeting making sure that decisions are made in the end and that they are recorded somewhere. This is something we have been missing lately when SqC has been more or less (cough) totally silent on the list - but hey, Croquet makes us forgive them, right? ;-)
2. The Guides take care of the "base image", and that translates currently to the update stream. Even though we are in this time and day changing how we manage Squeak packages and what the base image actually IS (pretty soon it may partly turn into a bunch of packages), this will still be an activity that needs to be taken care of regardless of how it is structured technically. We still all want to have a solid base to stand on.
3. The Guides coordinate our efforts in the community. When we identified this duty we mostly talked about package coordination, especially when it comes to breaking out stuff from the image. But we think this is actually a larger problem - the Guides should act as a coordination point for all efforts in the community that needs coordination - it is more of a service to the community. For example, if someone steps up and says "I would like to break out Celeste and be the maintainer for Celeste.", then if he coordinates this with the Guides it will be noted and we make sure that we don't end up with duplicated efforts and confusion about who is responsible for what. Coordination of course also has esepcially to do with outreach and publicity efforts, including press releases and release announcements.
If you look again at the above, the Guides don't really have much more "power" than anyone else - we just provide these three services to the community. Well, of course being a Guide might give you some form of "informal leverage" but not formally. ;-)
Another important change compared to how SqC worked is that the Guides is not responsible for creating the new additions to Squeak, as SqC seemed to be. And perhaps more importantly - our own work shouldn't automatically be included in the distribution image - we need to go through the same process as everybody else.
How do the Guides work
============================
With this post to the squeak-dev list we are officially started. But it will of course take a little while for us to find our roles etc. A few simple things are already decided though:
1. From now on the Squeakfoundation mailinglist will be used for essentially all work within the Guides. The idea here is that we work "in the open". If someone wants to follow what we do, just read that mailinglist - no secret handshakes and magic here! And if there is stuff that really involves the community it will be cross posted to squeak-dev etc. The Guides don't use private email for this work - unless it for some reason feels like the appropriate thing - but that would be the rare exception to the rule (and I have no good examples to give off the top of my head). Possibly the squeakfoundation list will be kept readonly, we will see.
2. The Guides rotate. This needs to be clear from the start. We aren't simply replacing SqC with another similar entity. The Guides work inside the community and not outside of it. Typically you would be a guide for 6-24 months (?) and then you sign off for someone else to fill your place. Of course we should figure out how this is handled in practice so that it's something natural and smooth - perhaps some kind of apprentice model can be used. Signing off is probably often due to changed personal situation and there should be no hard feelings if someone needs to sign off "prematurely".
Note: Since we rotate it isn't that crucial exactly who we are because we will not really be "dictating" decisions, the decisions will still be "made" through discussions on the list. We think and hope this will work - and if it doesn't then we can adapt and change later.
3. Duties number 1 and 3 above typically involve recording stuff. For starters we use what we have - the Swikis (minnow and squeakfoundation) and SqueakMap.
4. Duty number 2 is of course the "biggie" in some sense. As we are all aware the Harvesting process has been limping and it hasn't been clear why or why not a fix or enhancement gets accepted. Now with SqueakMap and a more package centric view the base rules are also changing - as Daniel has pointed out the stream should from now on mostly stick to removing constraints and not adding features. It's all about improving the Squeak "base" and we should always ask ourselves "Can this be in a package outside the image instead?".
In the beginning the base image is large but as we cut it down the update stream will hopefully get "smaller and smaller" as responsibilites are distributed among us in the community as packages. At the modules discussion people said they where longing for updates that actually *removed* stuff instead of adding. :-)
We also discussed how the "managing the update stream process" can be changed. One vision in this area is to have a tool much like "SM Package Loader" which shows everything lined up for review. To be able to look at the submissions, easily file them in, browse them and also see their current state in the acceptance process would be very helpful. And when the "reviewers" (which is not constrained to the Guides) put their approval mark on an update and an update reach say 3 approvals then it is automatically moved over to the final "queue" going into the image.
One single person should deal with that queue, reordering if necessary and testing the updates in a clean image. That same person also pushes the final button and posts the typical "updates email" to the list with exlanation on the updates. In essence this would remove all that "Hey, why isn't my enhancement in the updates?" stuff because everybody can just fire up the update stream tool and take a look.
Note though that this was a vision. Someone needs to implement such a tool first, but since we have Doug Way aboard as a Guide - the primary Harvester - it doesn't seem to be an impossible task.
The near future
===================
What will happen soon? Below is a sketch to give you some ideas.
Currently we have 3.2 which is frozen at update 4957 and acts like a branch point between 3.2.1 (which is the maintenance branch of 3.2 and will probably soon include SqueakMap) and 3.4alpha. We are aming at a short alpha period for 3.4 and to finalize it before christmas.
We do not want to change things just for the sake of change - there needs to be a need first! For example, Scott Wallace can continue his excellent work on managing the mechanics of the update stream (if he is willing of course - he has been doing a brilliant job), and Bruce O'Neel can continue his excellent work on uploading images/VMs to the ftp site, etc. But at the same time we will start looking at how to manage the update stream in a more community driven way with better tools.
The Guides will focus on making sure things get done - not doing it ourselves. :-) The more work we can distribute among ourselves in the community the better. And note that this means trusting people for real. This is important - people grow with their responsibilities, and it isn't much fun doing something if you are not trusted. This means that if you think there is something YOU would like to take responsibility for - raise your hand on the mailinglist and we will make sure you will get your chance!
One thing we will probably start with immediately is formulating a list with priorities of what existing fixes/cleanups we would like to focus on first in the image. This will of course be discussed on the list, stay tuned for that thread to start. Daniel is really itching in this area so he will probably be the one that guides that process. :-)
We will also start the big work with coordinating the transition over into "package land" using SqueakMap and other tools. Exactly how we will do this will be worked out in the near future, but I (Göran) will probably keep my focus entirely on SqueakMap and the upcoming essential mechanisms to make this a reality (versions and dependencies etc).
We are also aware that Dan Ingalls wants to start tackling the eternal "minimal kernel image holy graal" and since he has already done it more or less - it sounds like he might actually pull it off! This means that the current ongoing move into "package land" will be done on two fronts - from the bottom and up led by Dan and from the top down by... the community! :-)
Last word
===========
Finally, writing this statement and getting it somewhat right was quite a bit of work - in order to meet the 48 hour deadline I (Göran) had to take a few chances... I am 9 hours ahead of the US westcoast which means that it's hard to get feedback. My fellow guides will just have to speak up if my final tweaks in this document got wrong. :-)
I hope you are all aware of that we need to evolve this thing - nothing is "carved in stone". But it is our hope that you all think this sounds like a good start and that this direction of the community is something new and good.
So... let's get to work!
regards,
Göran, Doug, Ned, Daniel, Craig, Tim
