securedrop
securedrop copied to clipboard
Update feature_request.md
Echoing similar PR in docs repo, below (verbaitm from that PR):
- "Has this idea been influenced by your conversations with users, or by your own experience as a SecureDrop user?" is not user research evidence. It's anecdotal feedback. Qualifying anecdotal feedback as user research evidence (the latter, aggregate information collected in a methodical fashion) is a disservice to the difference between the two. Anecdotal feedback is absolutely important, however—they just need to be correctly qualified.
- Who the users are, needs to be more clearly spoken to in issues. Centering issues on existing user profiles (mini-personae) can be helpful.
- In 3 years, I've not once produced any findings from user research to merit updates to the docs. As such, "User Research Evidence" as its own section is both moot and problematic.
And,
- "Security," "Product Desirability," and "Usability" are very different primary needs that SecureDrop dev efforts work in service to. Human error is often a security concern, and nefarious behavior by humans is at the root of most security concerns—however it has been my own observation in securedrop Issues, that both should be spoken-to, separately. Where they overlap, that can certainly be spoken to—but I feel it would better support both, to seek to speak to both.
Status
Ready for review / Work in progress
Description of Changes
Fixes #.
Changes proposed in this pull request:
Testing
How should the reviewer test this PR? Write out any special testing steps here.
Deployment
Any special considerations for deployment? Consider both:
- Upgrading existing production instances.
- New installs.
Checklist
If you made changes to the server application code:
- [ ] Linting (
make lint
) and tests (make test
) pass in the development container
If you made changes to securedrop-admin
:
- [ ] Linting and tests (
make -C admin test
) pass in the admin development container
If you made changes to the system configuration:
- [ ] Configuration tests pass
If you added or removed a file deployed with the application:
- [ ] I have updated AppArmor rules to include the change
If you made non-trivial code changes:
- [ ] I have written a test plan and validated it for this PR
Choose one of the following:
- [ ] I have opened a PR in the docs repo for these changes, or will do so later
- [ ] I would appreciate help with the documentation
- [ ] These changes do not require documentation
If you added or updated a production code dependency:
Production code dependencies are defined in:
-
admin/requirements.in
-
admin/requirements-ansible.in
-
securedrop/requirements/python3/securedrop-app-code-requirements.in
If you changed another requirements.in
file that applies only to development
or testing environments, then no diff review is required, and you can skip
(remove) this section.
Choose one of the following:
- [ ] I have performed a diff review and pasted the contents to the packaging wiki
- [ ] I would like someone else to do the diff review
The threat model language is a bit unclear to me and I've suggested alternative wording there. Otherwise this looks like a good change from my end.
I've appended a commit with the suggested changes.
Superseded by #6734, which rebases 8d9aa6e0946bb23d72a63344c8b9e02a08e42e2e.