Hi all,

>From the responses so far, you may have assumed what I meant by "tighter" as
"more" process. I'm not necessarily suggesting that.  I personally believe
there is a balance that must be maintained between strict software
engineering processes (like formally accepted review methods such as
Software Inspection) and the goals that the group is trying to achieve. In
Squeak's particular case (it's not just an open source application, but a
system where anyone can change anything -- a special case, IMHO), I believe
the approval processes are a bit too far to the left side, that's all. A lot
can be achieved with the right balance - by keeping it "agile" but also
putting in a few safeguards so people don't get sidewhacked.

Also, I don't think you can have more personal responsibility w/o more
community accountability. Clearly any system is only as good as the people
who make it.
I have no suggestions at this time, just my observation.

brad

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of goran.krampe at bluefish.se
> Sent: Sunday, July 11, 2004 2:37 PM
> To: The general-purpose Squeak developers list
> Subject: RE: How to improve Squeak
> 
> "Brad Fuller" <brad at sonaural.com> wrote:
> [SNIP]
> > But, in addition and more important: After reviewing this link, I 
> > don't have to tell you experienced ones that the approval 
> process is 
> > somewhat of a problem from a quality standpoint. For 
> instance, ONE harvester can "approve"
> > a submission to be included in the image (and, it could be 
> his/her own
> > submission) -- there is no mandated peer review, or even a 
> peer review 
> > process for that matter. I trust that everyone intimately 
> understands 
> > the other issues and problems with this process.
> 
> You know... I claim the total opposite. :) The process we 
> have now is somewhat bureaucratic and even though it works 
> "kinda" it would be better if the process was much more 
> agile. Normally open source projects don't have this kind of 
> process for core development - only for contributions coming 
> in from the outside.
> 
> > Has a proposal been put forth in the past to improve this 
> process? I 
> > for one would like to see this tighter.
> 
> "Tighter" would "kill" the joy and joy is what we thrive on. 
> In fact - as I said - we need a swifter process with more 
> trust in the experienced developers. The harvesting process 
> is perfectly fine for handling ENHs and FIXes coming in from 
> less experienced developers - but it should IMHO not be used 
> for core development by the more active experienced Squeakers.
> 
> We need something similar to a CVS with an update/commit 
> process based on trusted core developers. And I think we may 
> try to put something like that in place pretty soon - there 
> have been a few experiments. And even if we don't put that in 
> place for the image - it is used or can be used for the 
> packages being broken out of the image.
> 
> What we also need is less centralization and more personal 
> responsibility. That can be had using packages and maintainers. So...
> more packages! More maintainers! :)
> 
> regards, Göran
> 
> 
>