We could use initiatives like the SummerTalk, to sponsor students to get 
some needed work done in Squeak. It would involve finding a tutor 
willing to give time over the summer, and also to take(find?) the time 
to write the project plans. But it could be both a good experience for 
the student and a benefit to squeak and its users.

It would also bring a satisfaction to the student, knowing his work is 
used :)

Yann , SummerTalk student
http://yann.monclair.fr/summertalk

karl wrote:
> I agree with Andreas. But I think we should consider the possibility of 
> the community to pay for someone to do some of the dirty work, for 
> example to make the maintenance of the process easier. There have been 
> people willing to put up money for projects like this. We could identify 
> what are the big bottlenecks in the process and what can be done about 
> them. Then we can look for a reasonable solution and make a offer/bounty 
> for a solution.
> Karl
> 
> 
> 
> 
> Andreas Raab skrev:
>> Hi Giovanni -
>>
>> I fully agree with the meta goals of your proposal, namely to enable 
>> people to do their own development and to limit the amount of time 
>> spend on each individual part of the release.
>>
>> That said, I'm in almost complete disagreement with the rest of your 
>> proposal ;-) The fundamental flaw in it is that you are trying to 
>> commit other people's time. Starting from "the board appoints a 
>> release team" (phase 0) over "the teams announce the development 
>> plans" (phase 1) and "code will get dropped" (phase 2) up until "the 
>> VMMaker team will want to..." (the example) you're happy committing 
>> other people's time. In my experience this has *always* been a fatal 
>> error in a volunteer open source project.
>>
>> The *only* time you can commit is your own. And given that, how much 
>> of your proposal works if the only time that you can count on is your 
>> own? Even if we want to change the release process we cannot change 
>> some fundamentals about the environment we're in. And one of those 
>> fundamentals is that (on a scale where it matters) you can't tell 
>> people what to do. They're doing it voluntarily, they're doing it for 
>> their own reasons and trying to change that simply won't work.  To 
>> give a more concrete example, the maintenance work I do for FFI, 
>> Graphics, Balloon, and Compression packages is purely a volunteer 
>> effort. If you ask me about my "development plans" for the next six 
>> months, all I can say is "uhm ... ". Most importantly, because I have 
>> a fulltime job in a startup I for example couldn't possibly commit to 
>> a six months active development plan. It's simply not doable and even 
>> if it were I'd reject it on the grounds that unless you pay me for it 
>> I'm not going to treat this serious enough to make six month plans ;-)
>>
>> Both Stef and Markus understand that basic point. They both understand 
>> that in reality, all they can count on is their own time and they have 
>> reacted by investing more and more of their own time and effort in the 
>> process. And I would like us to change that process from one that 
>> leaves people burned out into one that can be done in a reasonable 
>> amount of time with a sustainable amount of energy.
>>
>> That change starts by admitting that we're all volunteers. Whether 
>> something will happen depends on so many factors that it's basically 
>> useless to try to do serious upfront planning for it. And again this 
>> is meant on scale - for each individual team it may make perfect sense 
>> but on scale I think you really can't.
>>
>> To emphasize that point even more I'll give you two recent examples: 
>> First, we have been talking for *years* about changing the source 
>> pointer in the methods. That it happens *now* is (from my point of 
>> view) exclusively due to the fact that we got a new sources file in 
>> 3.9 and lost the entire previous history for the single reason of the 
>> source limitations. Could anyone really have planned for that? I don't 
>> think so. Second, the SSL implementation we got recently. A while ago 
>> we started looking at SSL ourselves and decided to go with OpenSSL - 
>> we talked about Crypto team and their work but honestly, I would have 
>> called anyone a nut who would have told me that this stuff will be 
>> ready by now (I probably would have just laughed them out of the 
>> room). At least for me, this project came out of the blue, completely 
>> unforeseen and again nothing you could have possibly planned for.
>>
>> My point here is (in case you haven't guessed it by now) that in a 
>> volunteer community "planning" on the scale you are looking at is in 
>> many ways a futile exercise. Things happen for their own reasons at 
>> their own speed and not because you want them. And unless you want to 
>> put in endless amounts of energy by developing all the stuff that 
>> "your release" needs, you better find a way of dealing with that.
>>
>> Which brings me to the proposal I made earlier. The main goal of that 
>> proposal is really to get away from the upfront feature planning 
>> process and deal with the chaotic reality of open source development 
>> by *embracing* it. So instead of feature list of things that we SHOULD 
>> do, I'd like us to discuss things we HAVE done. Instead of wishful 
>> thinking I'd like us to talk about all the cool stuff that is actually 
>> happening!
>>
>> I think that this may be the only way to make sure we can survive the 
>> release process in a volunteer community like ours and it's 
>> surprisingly similar to what we did at SqC - the main difference is 
>> that SqC (instead of the community) picked which of the contributions 
>> got adopted and which ones didn't. At SqC (or any other commercial 
>> entity that I have been involved in) we have always been aware of 
>> error 33 and therefore never relied on the open source effort to 
>> produce specific results in a specific time frame. That's what 
>> companies do, that's why they take money to do it. However, anything 
>> that happened was always welcome and often a surprise. And I can say 
>> for sure that during those times nobody got burned out by the 
>> process.  And I think that process can be recreated.
>>
>> Cheers,
>>   - Andreas
>>
>> Giovanni Corriga wrote:
>>> Hi all,
>>>
>>> since we've started discussing 3.10/4.0, I'd like to relay some thoughts
>>> that I've expressed some times ago on #squeak about a possible
>>> development process for Squeak 3.10.
>>>
>>> This proposal is based on two points:
>>> - decentralization of development
>>> - fixed duration of iterations ("timeboxing")
>>>
>>> "Decentralization of development" means moving most of the
>>> responsibility of development from the release team to the single
>>> package mantainers (stewards). The release team should just be an
>>> integrator of the code blessed by the stewards, and should facilitate
>>> coordination between the stewards of different packages.
>>> "Timeboxing" means having a fixed length release cycle, at the end of
>>> which a new stable version is released. This means that if there are
>>> some problems with a new feature, the deadline doesn't get postponed;
>>> instead it's the feature that gets dropped from the current development
>>> release and rescheduled for the next release.
>>>
>>> How would this work? Here's a more detailed description.
>>> -----------------------------------------------------------------------
>>> PHASE 0: RELEASE TEAM FORMATION
>>> The SqF board will appoint a release team for 3.10. This team will have
>>> 3-7 members; 5 would be the sweet spot.
>>> The first task for the release team will be to find a mantainer for each
>>> one of the packages currently in the image. If they can't find a
>>> mantainer for a package, than said package _will get dropped from the
>>> image_ without any further discussion.
>>>
>>> PHASE 1: RELEASE PLAN
>>> After having found mantainers for every package, there's a package
>>> selection phase, during which the team and the maintainers:
>>> - decide which packages currently in the image should get removed from
>>> the image and turned into SqueakMap-loadable packages.
>>> - decide which new packages can be added to the image or replace other
>>> packages currently in the image.
>>> Input from the community and the stakeholders will be taken into
>>> account.
>>>
>>> After deciding which packages will be in the 3.10 image, the release
>>> team, the mantainers and the community will work on creating the release
>>> plan.
>>> Each package mantainer will announce what it plans to do for 3.10. The
>>> release team will integrate these proposals into a coherent release
>>> plan, solving possible conflicts and coordination problems. The
>>> community will be able to make comments and/or requests.
>>>
>>> After all these steps, which shouldn't take more than a month, the
>>> development of 3.10 can start.
>>>
>>> PHASE 2: DEVELOPMENT
>>> Development will have three stages:
>>> - a 3 months alpha stage
>>> - a 2 months beta stage
>>> - a 1 month gamma/RC stage.
>>> The deadline for each stage will be decided at the beginning of the
>>> iteration.
>>> Every week during each stage the release team will integrate the new
>>> releases of each package blessed by the package mantainers.
>>>
>>> Package mantainers will be the main responsible for development of their
>>> package and they'll be free to manage development as they like; ideally
>>> they should create a development team.
>>>
>>> If at the end of the alpha stage some of the work items of the plan
>>> aren't near completion, _these items and the corresponding code will get
>>> dropped_. If this is not possible, the code will be kept in the image,
>>> but it will have not to break the other code in the image.
>>>
>>> During the beta and gamma stages, no new features will get added to the
>>> image; only bug fixes can go in. During the gamma stage, only
>>> showstopper bugs will be fixed; other bug fixes (eg. cosmetical fixes)
>>> will be scheduled for 3.10.1.
>>>
>>> During the gamma stage of 3.10, the release team for 3.11 (or 4.1 or
>>> whatever) will get appointed and will work with the package mantainers
>>> to form the release plan for the next version.
>>>
>>> EXAMPLE
>>> Here's a an example of how things could possibly work.
>>>
>>> Release plan:
>>> During phase 1, the various package mantainers propose work items. So
>>> let's pretend that...
>>>   - VMMaker team will want to:
>>>     * integrate the async event patches useful for SqueakGtk.
>>>     * integrate the Ffenestri code in all VMs, including the Unix one.
>>>     * work with the Kernel team/maintainer on CompiledMethod cleanup.
>>>   - Nebraska team will work on removing it from the image.
>>>   - Pavel will want to work with various mantainers to integrate his
>>> patches for his KernelImage system.
>>>   - Tools team will want to:
>>>     * better integrate AST and the Refactoring services.
>>>     * make Omnibrowser the default browser.
>>>
>>> Now let's pretend that at the end of the alpha stage, the Tools team
>>> still hasn't produced an Omnibrowser based debugger. Since it's the end
>>> of the alpha stage, the OBDebugger will be punted to the next release,
>>> and 3.10 will have a class browser based on OB but still the old
>>> debugger.
>>> -----------------------------------------------------------------------
>>>
>>> I believe a process such as the one I'm proposing can work and help
>>> produce good quality releases.
>>>
>>> I'd like to hear comments on this, even if they just say that my
>>> proposal sucks.
>>>
>>>     Ciao,
>>>
>>>         Giovanni
>>>
>>>
>>>
>>
>>
>>
> 
>