Provide a design rationale

sventuerpe commented 4 years ago

What is missing

A design rationale should be provided that explains:

design objectives for app-based contact tracing support,
known approaches to the problem of supporting contact tracing with a smartphone app,
an evaluation of each approach with respect to the deign objectives, and
why automated contact tracing with anonymous notification was chosen as the preferred approach.

The design rationale should be honestly written. This is not a sales exercise.

Why should it be included

Design exploration is an essential step of development. Even under time pressure this step should not be skipped and replaced by a series of political accidents. The stakes are high with an application that is to be used by millions of people with real-world consequences. This task should be taken seriously and the objectively best approach according to current knowledge should be selected. The public needs and deserves to known why a particular approach has been chosen.

A clear design rationale also supports decision-making down the road. Feature and extension ideas will continue to pop up, the more so the project seems to have a rather limited understanding of stakeholders and their needs. With a proper design rationale it becomes easier to reject ideas that would fit better into a different approach and to explain such – to some extent inevitable and useful – rejections.

Where should it be included

The design rationale should become a separate document.

(If the project were unable to produce a design rationale for political reasons, a statement to this end in the scoping document or elsewhere would do.)

Ryuno-Ki commented 4 years ago

As clarification: Design is not meant in terms of UI/UX here? From what I read, you're rather thinking along the lines of architecture decision records?

sventuerpe commented 4 years ago

Not limited to UI/UX, but considering in general terms how an app is supposed to work and to interact with its stakeholders. I would like to see a comparison between major design approaches – e.g., Bluetooth-based automated tracing, logbook approaches, Chinese health codes, etc. – within a reasonable set of high-level design objectives like effectiveness, reliability, robustness against abuse, privacy, etc.

kbobrowski commented 4 years ago

I'm not sure if it is the best place for these kind of issues - maybe we can trace down some government github repo for this ;) it looks like a decision to use current approach (as to the method and key design decisions) has been done on a higher level than SAP / Telekom

But if there is someone here who could answer questions from @sventuerpe it would be great.

m4cx commented 4 years ago

@kbobrowski But why should such decisions be made by non-experts. Political decisions can be made upfront, but must be revisited. SAP / Telekom are the experts now responsible for this now.

sventuerpe commented 4 years ago

“Political support” could be one design goal and if this is the most important one, why not document this fact?

fealXX commented 4 years ago

As far as I am aware (and I'm sure someone will correct me if I am wrong), Google and Apple "decided" on the approach by setting the outline of how the OS-API will work and the Bundesregierung had to align their wishes. I don't like it, but that seems to be the way things work. https://www.apple.com/newsroom/2020/04/apple-and-google-partner-on-covid-19-contact-tracing-technology/

If you want a general comparison between approaches, looking into the work done by PEPP-PT / DP-3T initiatives might help. https://github.com/DP-3T/documents https://github.com/pepp-pt/pepp-pt-documentation

sventuerpe commented 4 years ago

My perspective is broader than just Bluetooth-based contact identification and listing. But yes, Gapples decision to provide certain APIs surely plays a role. The corresponding generic design goal would be something like feasibility of implementation with available technology. Alternative approaches could score equally high or even higher in this dimension.

fealXX commented 4 years ago

What approaches other than BLE do you have in mind? GPS/GSM-Location is not precise enough and would lead to even bigger privacy problems, when recording location history. The only other available wide-spread tech in a smartphone I could think of would be wifi-direct, but that would take the users ability to log into their WLAN while the app is active.

kbobrowski commented 4 years ago

It looks like the direction of the app was dictated by decision not to use geolocation (so no GPS / Chinese health codes), decision to go with decentralized approach, and Apple decision to allow efficient use of Bluetooth in the background only through Google/Apple API. This series of decisions leads to quick convergence on current architecture.

@m4cx @sventuerpe agree that these decisions should be done by experts, and also would like to see some documentation on which decisions were based on "political support". Hope this is a place where it can be clarified, let's wait for a comment on this from code owners.

SebastianWolf-SAP commented 4 years ago

Sorry that we needed to let you wait that long, but we took the questions really seriously and asked the German Federal Government to get proper responses. Of course, many aspects have already been discussed here (no geolocation, use of Google/Apple API for best functionality etc...), but that of course doesn't answer everything

To keep it short, there is no separate document and such a separate document is currently not planned. But all the answers are now available in our FAQ on our website, please check the new entries in the "General" section.

The answers might not be as extensive as you might probably have expected, but you can see that they are very honest ones and reflect pretty much the rationale behind the project and the way so far.

Please get back to us in case you need additional details or if something is not clear.

Mit freundlichen Grüßen/Best regards, SW Corona Warn-App Open Source Team

corona-warn-app / cwa-documentation