Squeak
Session
Links
Squeak Mailing Lists
Squeak By Example
SqueakPeople
Squeak Swiki
SqueakMap
SqueakSource
SqueakLand
SqueakVM
Seaside
Croquet
Spoon
Bug Reporting
Teams
If you are interested in joining a team then send email to the team leader. If you are interested in creating a new team then send email to the Squeak-Dev Mailing List explaining your ideas. For details on the team model, see below.
Current Teams
| Name | Description | Coordinator | Team leader | Mailing List | |
| Balloon Stewards | Maintaining the Balloon- category of classes in the Basic Squeak Image | Craig Latta | Andreas Raab | List | |
| Box Admins | Maintaining the community servers | Cees de Groot | Ken Causey | List | |
| Compression Stewards | Maintaining the Compression- category of classes in the Basic Squeak Image | Craig Latta | Andreas Raab | List | |
| Documentation Team | System documentation | Craig Latta | Matthew Fulmer | List | |
| Election | Replacing SqueakFoundation Board Members | Yoshiki Ohshima | Daniel Vainsencher | List | |
| FFI Stewards | Maintaining the FFI- category of classes in the Basic Squeak Image | Craig Latta | Andreas Raab | List | |
| Graphics Stewards | Maintaining the Graphics- category of classes in the Basic Squeak Image | Craig Latta | Andreas Raab | List | |
| I/O Stewards | Maintaining the Files-, Network- and NetworkTests- categories of classes in the Basic Squeak Image | Tim Rowledge | Cees de Groot | List | |
| Modules | Spoon, Islands, Environments, Namespaces, ClassBoxes etc. | Craig Latta | Dan Ingalls | List | |
| Morphic Stewards | Maintaining the Morphic- category of classes in the Basic Squeak Image | Craig Latta | Juan Vuletich | List | |
| News | Handling the production of the Squeak Weekly and other related tasks | Craig Latta | Giovanni Corriga | List | |
| Packages | Partitioning, PI, packages, TFNR, SM, Universes etc. Evolving the tools and assigning parts of the 3.9 image, and much more. | Bert Freudenberg | Avi Bryant | List | |
| Software Engineering Team | Description: Developing and maintaining software engineering tools in and for (but not only for) squeak | Marcus Denker | Hans Beck | List | |
| ToolBuilder | Developing an abstraction layer for simple tool development over Morphic/MVC/Tweak/etc. | Cees de Groot | Brian Brown | List | |
| v3.9 | A Team focused on delivering the 3.9 release. | Cees de Groot | Stephane Ducasse | List | |
| WebSite | Handling the development of this website and the contents of http://ftp.squeak.org/ | Stephane Ducasse | Karl Ramberg | List |
You can also go to Contact Us to tell us your thoughts on how we can improve our site.
Team model
When there is a need perceived in this community, call it a project or task or whatever, the current SqueakFoundation Board will try hard to detect it. If you think there is a need to be adressed - speak up. The board then tries to find an individual Squeaker to grab that issue by the... mouse ears, and form a Team around it. There are only a few but important rules about such a Team:
- A Team is started when a Team leader is assigned. This is today done by the board. The board also assigns a board member as "coordinator" to track that Team and to keep in touch with the Team leader. From then on the Team leader takes over.
- The Team should work openly. Setting up mailinglists and/or Swikis is of course fine, but they should be readable by us all. We don't want to endorse "secret" work.
- Anyone can join a team, but the team leader is King. If some wacko joins and starts shouting "Java! Java!" then the leader has the right to kick out the wacko. :)
- After the Team is started the board would like to get some plan from the team leader. It doesn't have to be complicated at all, just some statement on the intentions on how to proceed.
So obviously the Team leader has more or less total power, which also means responsibility. The Team may fail to deliver of course, no big deal, but managing the Team should be cared for by the team leader regardless of such a failure.
Now... what are the effects we hope to get out of this model?
- Since we keep track of Teams and Team leaders and since we track their status, just that simple thing will make it much easier for all of us knowing "What is going on?". This issue is one of our burning ones, btw. It means you can always take a look at the Team table - and voil?, there you see whom to contact etc.
- Since a team leader is sticking out his/her head and actually takes responsibility and is being delegated full power, we think the incentives for actually getting results done is much higher than before. And the Team can rest safe that their work isn't going to be forgotten and generally thrown in the garbage bin.
- The noise on squeak-dev should hopefully go down a bit. This is also one of the burning issues.
- Also it will be quite clear that the board is actually much more in the "coordination business" than in the "dictator business" or in the "Super coder business".
Of course, we are not saying forming a Team is the only way to work in the squeak-dev community, but it would have a few advantages compared to "just doing it":
- The Team gets the board tracking it and helping out with coordination with the other Teams and release planning, hopefully a valuable service.
- The Team gets feedback from the board, which of course may be crap but we will give it. :)
- When results are about to be delivered the board is there to help in getting it received and properly dealt with. It is the responsibility of the board to make sure a Team doesn't work a lot on something that then doesn't get a proper reception.
- And of course, a Team has the support of the board, since we are doing the above. Such endorsement may be worth less to some, but it is there anyway.