"Peter Smet" <peter.smet at flinders.edu.au> wrote...
>If we are to encourage people like yourself and others to contribute to
>Squeak, we must give them immediate feedback - yes, this will go into the
>image, yes it will go into an add-on package, or no, it has the following
>problems. This just doesnt happen, but IMO it is important that it should.

Since we do follow essentially all of the Squeak mail, and do our best to respond daily on important topics, it would feel better if you were to address such specific suggestions directly to us rather than sitting on it and then complaining openly to a third party.

That said, Peter, we also agree with you.

There are lots of things to be considered here...

* Each day the Squeak list grows a little and, more importantly, the level of interest and seriousness of its members increases as well.  There are understandable pressures for features found in other Smalltalks, ANSI compliance, and a higher standard of documentation.

* Each day Squeak also moves closer to something that could meaningfully serve a MUCH larger community.  We still have a long way to go, but we are talking literally millions of end users (HyperCard is a good metaphor) on the internet, versus hundreds of developers.  [Don't get me wrong -- we're developers, so we are pushing for those goals as well].

* You are correct that the Squeak team is "flat out" most of the time, whether we're building infrastructure for development, trying to advance the state of end-user accessibility, producing artifacts for our employer (or just keeping up with messages on the Squeak list ;-).

No one feels the shortcomings in the current situation more than we.

We can understand your frustration at not getting immediate feedback on each change you make to the system.  At the same time, Stephen Pope is a good example of someone who has dealt with this situation effectively, by maintaining his a set of goodies for each new release, and occasionally lobbying for some of them to be folded into the main line (in fact it is usually other folks who do the lobbying).

The process is not perfect.  We do the best we can.

Sometimes I get too busy to issue updates.  Most often, though, I am actively planning how to shield the less adventurous citizens of SqueakVille from the effects of dangerous and incomplete cycles of change.  There have been a couple of times since the last release when I could have issued updates with some confidence, but they happened also to be times when I was busy.

On 6/21, I wrote...
>A number of interesting enhancements and bug fixes have been put
>forward from this mailing list.  Please let me know privately of
>anything you feel deserves special consideration for inclusion in
>the main line release.

.... regarding the next release.  It would be much more pleasant (and actually useful) to get reminded of, eg, the improvement to atRandom in this manner I requested, than to find it lodged in an oblique reply to a newbie question (and thanks, by the way, to those who did reply).

"Mark A. Schwenk" <mas at wellthot.com> wrote...
>There now seems to be a large enough base of users outside Disney that could
>cooperate to form a development group to design and maintain a parallel version
>of Squeak (Squawk?) and respond to the growing needs of its growing audience. 

This may be true, and the time may have come to do this.  I would feel a small sense of failure if it is so.  From the beginning, we have felt that Squeak can continue for a long time as the home of both Blue plane and Pink plane developments.  Even with the downsides, we feel the synergy that results from a coherent sense of what Squeak is, and the simplicity of pointing newcomers to a single source, still outweigh the possible benefits of a major fork.

I wouldn't press this position (believe me, it's not simple to keep it all together) if I didn't feel that it is still possible to have our cake and eat it too.  From my point of view as coordinator, everything is still quite manageable.  There are at least two major problems, but I believe they can both be addressed with less effort and impact than a major fork.  One, as has been pointed out, is largely a matter of communication.  The other is one of responsiveness to suggestions and contributions from throughout SqueakVille.

Regarding communication we do make an effort to outline our major directions from time to time.  The finestructure is manifest in the updates.

> What's worse is that the Disney team have their own internal update stream
> that we are not privy to. Recently, this resulted in a lot of duplicated
> effort by people on the list, fixing a bug that was already well and truly
> fixed. Now I realise that the Disney team are probaby working flat out on

While I dislike the pejorative allusion of the term "privy", I have to agree that this is a problem.  Fortunately I think there is a simple solution.  In the past we have been reluctant to release updates at various junctures, in order to shield newbies from possible instabilities.  What SHOULD happen is this:  when we have that feeling, that is when we should declare a new version number.  Newbies would not "see" any later updates, but any serious Squeaker could advance his version and track the latest changes.  We at Squeak central can freely broadcast everything hot off the press, knowing that only the self-professed test pilots will be affected.  All the necessary mechanism is already present in the update system.

This still leaves Peter's question about quick feedback on simple proferred changes.  We could probably use a volunteer to filter these out and solicit our intentions.  The perceived responsiveness will also be enhanced with access to the latest updates.

Regarding responsiveness to major contributions, things are not so simple, but where there's a will there's a way.  Let's take a look at what happens when it works:
	* One of us sees the contribution, and likes the idea
	* He gets the code and sees if it works right
		...and fixes bugs if found
	* He reads the code and sees if it is well-written
		...and cleans it up if not
	* He then releases it as an internal update
		...and we fix any further bugs that show up
	* It comes out when I next release internal updates
		(not frequently enough -- I know ;-)

Each of us in the group plays this role at various times, and in certain areas of our interests.
The problem is, what to do when...
	we like the idea, but we want it done differently,
	the code needs work, but we don't have the time to do it,
	it's a good suggestion (not code), but it's not our top priority.

To make things more concrete, here is a list of things that we agree would be good,
and some of the reasons why they haven't gotten done:
	Integrate Craig's exception mechanism
		Time to make it ANSI compliant
		Time to integrate with existing uses in the system so things are coherent
	Support block closures
		Time to assemble everything needed and debug it all
	Integerate Tim's new compiled method objects
		Many of the benefits come "free" with Jitter
		Time to assemble debug and test all the changes
	Improve ANSI compatibility
		Time to enumerate and evaluate merits of each major issue
		Time to implement those that pass the test
	Handle events cleanly so nothing gets dropped
		Reasonable crossover strategy
		Choice of how best to do it across all platforms
		Time, of course
	Documentation
		Not our style (just kidding ;-)

In an ideal world, here is what might happen:
	* For each such project, someone from SqueakVille (that's you) would
	    step forward and volunteer to carry it through to completion.
	* We would tell that person what we feel needs to be done to
	    make us happy with its inclusion.
	* Working with a fully updated system, that person eventually
	    brings the project to completion and offers it for inclusion
	* We then have little to do but look it over, check that it
	    meets our standards as well as the original intention,
	    and issue it as an official update.

Obviously we're talking serious commitment.  But in many cases (certainly Craig and Tim), the hard work has already been done.  Our commitment in return would be:  having stated any concerns in step 2, we would proceed with dispatch to include the completed project.

This has gotten to be longer than I intended, and it's probably a good place to stop.

	Do you think this addresses the worst shortcomings in the current process?
	Are you seriously interested in taking on any of the above projects (maybe with help)?
	Are there other projects that I haven't mentioned that should be included
		as most appropriately handled in this manner?
	Are there other similar high-level concerns that should be addressed at this time?

	- Dan (for The Squeak Team)