This page exists to document the results of the Parrot Implementor's BOF at YAPC::NA 2009. The subject was a postmortem review of recent Parrot releases. Root causes were explored, and the group came away with a consensus list of items to improve the next set of releases.

What Went Right?

See attachment:Photo_062209_001.jpg

• on time
• on budget
• hit some milestones
• rotating release managers works
• external languages still work
• devel cycle still works
• received publicity
• product roadmap/direction
• reached 1.0 thanks to PDS/milestones

What Went Wrong?

See attachment:Photo_062209_002.jpg

• last minute life interruptions (1 vote)
• missed {several|critical} milestones (4 votes, despite appearance of picture --agh)
• missing release artifacts
• last minute HLL testing necessary (merged with below)
• incomplete client language separation (merged, 1 vote)
• low bus number on multiple branches (3 votes)
• vague or missing descriptions of multiple milestones (2 votes)
• milestones removed from roadmap
• poor triage of HLL blockers (1 vote)
• poor communications with HLL implementors (4 votes)
• infrastructure changes & schedules

Why?

See attachment:Photo_062209_003.jpg

• not enough tuits/developers for the aggressive plan
• one miss multiplies
• lack of concrete plans "anyone" can work on

design stuck in peoples' heads

• lacking project management
• incomplete/ineffective milestone ticket review -> no action
• #ps rear view in some cases
• missing {tactical|useful|timely} information

How Can We Improve the 'On Ramp'

See attachment:Photo_062209_004.jpg

• What's problematic about recruiting, training, and retaining?
• ((We don't know. --agh))

How Can We Do Better?

See attachment:Photo_062209_005.jpg

• big tasks need sub tasks/STEPS
• analyze approach/publicize tradeoffs
• new milestones need some written plan
• publicize VISION for supported releases
• technical descriptions of (completed) milestones
• document project management requirements
• review critical tickets/assign volunteers in #ps
• request task analysis from critical ticket reporters
• document severity/priority in Trac for reporters
• make #ps quicker - pre-post standard reports

Austin adds:

Several of these items are redundant, or are aspects of the same underlying need. The "sub tasks" item, along with the "written plan for new milestones" and "request task analysis" are all essentially the same. Patrick pointed out, with support from others including Andrew, that when even a weak, ineffectual roadmap or plan was laid out there were suddenly plenty of people who could help. (Specific reference here to GC and Dtrace in the PVMW.)

Someone else (I think cotto, but not sure) mentioned that Dan Sugalski's posts on the technical details and tradeoffs were enormously valuable/informative, both for "learning to code" and "learning to code Parrot." Thus, the "analyze approach" and "technical descriptions" items. I suggested that the technical description be added to the project manager's checklist, to encourage developers who complete a milestone to provide documentation on what has been delivered.

The various project management / #ps items cluster around the need for the team as a whole to be aware of what's coming up, and what might not be coming up if someone disappears. In addition, with some of the suggested additions to #ps Patrick or Jerry raised the point that #ps meetings are already long enough. Thus, some sort of speedup is needed there.

The breakdown and vision items are related to improving the on-ramp, for getting new developers. The milestone report currently available includes tickets, but not an overall "thrust" or vision. Thus, re-instate the "here's what we're aiming for" vision that apparently used to exist. Jerry (I think?) suggested special-purpose tickets.

Group picture

This picture was taken Monday, 22 June 2009 around 7pm, after the Parrot Implementors BOF at YAPC::NA 2009.

Back row, left to right: Austin Hastings, kid51, chromatic, whiteknight. Front row, left to right: Util, cotto, pmichaud, particle, jhorwitz.