Sprint Planning Meeting 2019 09 19
Erik Moeller edited this page Sep 19, 2019
·
3 revisions
Feature: v3 Support
What went well:
- excellent QA matrix/coverage and collaboration
- Collaboration specifically for the main PR I think was good (though much more and we'd be approaching too many cooks in the kitchen). Dedicated channel for this PR discussion I think worked well too to get convos about a specific change out of DMs (which scales poorly when there are more than 2 partipants ;))
What can be improved:
- We are merging critical new functionality too late in the release cycle. We should really aim to get main functionality for releases in the PR stage and merged as early as possible. A lot of integration work was left until late, creating a crunch.
- more automation
- Recommended ACTION: in upgrade scenario, automate testing behavior of the server app when the onion service configuration has changed
What's still a puzzle:
- behavior of installer when downgrading to v2
-
Recommended ACTION: investigate installer behavior
- potentially fail gracefully in all unsupported scenarios (and be extra mindful of order of operations)
- HTTPS migration process (never tested or fully documented Digicert process (even though this happened for SDO))
- ACTION: Purchase EV certs for testing (already underway)
- Too many different scenarios - automation time!
Feature: Python 3
What went well:
- It worked. (+1 +2)
- It worked really well. haha
What can be improved:
- There was at least one false alarm due to confusion about how the package is now built (pip default behavior with hashes). I (@rmol) could have done better explaining the changes so that was detected and discussed earlier. We thought dh-virtualenv was not using hashes because --require-hashes was not used; the default behavior is to require them if any requirement specifies --hash, so safe, but that's not something we should rely on the default for (Mickael found and filed issues for this in SD and other projects).
- supervisor still on Python2
- We accidentally were downloading wheels during build, hard to catch issues of this type, potentially more reviewers would be the main change to help here - I thought that was a known thing. (this was a regression).
- +1: There's a lot of complexity in the build process
- Recommended ACTION: More comments in the build playbook would be good
- Recommended ACTION: Actually create build logs, as previously discussed (will be clarified in RM guide during current sprint)
What's still a puzzle:
- We will now have to convert the Python3 App package into a reproducible one.
Feature: Deletion changes
What went well:
- comprehensive solution to issue, much more than I expected!
- very clear and good testing intructions on the PR
What can be improved:
- notifications - OSSEC alerts not always read by admins. Opportunity to alert in the JI with exception handling using: https://github.com/freedomofpress/securedrop/issues/4787
- Recommended ACTION: identify simple notifications that could serve as test case for this idea, e.g., #4787 above
- there is still a possibility that replies could be disconnected -- the fixes focused on submissions, because we permit deletion of sources and submissions, but in a disaster recovery scenario we could end up with replies in the db that lack files. Should explore this.+1
- Recommended ACTION: cover replies in integrity checks
What's still a puzzle:
- IMO the question of how best to protect against data recovery is still open - shred/srm/other and which HW makes sense? I don't think there ever was a consensus beyond "moar thermite"
- Potential ACTION: further investigation of full-disk encryption unlock
- Potential ACTION: clearer recommendations on storage w/ export input (e.g., use specific SSD make/model)
- Potential actions in this area need strong validation through threat model (this is THREAT147 for cross referencing, currently ranked at 4 in relative adjusted risk)
Feature: UX changes
What went well:
- Great collab between Nina and Erik using development environment shared via localtunnel (Nina tweaked CSS rules in inspector, Erik applied them)
What can be improved:
- UX still treated a bit as a "nice to have" (mainly Nina/Erik collab), needs to become more central to how we think about SecureDrop development
What's still a puzzle:
- packaging changes when dealing with assets (specifically configuration files) can be challenging (due to complexity of build logic)
Release process
What went well:
- From viewing the Gitter scrollback, the RM guidelines worked: final release day tasks e.g. rebuilding documentation were not forgotten. Question for the group: were some things not documented? Those should be added to the guide.
- we had some initial challenges around RTD branch naming but i think those were resolved and documented. Jen will add more docs on this
- The team handed off tasks very nicely at the end of the day
- +1, the round the clock coverage was useful for testing/ci/review tasks
- First release in a while without Jen. Sign of a mature team that the project lead does not have to be present during release. super nice job yall!!!!!!!!!!
What can be improved:
- Kushal should write changelog entries regularly (the initial logs he wrote were bad in shape).
What's still a puzzle:
- We should probably onboard someone to prod release process for Bus Factor reasons +1
- Recommended ACTION: identify at least 1 more staff member who can manage a prod release
- Recommended ACTION: need better docs for server-side part of the process
Language Management
What went well:
- source string feedback pointed out some idiomatic English that was hard to translate
- Recommended ACTION: Keep string feedback period
- Recommended ACTION: Keep prelim merge of translations
- Not sure if this is what is meant, but the increased time we had for translations was very helpful, and I think strikes a good balance to ensure we aren't rushed to merge (given long ci times)
What can be improved:
- Despite energetic contributors, Slovak and Czech didn't make it in. I think we could document reviewer selection/onboarding process better.
- Recommended ACTION: More clearly state requirements & process for new languages in docs
- Recommended ACTION: Agree on a clear policy for review requirements
- LM policies around acceptance of strings on release day (or day -1)
- Recommended ACTION: Agree on clear policy for last minute string acceptance
- i18n needs constant attention, not just showing up when a release is imminent. Notification fixes to Weblate config should improve this, but we have repeatedly dropped the ball on communications with translators, which leads to that ^.
- Recommended ACTION: Weekly update on translation community (possibly have designated team member who checks in throughout a release cycle)
- Recommended ACTION: More frequently do small string updates during release cycle
-
Recommended ACTION: slack integration for weblate comments
- We should consider translation when changing UI text.
- We should reduce churn, to avoid fatiguing translators.
- We really need to avoid idiomatic English. It's led to confusion and conflict among translators.
- We need screenshots and ideally a demo site.
- Recommended ACTION: potentially turn nyworld.org into permanent demo site
- It's been requested that we enable translation of source/journalist guides. This looks easy enough with Sphinx/RTD, but we might need/want to create a separate project for them.
What's still a puzzle:
- Let's tweet out "please help translate securedrop" at the beginning of the translation cycle and use our SecureDrop account more if critical languages are lagging behind.
- Getting more people interested in the translation process (translators/reviewers) of SecureDrop
- Erin suggested it would help to have testimonials from SD users to show the importance of the project
- I think we should send contributors stickers or shirts. +1 if Ryan has bandwidth
- What happens when a supported language isn't getting attention, and it's not being used? (Romanian)
Quality Assurance What went well:
- Really good co-ordination from kev (+1) What can be improved:
- test plan didn't keep pace with changes to spec during QA process
- moar automation especially of onion service migration cases.
- maybe add dedicated "QA Lead" role for future releases, to take certain tasks (e.g. test plan prep) explicitly off the RM's shoulders (under the RM's direction)
There are 9 working days in this sprint.
2019-09-19 : Conor OOO
2019-09-24 to 2019-09-27: Conference: Jen @ Global Investigative Journalism Conference (Germany)
2019-09-30 to 2019-10-04: SecureDrop Retreat and FPF All-Staff
2019-10-07 to 1019-10-08: Holiday (India): Kushal
2019-10-07 : QA/Feature & String Freeze for SecureDrop 1.1.0
After sprint period:
2019-10-11 to 2019-10-13 (Friday-Sunday) PyCon India
2019-10-14 to 2019-10-18: Kev at on-site
2019-10-21 : SecureDrop 1.1.0 Release
2019-10-22 : Tails 4.0 release
Time check: https://docs.google.com/spreadsheets/d/1aSLV6kMN8hhX_R64O3zruC0BmUKaF8lhBA3Ys9UsCFQ/edit#gid=0
- Agree on must-achieve sprint goals
Proposed:
- SecureDrop Core: Tails 4.0 support
- rigorous testing of all Tails-based workflows and Tails upgrade paths, including password databases;
- resolve all discovered compatibility issues;
- test on all workstations, including the SVS;
- provide additional documentation where warranted, update screenshots.
- SecureDrop Core: Complete Python3 transition:
- migrate securedrop-admin to Python 3
- supervisor and any other Python2 deps
- removal of all remaining Python2 code paths.
- SecureDrop Workstation: Complete basic export and print integration
- land basic export integration PR and round of polish/fixes.
Proposed to keep off the table for now:
- SecureDrop Workstation Debian Buster transition (except for unbreak-now tasks to fix provisioning)
https://docs.google.com/spreadsheets/d/1K9EaaXjVeXkdZvv2mg_k9exj-4M_j4EjIYOd4Ipunyc/edit#gid=0