2022-12-09 Retrospective

 

Date

Dec 9, 2022

Team

@Mwayanjana Bolokonya (Unlicensed) @David Trapp@Lite Farm @Anant Sunilam Awasthy (Unlicensed) @Richard Wasswa (Unlicensed) @Duncan Brain @Carolina di Lello (Unlicensed) @mika.pochta

Background

This retro is for S53: Tuesday, Nov 29 2022 - Friday, Dec 9 2022

Please add comments before the meeting! We’ll take a few minutes to add additional comments and discuss, then put together action items to operationalize suggestions.

Last sprints (S51) retro is here: 2022-11-23 Retrospective

Retrospective

S53 Discussion topics:

  • How are architectural decisions being made right now?

For the next sprint, we will try the following:

  1. Planning will be a shorter discussion of the most prioritized stories where engineers claim tickets they want to work on

  2. Engineers do a research phase to understand their tickets, try to estimate them, document questions about requirements, talk to other folks, sketch out contracts, etc.

  3. A meeting 24 hours later where we as a team meet and…

    1. Engineers: Seek clarifications on requirements, propose approaches, solicit feedback

    2. QA: Understand the scope of tickets better and has a rough set of test cases for all tickets

    3. PM / UI: respond to questions and update requirements as needed

 

  • How can we better support contributors and make them feel welcome?

 

Better documentation.

We could have a rotating community manager. For example, each sprint someone is responsible for greeting and getting people settled. @David Trapp to take on this role for S54 + S55.

Could have a part-time “Community Manager” role for someone too.

Could update the “Getting Started” document with new information and add an FAQ.

Pin some Q&A on Slack channel.

Start doing

Stop doing

Keep doing

Start doing

Stop doing

Keep doing

  1. Add comments in the code base to provide a brief explanation of the implementation.

  2. Connect with the developer who created the PR. its easier to explain things on call rather than posting a long comment in the PR. (comment from Kevin: Sure - but then document that call on the PR for future generations)

  3. Add a lane on JIRA, before verification where the UI/UX designer can review UI issues associated with a ticket

  4. Prioritizing review of tickets in validation (same day review)

  • Approving PRs without actually reviewing them

  • Great team work. shout out to @Duncan Brain for doing a though review of field work PR.

  • Shout out to @Richard Wasswa (Unlicensed) in helping me out in the irrigation task module and resolving the PR comments.

  • Booya! @Carlos Moreira (Unlicensed) had his first ticket merged in - you’ll now have a tiny impact on thousands of people around the globe!

Action items:

Add “Community manager” role for each sprint planning to support new contributors @Lite Farm
Create some documentation around common libraries we use (add to “Getting started”?) - ticket for next sprint?
To discuss during next planning session, implementation of “Start doing” #2, such that there is a reduction of lengthy comments on PR, possibly adding this as a portion of definition of done.
Create or link a best practices for reviewing PRs with details on how to document back and forth between creator and reviewers @Lite Farm
@Carolina di Lello (Unlicensed) and @Mwayanjana Bolokonya (Unlicensed) to define how best to verify UI/UX tickets
@Lite Farm During planning on 12/12 to review the comment from “Stop doing” Approving PRs without actually reviewing them