Guaging community opinion (was Re: Complexity and starting over on the JVM)

Ken Causey ken at kencausey.com
Tue Feb 5 14:18:51 UTC 2008


On Mon, 2008-02-04 at 19:08 -0800, Andreas Raab wrote:
> Paul D. Fernhout wrote:
> > Andreas Raab wrote:
> >> Paul D. Fernhout wrote:
> >>> So, for the 21st century, Squeak gets underscore *wrong*.
> >>>   http://en.wikipedia.org/wiki/ASCII
> >>>
> >>> And for a dozen years. Every knows it is wrong. There was even a recent
> >>> discussion on it. It still can't be fixed!
> >> Sure it can. Croquet fixed it.
> > 
> > That's exactly my point. :-) Why only Croquet (or some other images)?
> 
> Because you need authority to make certain changes and these changes 
> certainly will be seen as controversial by some. And no, that's not your 
> point as far as I can tell - unless your point is that there is no 
> unambiguous authority for Squeak today (which I agree).
> 
> Cheers,
>    - Andreas
> 

As regards a given release, it seems to me the authority is fairly
clear: the release team and perhaps more specifically the release team
leader.  At that point of course the release team is in the position of
having to guage the community's reaction to a change.  And here is where
I think we have trouble in practice.  Our current methodology is to
listen to the vocal minority (those who actually go to the trouble to
post to squeak-dev or reply to the submitter).  My experience has been
that it is those who feel negatively about something that feel most
compelled to respond.  Correspondingly I strongly suspect there is a
significant minority (at least) who is quite happy with the idea but
either can't be bothered to respond or don't feel their opinion is
relevant; then there's another quite possibly larger group who have no
real opinion.

Within this community I've come to feel that the only day to day
practical solution is to do it and then ask for forgiveness when it goes
all pear shaped (badly).  Of course when that happens it really helps
when it is something that can be readily reversed with no harm done.
And that's where it seems we have a problem because the current release
management schemes don't well-support removing something readily and in
such a way that few if any are inconvenienced.  I don't have a ready
solution to that, it is something I find myself thinking about more and
more.

In the interim it seems to me that each release team has to make the
choice.  They can either take a chance, make a change simply based on
the vocal few and prepare for possible flames at a later date.  Or in
cases where it seems desirable, go to a little more trouble and call for
a semi-formal vote.  Clearly that's not something any of us want to do
every week.  But I don't think it would be that big of a deal to do it a
few times a year.  Details would need to be worked out but I think it
would not be all that difficult and would be easier each time we did it.

I have other thoughts on this and related issues, but I find myself
getting more and more annoyed with long emails, and this one is already
over the threshold,

Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080205/e50d400c/attachment.pgp


More information about the Squeak-dev mailing list