Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
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.

Status Reports

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

Subsequent tasks

Here we add proposed tasks not started yet.



Adam's list

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.

Documentation/Communication

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.

Adam's list

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: