Policy Name: Mass Changing of Data
Policy Statement
- When we will modify data based on time information, we should never do so unless at least one warning email has been sent to every affected user, giving at least three working days notice of the change.
- Examples are: expiring a membership, or changing the status of a bug that needs information and has no additional comments for a long time.
- We should determine "affected people" in the most comprehensive way possible.
- For example, in the case of a bugtask, it should be the assignee, the reporter, and all subscribers to the bug. In the case of an individual team membership, it should be the individual concerned and the team admins. If it is a team membership in another team, then the admins of both teams should be notified.
- We should not just assume that a warning mail would have been sent at a particular date, it should record in the database that a warning mail has been sent. This is because a script may fail, or not be run, on a particular invocation. So we need to know if a warning was actually sent, not assume that a warning "would have been sent".
- For example, it is not enough to create a robot which warns everyone who's membership in a team will expire "in seven days" on the assumption that the script will be run every day. That robot should store a data that the warning was sent, and should only expire the membership n days after that warning was sent.
Rationale
We are implementing this to prevent surprises to our user base and to ensure we maintain the highest degree of data integrity that we can.
Scope
- Affects: All Launchpad
- Term: permanent
Supporting Documentation
- none