Thanks for the report.

It's great to see you doing a retrospective. I hope you will do it regularly :).

Cheers,
Doru


On Mar 15, 2013, at 9:49 PM, Stéphane Ducasse <[email protected]> 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."


Reply via email to