Daily fertility likelihood labels that never say safe #23
Labels
No Label
P0
P1
P2
release-blocker
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: null/Privacy-Period-Tracker#23
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
§18 asks for today's fertility estimate as a label, and gives the vocabulary: Lower likelihood, Higher likelihood, Estimated fertile window.
It also gives the prohibition, in three words: "Avoid 'safe' or 'unsafe' labels."
That is not squeamishness about wording. A person reading "safe" on a day outside the fertile window will take a decision on it, the estimate is derived from a predicted date that carries days of uncertainty, and the app has already promised in §18 that none of this is contraception. "Lower likelihood" is true; "safe" is a claim the model cannot support and the product must never make.
Build the label as a function of the day relative to the estimate, so it is testable, and show it on Today under the existing fertility section.
Also worth pinning here: a day can be outside the fertile window and still not be "lower likelihood" if the forecast is barely certain at all. Where confidence is low the honest label is the vaguer one.
Verify: a unit test maps days across a cycle to the three labels; no label string in the codebase contains "safe"; and the label on Today changes as the estimated window is entered and left.