Andreas,

==============================
... the "mainstream" cannot necessarily cater to every subgroup. In
Jim's case it was pretty clear that this is work that will be
interesting for a particular subgroup of the community - people who need
100% Windows looking apps. Jim did a *great* job at this but the simple
fact of the matter is that Squeak community is roughly 30/30/30 between
Windows, Mac, Unix and only a subset of the 30% windows users really
wants Windows looking apps. Meaning that Zurgle might be interesting for
(probably less than) 10% of the overall users of Squeak. Personally, I
don't see how Jim could have been treated "less horribly" other than the
people who care about the native looking stuff to pick it up and help
him. That he didn't get much support -to me- is a clear sign that the
percentage of people who want Windows look is a lot less than 10%.
==============================

An alternate approach would be to ask for a streamlined Zurgle that
didn't need the external files, was better than the base image, and
could be turned into the full Zurgle for those who wanted it.  I said
more about this in my response to Edgar.



==============================
BTW, I totally understand that this is a circular argument. Squeak is
cross-platform which means that a Windows look will never become
"standard" which means Squeak will not attract Windows programmers etc.
But that's just what Squeak is, we made it that way. And of course we
could change it, but then I wouldn't use it.
==============================

With respect, you are taking an overly narrow view.  Squeak can provide
multiple policies to serve a wide range of masters.  I must also
disagree tha the Windows look is crucial to snaring Windows users.  Feel
is another matter, and Squeak's feel leaves a lot to be desired.  It can
also be fixed.  You  might take a look at my MouseOverMadness change set
on Mantis as a small down payment.



==============================
> Please note that I am very comfortable with folks like Andreas having
> far more influence than newcomers. I also do not believe there is a
> conscious effort to exclude new ideas. However, there appears to be no
> need to review and close submissions, so they get ignored vs. rejected
> with an explanation. I suspect that many things that have been ignored
> would be much harder to actively reject with a reason.

I don't think so. I think you're getting confused by the absence of any
visible policy for inclusion into the image. It is hard to guess from
the grab-bags of stuff that get included why exactly those things ended
up in the image and why not others. Personally, I feel that about the
*only* thing that had a right to get into the image in the last three
Squeak versions was the m17n support. Everything else should have been
loadable via SqueakMap. And (again personally speaking) I would have had
no problem to actively reject all these other things merely based on the
fact that they're not critical and that they should prove their weight
in package form after which someone might bring forward an argument why
the inclusion is critical.
==============================

I stand by the glass ceiling and the harm it does by discouraging
would-be contributors.  Otherwise, I see what you are saying, **IF**
there is ultimately a way for the packages to get included.  Absent
that, SqueakMap will turn into a junk yard of conflicting packages and
lost opporunities.  Squeak needs some configuration management, and
inclusion critieria must be wider than "non-critical need not apply." 
Put another way, who decides what is critical?  Critical to what end? 
As an example, past tense is arguably appropriate for Zurgle, which is a
shame.  I agree that it is/was too much, but fault the configuration
management process (or lack thereof) for failing to negotiate a mutually
agreeable solution that could have been with us for years now, not in
the way of the hard core Squeaker, and serving the needs of those
burdened with demanding customers or other constraints.

Bill





Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029