Changes between Version 4 and Version 5 of Yapc10Bof

Show
Ignore:
Timestamp:
06/23/09 23:16:03 (5 years ago)
Author:
Austin_Hastings
Comment:

Moved photos inline, w/ OCR

Legend:

Unmodified
Added
Removed
Modified
  • Yapc10Bof

    v4 v5  
    1 This page exists to document the results of the Parrot Implementor's BOF at YAPC::NA 2009. 
    21 
    3 == Group picture names == 
     2[[PageOutline]] 
    43 
    5   * First row 
    6     1. Austin_Hastings (leftmost) 
    7     2. kid51 
    8     3. chromatic 
    9     4. whiteknight 
    10   * Second row 
    11     1. Util (leftmost) 
    12     2. cotto 
    13     3. pmichaud 
    14     4. particle 
    15     5. jhorwitz 
     4This 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. Some root cause analysis was attempted, but it fell victim to "we're hungry and want beer" near the end. Nonetheless, the group reached consensus on some changes to attempt going forward. 
     5 
     6== What Went Right? == 
     7 
     8See attachment:Photo_062209_001.jpg 
     9 
     10  * on time 
     11  * on budget 
     12  * hit some milestones 
     13  * rotating release managers works 
     14  * external languages still work 
     15  * devel cycle still works 
     16  * received publicity 
     17  * __product__ roadmap/direction 
     18  * reached 1.0 thanks to PDS/milestones 
     19 
     20 
     21== What Went Wrong? == 
     22 
     23See attachment:Photo_062209_002.jpg 
     24 
     25  * last minute life interruptions (1 vote) 
     26  * missed {several|critical} milestones (4 votes, despite appearance of picture --agh) 
     27  * missing release artifacts 
     28  * last minute HLL testing necessary (merged with below) 
     29  * incomplete client language separation (merged, 1 vote) 
     30  * low bus number on multiple branches (3 votes) 
     31  * vague or missing descriptions of multiple milestones (2 votes) 
     32  * milestones removed from roadmap 
     33  * poor triage of HLL blockers (1 vote) 
     34  * poor communications with HLL implementors (4 votes) 
     35  * infrastructure changes & schedules 
     36 
     37== Why? == 
     38 
     39See attachment:Photo_062209_003.jpg 
     40 
     41  * not enough tuits/developers for the aggressive plan 
     42  * one miss multiplies 
     43  * lack of concrete plans "anyone" can work on 
     44     design stuck in peoples' heads 
     45  * lacking project management 
     46  * incomplete/ineffective milestone ticket review -> no action 
     47  * #ps rear view in some cases 
     48  * missing {tactical|useful|timely} information 
     49 
     50== How Can We Improve the 'On Ramp' == 
     51 
     52See attachment:Photo_062209_004.jpg 
     53 
     54  * What's problematic about recruiting, training, and retaining? 
     55  * ((We don't know. --agh)) 
     56 
     57== How Can We Do Better? == 
     58 
     59See attachment:Photo_062209_005.jpg 
     60 
     61  * big tasks need sub tasks/STEPS 
     62  * analyze approach/publicize tradeoffs 
     63  * new milestones need some written plan 
     64  * publicize VISION for supported releases 
     65  * technical descriptions of (completed) milestones 
     66  * document project management requirements 
     67  * review critical tickets/assign volunteers in #ps 
     68  * request task analysis from critical ticket reporters 
     69  * document severity/priority in Trac for reporters 
     70  * make #ps quicker - pre-post standard reports 
     71 
     72=== Austin adds: === 
     73 
     74Several 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.) 
     75 
     76Someone 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. 
     77 
     78The 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. 
     79 
     80The 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. 
     81 
     82== Group picture == 
     83[[Image(Photo_062209_006.jpg, 50%)]] 
     84 
     85This picture was taken Monday, 22 June 2009 around 7pm, after the Parrot Implementors BOF at YAPC::NA 2009.  
     86 
     87Back row, left to right: Austin Hastings, kid51, chromatic, whiteknight. Front row, left to right: Util, cotto, pmichaud, particle, jhorwitz.