Skip to content

Sprint Planning Meeting 2020 04 22

Jump to bottom
Erik Moeller edited this page Apr 23, 2020 · 2 revisions

Sprint Planning Meeting, SecureDrop, April 22, 2020

Sprint timeframe: Beginning of Day (PDT) 2020-04-22 to Beginning of Day (PDT) 2020-05-06

0) Retrospective

What we said we would do:

  • Respond to immediate pilot-related needs (this may result in sprint tasks being deferred)

Goal met. We supported 4 installs (with a lot of team responsiveness to changes in scheduling and logistics). We reached agreement on copy & paste approach, which was not a formal sprint commitment.

  • Land critical updates for SecureDrop 1.3.0

Goal partially met. All critical SecureDrop 1.3.0 changes have either landed or are in progress.

  • Land scalability fixes to ensure client is consistently well-behaved with large number of sources

Goal met. Timeouts investigation completed, timeout changes and other performance improvements landed. SD 1.3.0 will include important performance fix that should help all Workstation users. Further performance improvements to come.

Other notable accomplishments:

  • We're now running a pilot for our flagship technical project, and it's going well so far!

  • Good upstream coordination with Qubes on libxenlight issue, seems in part a Qubes/Xen memory management issue, see https://github.com/freedomofpress/securedrop-workstation/issues/498#issuecomment-615064166 . Some landed/pending changes may mitigate but won't fully resolve yet.

  • Lots of blood/sweat/tears getting Qt text widgets to resize correctly according to their contents while permitting copy&paste. Close to a viable approach, final decision still TBD.

  • Changes to QA loader to make it easier to manage datasets for staging environments

  • Successful early testing of HTTPSEverywhere ruleset

Team comments and observations:

What worked well: - Conor: We installed the Workstation without setting foot on-site! +3 - Conor: Early pilot feedback is darn positive, plus we're getting great tips on workflows to support - Nina: Had not expected SO MUCH communication on Signal, from participants; which has been a delight and super helpful/insightful.

What could be improved:

  • Erik: Too many tasks on the sprint, which contributes to stress and cognitive overload. We're introducing mid-sprint management check-ins, and will be a bit more conservative this sprint, especially with a QA-intense release upcoming.
  • better scoping of tasks/issues prior to implementation could reduce review time (probably similar total time-on-task)
  • Conor: Structured reports on testing results: debugging the timeouts has been an adventure, several times we appeared to be talking past each other since we were testing in slightly different ways. Full templating of reports strikes me as a bit strict, but maybe a wiki page recommending a format
    • +1 to structured reporting/what to watch for: makes it easier for fringe folks (ro speaking) to help w QA
    • I dunno, templates sound like a good idea considering the time these tests take; want to make the most of that
    • ACTION: Let's talk in the context of sprint planning about whether we have adequate test plans for issues on the sprint
    • ACTION: Let's create a template for environmental information (owner: Kev)
  • bumping Allie's idea yesterday re: more defined client test data (https://github.com/freedomofpress/securedrop-client/wiki/Message-Test-Data ) in general
    • ACTION: Create a developer tips page on SecureDrop Workstation wiki (owner: Kushal)
  • Nina: No UX access to Security GH repo is frustrating; understand the "why," but it excludes human behavior fails & opportunities

What's still a puzzle:

  • Kushal: The Qt text widget height issue is a big puzzle, asked around in every related community/developer + google search. All provided solutions failed in different ways.

  • Allie: Usually when we've been stuck on Qt issues, we've been able to look at the Qt forums and google around for ideas, but this time we hit a wall with this strategy. I think we should look into finding more active Qt communities, maybe take an advanced class so we can figure out where to get advanced help. Otherwise, we need to allocate more time so that we can review Qt C++ code to figure out why things do work for us as expected. If we can, in future getting a training from KDAB on this will be really useful. We can ask for a non-profit discount.

  • ACTION: Ping KDAB about training opportunities / nonprofit discount (owner: Erik)

  • ACTION: Start pining PyQt mailing list re: recent issues (owner: Allie)

    • To this point there is a pyqt mailing list we could use, I was looking at it this morning and it seems pretty active. Another option is Freenode's #qt #qt-pyside channels (I believe kushal you use these) (kushal: I asked in those and then the kde channels+people)
    • Is there no public bugtracker for PyQt5? odd if true (political question: All Qt people will always ask to use pyside2, and PyQt5 will ask for formal contract with them (unless we find the community). Generally all of these issues go into Qt related forums/channels.
    • +1, a broader network to consult with here would be invaluable

  • What does functional testing look like? Of the client specifically, of the Workstation components overall?

  • ACTION: Include questions about functional testing approaches in our outreach to expert communities

  • ACTION: In sprint n+1 do exploratory investigation of GUI automation / integration testing of Qubes (probably Kushal/Kev collaboration)

1) Review important dates and time commitments

2020-04-27              : PTO: John
2020-04-28              : PTO: John
2020-05-04              : PTO: Jen
2020-05-05              : SecureDrop 1.3.0

Time check:
https://docs.google.com/spreadsheets/d/1FkODYnG3vVrRhwZckRtx1bB-vox1Y_6agcuCdBnYrDI/edit#gid=0

2) Agree on goals for this sprint

  1. QA & release SecureDrop 1.3.0 including all agreed upon changes.

  2. Get SecureDrop Client (incl. SDK/Proxy) release-ready with, at minimum, the following changes:

    • current master
    • copy & paste solution
    • text wrapping solution
    • missing submission key handling solution

Release-ready means that we can start the QA process on nightlies, but may not cut a release yet.

  1. Get SecureDrop Workstation release-ready with, at minimum, the following changes:
    • current master
    • Copy & Paste RPC policy change

Release-ready means that we can start the QA process on nightlies, but may not cut a release yet.

3) Task selection and estimation

https://docs.google.com/spreadsheets/d/1vA_9kwrtktdqq--ps1xt9iHJu7Q-U9Y8Q4xy0HfgI9M/edit#gid=0

Clone this wiki locally