Log of the retrospective analysis from Pharo 2.0

> Hello happy pharoers
>
> Since Pharo2.0 will be released pretty soon, we led a retrospective analysis to learn and improve our process.
> Here are the notes taken by clement from the meeting led by esteban with all the team here.
>
> Pharo 2.0 Retrospective meeting by Esteban Lorenzo
>
> The Good
> • BugTracker as Backlog
> • Sprint / mini - sprint / pair programming
> • Locking changes before release
> • Community getting involved
> • Web doc
> • jenkins : the monkey, zeroconf script
> • Smalltalkhub
> The Bad
> • Trello
> • We need a place to backlog what to do. We should use the FogBugz bug tracker
> • Long development cycle (1 year), Focus problem : most things works but are not finished
> • We should have a 1 to 2 months cycle with a part where we introduce new things and a part where we only fix bugs. At the end of each cycle, Pharo should be stable. Each cycle should have a retrospective meeting. We should pair program every friday afternoons on Pharo improvements.
> • New failing test in Jenkins, Red builds on jenkins stayed forever
> • We need a clear separation between pharo and pharo contribution both on smalltalk hub and Jenkins to have a clean green front end to show to end users
> • In case of a red build, we need a quick meeting to pick someone to fix it.
> • We need to fix the red builds on the friday' mandatory mini sprint
> • Integrator bottleneck
> • More intelligent monkey
> • better tools (spec tool idea from Esteban where you just click accept and the slce is integrated)
> • New features accepted only with tests and comments
> • Only slices accepted no more change sets
> • Pointless discussions on the mailing list
> • Documentation : class comments, ...
> • do not integrate undocumented features
> • add code critics features in the monkey
> • change the template of the class comment
> The Ugly
> • 2 weeks lost : broken image during ESUG
> • 2 weeks lost : beginning of the year : no VM working, jenkins couldn’t test things.
> • -> we will staged development.
> • Communication failed : team and community
> • For new features, send more mails to the Pharo or RMOD mailing list and less to the RMOD mailing list or private mails between few people
> • Infrastructure
> • VM : stability
> • Stability : 1 VM release per Pharo release. 1 official Vm which is not just some VM from a build.
> • Stability : VM not release if an acceptance list does not work with the VM. The acceptance list is for now all the Pharo core, seaside and Moose
>

>
> Cheers,
> Doru
>
>
> On Mar 15, 2013, at 9:49 PM, Stéphane Ducasse <[hidden email]> wrote:
>
>> Hello happy pharoers
>>
>> Since Pharo2.0 will be released pretty soon, we led a retrospective analysis to learn and improve our process.
>> Here are the notes taken by clement from the meeting led by esteban with all the team here.
>>
>> Pharo 2.0 Retrospective meeting by Esteban Lorenzo
>>
>> The Good
>> • BugTracker as Backlog
>> • Sprint / mini - sprint / pair programming
>> • Locking changes before release
>> • Community getting involved
>> • Web doc
>> • jenkins : the monkey, zeroconf script
>> • Smalltalkhub
>> The Bad
>> • Trello
>> • We need a place to backlog what to do. We should use the FogBugz bug tracker
>> • Long development cycle (1 year), Focus problem : most things works but are not finished
>> • We should have a 1 to 2 months cycle with a part where we introduce new things and a part where we only fix bugs. At the end of each cycle, Pharo should be stable. Each cycle should have a retrospective meeting. We should pair program every friday afternoons on Pharo improvements.
>> • New failing test in Jenkins, Red builds on jenkins stayed forever
>> • We need a clear separation between pharo and pharo contribution both on smalltalk hub and Jenkins to have a clean green front end to show to end users
>> • In case of a red build, we need a quick meeting to pick someone to fix it.
>> • We need to fix the red builds on the friday' mandatory mini sprint
>> • Integrator bottleneck
>> • More intelligent monkey
>> • better tools (spec tool idea from Esteban where you just click accept and the slce is integrated)
>> • New features accepted only with tests and comments
>> • Only slices accepted no more change sets
>> • Pointless discussions on the mailing list
>> • Documentation : class comments, ...
>> • do not integrate undocumented features
>> • add code critics features in the monkey
>> • change the template of the class comment
>> The Ugly
>> • 2 weeks lost : broken image during ESUG
>> • 2 weeks lost : beginning of the year : no VM working, jenkins couldn’t test things.
>> • -> we will staged development.
>> • Communication failed : team and community
>> • For new features, send more mails to the Pharo or RMOD mailing list and less to the RMOD mailing list or private mails between few people
>> • Infrastructure
>> • VM : stability
>> • Stability : 1 VM release per Pharo release. 1 official Vm which is not just some VM from a build.
>> • Stability : VM not release if an acceptance list does not work with the VM. The acceptance list is for now all the Pharo core, seaside and Moose
>>
>
> --
> www.tudorgirba.com
>
> "Not knowing how to do something is not an argument for how it cannot be done."
>
>