This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.
Privacy enforcement comes with a lot of interesting questions regarding what they mean and how to record them.
For example, if a team has a package and believes the API is complete, they should be able to prevent privacy violations. In this scenario, privacy violations are more problems of the consuming team then of the owning team. For the problem side of this anlysis, you would think that the todo should be recorded on the violating package’s side (which is what we do today). To allow the owning team to have better control and be able to prevent privacy violations, they are likely better suited for the package defining the API (we don’t have this).
If, however, the API is not complete and the team has privacy violations on a package, those are more the owning packages problem and the consuming team should likely not get bugged that they are violating privacy (although they might want to know…)
Likely, we have to refactor how packwerk does package_todo to support this. The cool thing is, we got lots of time with Rafael from Rails Core team and shopify to talk through this and he sees the same issue and is on board with finding ways to solve this
What if we created the capability to record privacy todos in two places?
It might look like this:
- We require different todo keys, like
incoming_privacy
(in the provider) andoutgoing_privacy
(in the consumer). - Privacy configs might be
false
: as todayincomplete_and_enforce
: record only incoming privacycomplete_and_enforce
: record incoming and outgoing privacystrict
: don’t allow any todos