Skip to content

Sprint Planning Meeting 2022 03 02

Erik Moeller edited this page Mar 3, 2022 · 2 revisions

Sprint Planning Meeting, SecureDrop, 2022-03-02

Sprint timeframe: Mid-Day (PST) 2022-03-02 to Mid-Day (PST) 2022-03-16

1) Review previous top priorities

  • Implement lightweight spam mitigation measures in SD Server

Status: Done, TBD: should user options for min-length, codename blocking ship with 2.3.0

  • Get CSS cleanup & design standardization for Source Interface to "Ready for review"

Status: Close to ready. Will require significant testing (different operating systems, testing icons in staging, etc.), so may not be a good candidate for SD 2.3.0.

  • Begin work on high priority fixes for SD Client:
  • Indicate that conversation deletion is in progress until data is removed from disk
  • Speed up deletion as much as possible
  • Resolve issue with stale jobs being re-enqueued after user logs out / logs back in

Status: Good progress on all three issues, with draft PRs underway

2) Retrospective

What's worked well:

  • Strong emphasis on org needs in prioritizing near-term server-side changes! +1
    • nice to have a support -> issues -> prs pipeline going.+1+1
  • Great to have people in general, it's nice to be able to think in terms of getting out of maintenance mode and into problem-solving mode again + <3+1+1
  • Great to have Cory helping on SDW
    • s/helping on SDW// :) +1
    • [cfm] Aw shucks; I'm enjoying switching back and forth a bit between Server and Workstation lands. :-)
  • [cfm] I've really appreciated Workstation hangouts/pairing as I dive into that codebase.
  • Planning/brainstorming meeting with Allie ahead of feature development seemed like a really good use of time, we ruled out a lot of worse solutions (for deletion issue) in real time :)
  • Splitting up the tor2web work into discrete tasks made it easy to jump in and pick stuff up, and it was nice that we were all focusing on the same thing for a little bit
  • Once the basics were in place, the back and forth on SI redesign details was great

What can be improved:

  • Having more comprehensive or structured data on the needs of orgs re: spam mgmt would be grand. Perhaps another regular survey to users.+1
    • Already in the works :-)
  • Should more of us be pitching in on support responses? (Yes, and/or we should have some kind of more formal rotation and support onboarding?)
    • Ro and I had chatted about doing support rotation the way we do vulnerabilities triage - maybe this sprint a time to try this out?+1
  • Treating languages other than English as "first-class"+1

What's still a puzzle:

  • Are SD spam submissions send largely by bots, or largely by humans? +1+1

3) Key dates and time commitments

  • Erik alternating 48+PTO / 410, always off Fridays
  • Conor ~4*8 until April 30
  • Cory @ 4*10 Mon-Thu
  • Allie @ 3*10 Mon-Wed, out sick today
  • Ro @ 4*8-10 Mon-Thu
  • Giulio ~10-15 hours/week
  • Gonzalo on break for ~2 months, then returning to 3*10 Mon-Wed schedule
  • Maeve on break through March
  • Kunal moving during this sprint, w/ reduced availability
2022-03-08: QA / string / feature freeze for SecureDrop 2.3.0
            Tails 4.28
            SD & LL meet-and-greet (see cal)
2022-03-22: SecureDrop 2.3.0
TBD       : Potential irregular release for deletion improvement/bugfix in SD Client

Vulnerabilities triage: Kev

Support triage (first responder, escalating to others as warranted): Cory

Release calendar: https://docs.google.com/document/d/1q9OUgrJIWstEr-OhewaWepiuS7X2ihqp4YZPvj0KZoM/edit#

4) Priorities for next sprint

  1. Finalize spam mitgation changes for SecureDrop 2.3.0 and begin QA

Rationale: Spam is an increasingly common problem for organizations managing SecureDrop instances, which may ultimately cause them to stop using SD altogether.

  1. Merge high priority SecureDrop Client improvements: deletion, stale jobs bugfix

Rationale: Speedy deletion is our #1 user story to address, and relates highly to the spam problem above. The "stale jobs" bug is a severe enough data integrity issue that it warrants high priority attention.

  1. Complete one more round of testing of Qubes 4.1 compatibility PR and increase Qubes 4.1 familiarity across the team

Rationale: We have a limited number of release windows left to ship Debian Bullseye support and Qubes 4.1 support before their EOLs in August.

(Review of SecEng priorities)

Clone this wiki locally