Skip to content

Sprint Planning Meeting 2022 04 13

Erik Moeller edited this page Apr 13, 2022 · 2 revisions

Sprint Planning Meeting, SecureDrop, 2022-04-13

Sprint timeframe: Mid-Day (PST) 2022-04-13 to Mid-Day (PST) 2022-04-27

1) Review previous sprint priorities

  • Get first round of Source Interface design updates to "Ready for Review"

Status: Marked as ready for review, first round of review by Kunal completed

  • Follow up with news organizations regarding spam mitigation and spam survey responses.

Status:

  • Survey findings synthesized

  • Potential blog post under discussion

  • News orgs notified about availability of new features

  • QA and ship SecureDrop Workstation and SecureDrop Client releases

Status:

  • SDK released
  • Client RC is under QA, release has been rescheduled to next week
  • Config RPM has been updated yesterday

2) Retrospective

Facilitator: Kunal

What worked well:

  • More QA for the SDW than we've ever had
  • Marek and the Qubes team is being super responsive during our 4.1 compatibility testing and SDW release testing+1+1+1
  • pairing on workstation, client, and sdk release mechanics was really helpful
  • great cooperation on the hotfix +1+1+1+1
  • the SD Server point release process seems to be getting faster/smoother (possibly because there was no kernel bump this time). Historically they may actually have been quicker but with more of a YOLO factor, I think this one hit the sweet spot in terms of QA/response time
  • There was a big push to transfer knowledge from Conor to me (Allie) and from me to Ro, etc., so that was a big win this sprint (+1!), but overall less checking of the boxes perhaps
  • We consolidated client and SDW acceptance testing, but we still need to iterate on making improvements there, e.g. SDW Updater check using the preflight updater rather than directly installing the RPM
  • SD dev meetings continue to be great (may be a repeat from last retro but still)+1+1

What can be improved:

  • Updater behavior in Qubes remains problematic. +101

    • do we need QubesOS system testing too? (Functional tests of vms/updates etc)?
  • onboarding during (a) release cycle(s) has been challenging +1 (felt like folks on the team had a lot to juggle with during my ongoing onboarding) +1 (there could be more orientation planning around our release cycle); I don't know if we've given our new folks enough attention?

    • Concerned that in practice release calendar may have us feeling like we're either releasing or QAing every other week...but maybe just something to keep an eye on.

    • Would like big picture view of the technology [Orientation improvement]

  • gpg +1+1

  • test datasets - loaddata.py does not precisely simulate the source creation experience+1 +1; would like to put a little time into this since this bit me during testing

    • Also loads an instance with an unrealistic read/unread scenario for the client

    • And breaks my staging server sometimes :[

    • ACTION: Open issue to track potential improvements

  • engagement with translators is still a concern, would like to get some positive steps in place before next server release

  • The release process for the SDK is more complicateed and time consuming than it needs to be, and overall packages take a long time to properly build and release.

  • Time estimation: is it just me? :) +1+1+1

    • For me, I haven't missed estimating how long it takes for each task during sprint planning, but that could be helpful: bring back assigning points to tasks. Then we might need to make sure we add all tasks on the project board (which we're definitely not doing).

    • We've also been doing a lot of training while working on tasks, so that could explain why time estimation doesn't seem right

    • → context-switching: plan to work on X, have meeting about Y, get pulled into Z :-) +100+1(from the outside looking in)

    • One way to make this visible: standup could be: (1) What I intended yesterday; (2) What actually happened yesterday; (3) Therefore, what I intend today...

    • We could also have a % of our time that we don't allocate, just to allow for 'surprises'

What's still a mystery:

  • Now have a workaround for syncing unsupported SecureDrop languages to Weblate...but can't reconstruct how new languages managed to get added in the past. :-\

  • How best to implement dual-channel repo support for buster->bullseye transition on Workstation

  • What does it take to build a custom template for Qubes? (Knowledge share incoming)

  • Q2 goallzzz? and resource splits across SD and SDW projects to achieve said goals+1+1

    • Making room/time/capacity for architectural discussions that will facilitate both new features and fixes +1
  • Can we script/automate more of the workstation release mechanics?+1 (also potential improvements around our package builder logic and automating build logs, etc.)

3) Key dates and time commitments

  • Erik alternating 48+PTO / 410, always off Fridays
  • Conor ~4*8 until April 28
  • Cory @ 4*10 Mon-Thu
  • Allie @ 3*10 Mon-Wed
  • Ro @ ~4*8-10 Mon-Thu
  • Giulio ~20 hours/week
  • Gonzalo on break, probably back in late April
  • Ro ? some PTO in May, TBD
  • Abigail's OOO appointments: 4/25 10:30-12:30, 5/9 8am-11am, and a few more that are getting scheduled this week.
  • KOG offset 1/2 day of weekend QA time tmw (04/14)
  • Michael PTO tomorrow (04/14) for travel
2022-04-15: Holiday (US/Canada)
2022-04-18: Holiday (Australia/France)
2022-04-19: SecureDrop Client release

After sprint:

2022-04-28: Conor's last day :-(
2022-05-03: Tails 4.30 or 5.0 (see https://tails.boum.org/contribute/calendar/)
            QA begins for SecureDrop 2.4.0

2022-05-17: SecureDrop 2.4.0 release
2022-08-02: Debian Buster EOL / Qubes 4.0 EOL
  • Vulnerabilities triage: Michael
  • Support triage: Ro

4) Review top sprint priorities

Proposed:

  1. Complete SecureDrop Workstation release train

Rationale: Release trains always take priority over non-critical ongoing work.

  • Allie, Ro, Erik, Cory
  1. Land first round of Qubes 4.1 compatibility improvements

Rationale: 4.0 EOL coming up in August, Whonix EOL for 4.0 on April 20.

  • Ro, Erik, Michael, Kev will be doing 4.1 testing
  1. Land Source Interface design changes (round 1)

Rationale: Precondition for the "flow inversion" work, which itself is expected to significantly simplify the user authentication story for sources.

  • Michael, Kunal, Kev, (Cory)

5) Board review (if there is time)

https://github.com/orgs/freedomofpress/projects/1

Clone this wiki locally