Sprint Planning Meeting 2018 05 16

Sprint Planning Meeting, SecureDrop, May 16, 2018

Sprint timeframe: 5/16 BOD-5/30 BOD

What did we get done?

What went well with 0.7.0?

Messaging/announcements were smooth
Mickael did all the things with the stuff
Admin upgrade flow was smoother than butter on stick-free pan
Excellent communication and prep for supporting Admins, e.g. EFAIL discussion, etc.
Strong cross-team communication, e.g. Mike debugging the apt upgrade logic
Solid, albeit partial, progress toward automated upgrade testing (not yet in CI; would have caught the libjpg snag)
Involved more team members in crucial aspects of release, rather than the historical flow of lead dev orchestrating entirely
We found issues during QA process before the release. (and great collaboration in fixing these issues)
Good decision on removing a feature as required for the release.
Good decision making to push back the release a week
Introduced a lot of new, complex, functionality
Excellent triaging of a complex security vulnerability (efail) while balancing the release
SecureDrop servers came up after upgrade
QA procedure continues to get more structured with each release

What didn't go well?

[support] Postponed release after prerelease announcement caused (very light) amounts of confusion
Large amount of hefty PRs merged; long review times, complicated QA
Missed initial release date
Too many issues made their way into develop branch
Upgrade testing did not uncover major issues e.g. securedrop-app-code package not updating at all, likely to due confusing/unclear upgrade process for testers / QA participants
Found issues at the last moment and they were difficult to reproduce (example: osssec email or update testing one). ^ [Freddy] - Is this the tag issue for the qt-updated? I have thoughts.
Some functionality is becoming increasingly difficult to test in an automated fashion and requires more hands on QA time
Too much QAing while team is travel (this seems to be a reoccuring theme)
Release and QA process in general is still a significant time sink and manual QA limits the feature work we can do
We didnt uncover any bad-ass vulnerabilities with cool names (and no -install bug)(yet)

What do we want to change?

TBB testing! Lots of QA time goes toward manual interaction with the web UIs. Having the functional test suite target remote instances would be hugely valuable 👍
More paired review for remote team members; was critical for solid review of e.g. local-automated-upgrade-testing
More discussion in issues of potential implementation, to minimize improvisation when composing PRs.
Upgrade testing in CI (possibly daily rather than per PR) :+10000000000000000000e2000001: +1000000000000010000000000000000001 to this (<-- I think we got it, buddies.)
Consider 2-person review process for complex PRs - which complex PR did not get that 2 pair ? - Ideally yes, but we are already review- limited with current team. Actually the PRS that caused the most trouble - journalist notifications and updater GUI were reviewed by 2 people each iirc
More explicit/formalized testing plan for complex PRs - this is critical, 👍
Better QA testing plan (and results, github comments are challenging for this)(e.g 3.14 kernels was a tested by Mickael but I didn't see that). We need a testing Matrix
More integration testing that can automate more QA
More careful review and testing prior to merging PRs
Change the release time (if required) based on the availibility of the team members.
Each new big feature should possibly be broken into two tickets -- the actual logic piece, and then the testing component
- note: Can this be part of the PR process?

Ensure we capture PTO/holidays (incl international).

urgent bug fixes [outage level]
urgent security fixes
quick (< 1 hour) community PR merges + comments -- alternatively, communicate that PR will be handled next sprint
responding to issues

Consider tasks not in the spreadsheet: bugs, PRs, other urgent issues