A More Inclusive Community-Based Model for Squeak Development
danielv at tx.technion.ac.il
danielv at tx.technion.ac.il
Mon Aug 16 22:05:40 UTC 2004
I agree with much said by both Ned and Lex. I've written an article on
SqP that talks about the network effects through which these
social/technical issues affect Squeak. It has an example on how Linux
kernel development solves some of the bottleneck problems we're seeing.
lex at cc.gatech.edu wrote:
> This was a good read! I completely agree that focussing on the
> social structures is the best way to move forward, and also that we
> should pay attention to what others are coming up with. There are
> plenty of tools around, and we can make anything that we need anyway.
> Along these lines, we should think hard about what our actual
> communities are doing and desire. In particular, please notice that
> a lot of Squeak users are not tracking the "standard" Squeak
> release at this point, but have started with 3.0 (or earlier!) and
> gone on their own way. THIS IS NOT BAD. Or at least, we cannot
> afford to simply say all these guys suck and need to change pronto.
> We need to come up with a community structure that supports our
> current disparate members, even if we want to change this over time.
> One of your ideas I find particularly helpful is to consider that
> a package into any individual distribution requires some amount of
> extra work. Each distribution will have its own standards, all of
> which are more than zero.
> This does not mean, however, that people *must* be responsible. It is
> simply that they must be responsible if they want their code to go into
> the particular distribution they are interested in. There is no need to
> put guilt trips on people. Instead, let us set up standards, and then
> rely on people's own interests about whether it is worthwhile meeting
> those standards or not. Keep in mind that people *do* have pressure to
> get things into the centralized distribution(s) even if they are
> completely self-interested. Anyone who has tried to maintain patches
> while the upstream source is being modified, can tell you all about how
> un-pleasant that is.
> Another interesting aspect of having multiple distributions is that it
> removes some pressure from the gatekeepers in the "standard"
> distribution. If they think of themselves as making "the" Squeak, then
> they are under a ton of pressure to make every decision right, and this
> inevitable slows down the acceptance rate of good-looking patches. If
> they think of themselves as making *one* good Squeak distribution, then
> the standards are different. It becomes easier to allow for mistakes,
> because users who cannot tolerate the mistakes will be using a different
> distribution anyway.
> I picture this multiple distributions approach as being an excellent way
> to both support our current community and to support any efforts to
> migrate that community in desired directions. It would be nice, by
> itself, to go to some Squeak site and then be able to tour around the
> various sub-communities. And there are useful tools for migration being
> talked about: let packages be shared among communities, let them be
> added to distributions when they have met the distribution's policies,
> and do let distributions have policies attached to them.
> One aspect that bears some investigation is these "workflow" tools. I
> would be ecstatic to have a good Squeaky bug tracker, but the ToxicFarms
> guys seem to think workflow tools are better than mere bug trackers. I
> know nothing about them so cannot comment.
> On a small matter, it seems reasonable to have more than one
> image per distribution, so let's not *quite* identify images and
> one-to-one. A classic example is 3.6 basic versus 3.6 full: these both
> should draw from the same set uf packages.
> Finally, your "distribution" seems exactly what I mean by a "package
> universe", but I'm not sure if it is exactly what Linux people use it
> as. For whatever it's worth. I'm perfectly fine with "distribution" so
> long as we keep it straight.
> PS -- let's not forget to update the web sites with any updated
> community viewpoint we come up with after these discussions. And of
> course, these thoughts should actually be run by some of the
> non-squeak-dev Squeakers at some point!!
More information about the Squeak-dev