Idea: "Managing" Work Loads With Cells (Team Hierarchies)

cogitare at ixpres.com cogitare at ixpres.com
Sun Oct 5 23:06:30 UTC 2003


>From the recent thread 'Idea: "Timeout" submissions?' it appears
that there are "Opportunities for Achivement" in the Squeak
Development methodology. Say... perhaps bugs are going unfixed,
and submitters just quit sending in bug reports... And
perhaps the key players are overworked and stressed...

My idea -- not fully worked out for Squeakland -- is to
employ a "cell" system within the Squeak community for various
purposes.

There could be a set of cells for Bug fixing, and a completely
different set of cells for, say, Testing (or whatever).

There could be completely different meta-sets of cells: one
set of sets for Users and another for Developers (and novice
developers).

Within each set of cells would be a hierarchy with a "top"
cell and sub-cells, with each sub-cell connected to its
super-cell by co-membership in the cells of a single person:
a person could be cell "team leader" in a sub-cell and
cell "member" in the sub-cell's super-cell. Alternative
topologies are possible.

As new novice Developers and Users join Squeak, they may ask to
join a team (cell). Their request would be
shunted down to an appropriate cell somewhere in the
hierarchy (an expert might be assigned a new cell!)

The possible benefits of this team/cell approach might
include increased levels of participation (i.e. work sharing),
as well as skill transfers/sharing and enhanced sense
of community with concomitant improvements in networking
and public relations.

I notice that the flow of information on the mailing list
is like a fire hose! Perhaps too much data except for
highly dedicated people...but with a cell approach the
bug reports and status info could flow efficiently up and
down the hierarchy! For example, as a novice user I might be
(am) extremely reluctant to submit a patch for a bug
or to complain when Squeak hangs (I'll just wait for the
next release...) Within a small cell linked into a hierarchy,
someone I have "relationship" with could help me get
squared away -- or escalate the problem report if
appropriate. Eventually, after achieving some mastery
I might be in a position to help other novices and be
"team leader" of my own cell. And so it could grow...

Naturally there would need to be consideration of "feel good"
and "non-judgemental" aspects of cell/teaming. For example,
someone might wish to be reassigned to a different team,
or to opt out, etc.

My interest in this is threefold:

1) I like Squeak and want it to be clean, bug-free, elegant,
popular, etc.;

2) I am learning Squeak somewhat slowly and would benefit
from some mentoring and/or association with other people
doing Squeak programming;

3) I would like to contribute but the "fire hose" of
emails, changes, bug fixes, discussions, disagreements,
and all the rest of the "process" is so vast...and
is a bit much given my other necessary activities (including
just learning Squeak/Smalltalk from scratch.)


Also...I wonder if around the world there are hundreds
or thousands of people who may be using Squeak -- or
one day millions! -- but who never feed back their
experiences, bug reports and suggestions. With a cell-based
hierarchy it might be possible to harness the power of
many more people than is the case today.




More information about the Squeak-dev mailing list