Task Force November Revolution
Last updated at 8:32 pm UTC on 4 January 2006
Note: This project has been subsumed by the Packages Team effort. See the Packages Team on the list of teams here: http://www.squeak.org/Community/Teams
This is the work page for operation "November Revolution" (2003-11-05), aka TFNR, see posting on squeak-dev for details.
Yeah, the talk about revolution is of course just a joke - but we are in fact trying to distribute responsibility and power here, so it is a kind of "revolution". A positive one.
Going on now 2004-02-16: Task 1 finished as soon as the Guides all say they are behind it. Task 2 is finished. Task 3 ongoing. Task 4 ongoing.
People in Task Force
The IRC nicknames are in parenthesis.
This is the final list.
- Göran Krampe (gokr), on IRC from about GMT 8.00-16.00 + maybe 20.00-24.00
- Stephen Pair (spair), on IRC from about GMT 13:30-22:00 (send a message with my nick "spair" in it...that will buzz my IRC client)
- Adam Spitz (AdamSpitz), potentially on IRC GMT 0300-0800 (if I've done the conversion from PST correctly :)
- Giovanni Giorgi (giovanni74) on IRC from about GMT 20:00-22:00
- Brian Brown (brianbrown) on IRC 15:30-23:30, 0400-0600 UTC
- Marcus Denker (marcusd)
- Ned Konz (bikeNomad/ned) on IRC (potentially) 1500-0300 UTC
- Avi Bryant (avi)
- Dan Ingalls (?)
- Brian Rice (water) on IRC GMT 1700-0000, maybe 0400-0800
First three sub tasks
The first three tasks below are what the first week (and maybe longer) will be spent on. Members sign up on ONE of these tasks hopefully giving us a distribution like 3+3+4. :)
Dangers of TFNR (task 1)
We are assigning maintainers (Stewards, but I am moving away from that word because I have realized people have different "feelings" about it) to parts of base Squeak. This will change the landscape. What problems can arise? What do we need to do to prevent these problems? We have the "maintainer misbehaves"-problem, should there be a mechanism to "fire" maintainers? One way could be to let the Guides have that power - but only use it in special circumstances of course. Do we need to define expectations/responsibilities for the maintainers? Or can we let that evolve after TFNR (which is my personal view)? Etc etc. This task is about "soft issues" - community management etc.
Task result: A proposed set of rules on the Swiki with motivations. After punching it out and refining it further on squeak-dev I would like the Guides to "club them" before TFNR is finished (within 3 weeks that is).
Guidelines For Package Maintainership
Signed up: Giovanni Giorgi, Brian Brown, Stephen Pair (group leader)
Infrastructure (task 2)
This is about figuring out PackageInfo/SM2/BFAV/MudPie/whatever and how we use them in all this. There is a plan to add PI instances to the image using updates that describe the logical packages that are still locked inside the image. SM2 has a new field for packages in which the name of the PI can be entered - so we can register these logical packages on SM2. Another plan is to use BFAV to maintain these packages to begin with by simply giving the maintainers approval capacity for their respective packages.
Task result: Real stuff. :) A plan + real working mechanisms to support it. This includes a running working SM2 (yay!), perhaps a revised PackageInfo and some idea how to use MudPie for the in-image packages etc.
Signed up: Göran Krampe, Avi Bryant (group leader), Marcus Denker
Image inventory (task 3)
This is about taking the current Basic image and doing a first inventory. Finding good logical packages. The edges are allowed to be a bit "wrong" just as long as we get them. Big packages are ok - the maintainers can later split them up even more. Categories will be renamed and perhaps split up, classes will be moved between them. PIs will be created. Don't get stuck in trying to figure out dependencies too much and DON'T start doing refactoring - there is no time. Also don't bother making loose methods, the maintainers can do that later.
Task result: A reorganization + a set of PIs. What we need here is to group the classes/categories so that they are all covered by PIs. There is an interactive whiteboard up now at: http://anakin.bluefish.se:8080 (login as "guest" and empty password for readonly access).
Signed up: Ned Konz (group leader), Adam Spitz, Brian Rice
Inventory followup (task 4)
Using the results of the first 3 tasks above, go out and find those maintainers! Note that there can be multiple maintainers for some larger packages, like Morphic. Typically done by writing down candidate lists, posting on squeak-dev fishing for interest, lobbying personally and explain what it means etc. Lots of communication here. Convincing people that they can and that they don't need to be the best to do it. The important thing is to have interest, large ears and time to do it.
Task result: All logical packages created in task "Inventory" are registered on SM2 with one or more maintainers each. (See Stewards for Packages.)
Signed up: Adam Spitz
Here we add proposed tasks not started yet.
Adam Spitz have produced a nice little list of 30 candidate packages (some are very small and should perhaps not be separate etc, but anyway) that are "breakoutable" today. Let us begin by finding maintainers for these and actually breaking them out. This task is a "spike solution" - it tests how easy/hard it is to find maintainers, what issues come to the surface (technical and social)?
Task result: Adam's list dealt with in one way or the other. :)
Minimal snapshot planning
Craig Latta has been working hard on Squat - creating a minimal snapshot of the Squeak image and has reached below 100kb. This work should somehow eventually meet "normal" Squeak. This task is about planning ahead and figuring out how and when this can be done.
Task result: A proposal on how and when Craig's work can be "folded back" into regular Squeak.
We need to produce some sort of document that describes why we are doing what we are doing (i.e. why it is important to have package maintains for base packages). It should also articulate the expectations of maintainers, include technical discussions, and describe the overall process of maintainership.
Task result: A document (most likely on the swiki) that clearly states the motivation, rationale and process of package maintainership.
Packages that are already up on SqueakMap (and have maintainers, so this task force has nothing to do with those), but have remained in the basic image:
Packages that could easily be split apart from the image, this is the "Adam's list" mentioned above:
- Morphic-Postscript Canvases
- Morphic-Remote Hands
- Network-IRC Chat
- Network-TelNet WordNet
- System-Serial Port
- Tools-Doc Library
- Tools-File Contents Browser
- Tools-Message Names
- Tools-Method Finder
- Tools-Package Pane Browser
- Tools-Process Browser
- Tools-Time Profile Browser