2014-06-17 Curating Crunch¶

• Public IRC - ongoing effort to keep this professional, avoid discussing operational issues, avoid posting links that anonymous public can't use, etc.
• Redmine issue page layout makes it easy to miss the story description entirely. (Added #3048)
• Read "before review" and "during review" checklists on development process wiki page more often -- like when you're submitting a branch for review, or saying LGTM.
• When stories are underspecified, do something about it before going ahead: some combination of writing down your assumptions in order to confirm, and asking story author / Tom to fill in the mysteries.
• More designing before implementing. On non-trivial stories, think about what you're going to do, write it down, and show it to someone else before spending time writing code. This is the best time to get ideas about alternate/better approaches, advice from someone who knows more about the code you're attacking, etc.
• When preparing a branch for review, adding notes about "what I did and why" is a good idea. (But add them to the story page in redmine, not the review task page.)