Improving the aesthetics and usability of Squeak

Peter Schuller peter.schuller at infidyne.com
Tue Jul 9 18:44:28 UTC 2002


[ When I went to bed last night I had figured out a good way to lay out
my thoughts. Today, of course, I have forgotten it. But hopefully it is
possible to make sense of the stuff below. ]

> Please go on. I've been reading this thread with a lot of interest. The
> only two things I am missing is a) some proposal of how the problem can
> be solved and b) the necessary steps (and comittment) to get there.

I do have a suggestion. But first, let me clarify a few of my
opinions/beliefs. Perhaps they do not match that of the majority and/or
Squeak Central, in which case my proposed remedy is not useful. If they
do match, then it *may* be useful.

I am assuming one goal is to make Squeak as useful a tool as possible;
to make it popular; to increase the number of developers developing for
it. If this is not a goal, than I'm way off to begin with and the
remainder of this E-Mail is probably not that relevant.

I believe that for any piece of code there are certain advantages to
being in the image as well as disadvantages.

>From a user's (other developer using the code) perspective it is
convenient for a given feature to be in the image. The user does not
need to incorporate changes each time he/she upgrades to a newer image.
Further more, what is in the image is more likely to work than stuff
outside of the image possibly lagging behind Squeak development.

Of course, this also means that the developer of the feature (in the
image) has added responsibility in keeping his code up-to-date with the
remainder of Squeak.

However under the assumption that the developer does intend to keep his
feature up-to-date, it probably becomes easier if it is in the image.
Especially if it is a minor addition - a convenience method for some
existing class for example. Another developer making dramatic changes to
said class is then aware of the extra method. If the method breaks, it
will not be as likely to go unnoticed. If the method is not in the
image, the original developer must alone try to track changes made by
other people on dependencies, and modify his/her code appropriately.

I would like to introduce two types of changes:

   * The first is the very small minor enhancement - call it a
mini-patch. Examples could include adding documentation to the methods
of just one class, or fixing a minor bug in one method, or slightly
enhancing a class (if only by adding an *IfFail: variant to an already
existing method, for example).

   * The second is the large patch. A complete redesign of the I/O
subsystem, or the GUI layer, or a dramatic refactoring of core classes.

I am assuming that if a mini-patch is a basic language feature that is
clearly missing from Squeak, it is desirable to include it. If it's just
a cool feature that is useful but might be considered image bloat, it's
a trade-off and the outcome depends on the situation.

For larger patches, deciding when and if an enhancement should make it
into the image is a difficult task. It would typically affect a lot of
other code.

The type of patch I am mostly trying to address at this time is the
mini-patch. I can imagine Squeak Central being quite busy with other
things than sifting through hundreds of little patches and deciding
which should go into the image. But then, I have zero knowledge of what
goes on (practically) behind the scenes with regards to the release
process.

I do however believe that acceptance of mini-patches (those that are
useful) can be an important part in improving Squeak. While Squeak
progresses very quickly overall (at least, I believe so), there are some
areas that need obvious attention.

One is documentation. I have often found myself having to read through a
good chunk of code to understand how to use a class. This should in an
ideal world only be necessary if you were *developing* the class. Often,
the task of figuring out how to use a class is not that difficult. But
even so, it would be a definite improvement in documentation if I could
read the class docs and the documentation for the methods I want to use,
and based on that be ready to use it. Often, it does not take a lot of
work to add the require documentation (or at least parts of it) and
submit a mini-patch. But this is only useful if the patch gets accepted
(assuming it is of high enough quality).

Another area is the I/O classes. An obviously lack of a blocking
mechanism to accept connections in ConnectionQueue for example, prompted
me to add such a feature. But again, this wasn't very useful because it
didn't make it into the image. Then there if Flow - a larger patch and
another matter entirely.

I may very well be wrong, but I believe that if there is a mechanism in
place in the Squeak release process that is able to "handle" a steady
stream of mini-patches from various people (meaning, good ones get
committed), developers would be more inclined to submit such patches
because they know that if they do a good job, it will most likely be
committed. The two examples above probably fit into this picture.

If this is correct, then such a mechanism might go a long way towards
increasing the inflow of enhancements to Squeak. The question is what
exactly this "mechanism" is.

My suggestion, then, is for a form of community review process (there
may be serious flaws in this suggesting, but that's why I'm posting it,
so that people can criticize). Suppose there was an automated system
that gobbles up changes (perhaps built upon the current system that
scans the ML), puts them in a database, and gives the community a chance
to react to them - perhaps voting yes/no/abstain on weather or not it
should go into the image, and optionally provide comments.

In the end, the idea is that the community would alleviate the workload
of Squeak central with respect to culling patches. It would be
immediately obvious which changes have strong support, which are utterly
disliked, and which don't really trigger a re-action one way or another.

This whole thing could be done through a web interfaces, or additional
E-Mail based mechanisms, both, or something else.

I don't know. Perhaps "outsourcing" this process is a bad idea. Perhaps
there aren't enough in the community to support a voting system. Perhaps
the idea is just crazy all the way through. In either case, it's just a
suggestion :)

(If such a thing were to be adopted I would gladly help with the
software needed to create such a system.)

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org





More information about the Squeak-dev mailing list