> 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
>