|
|
**An importer is considered done when**
|
|
|
|
|
|
- All relevant data is imported to the Pod (defined per plugin)
|
|
|
- Data is imported incrementally: Data is not duplicated / stored twice when the plugin imports data multiple times.
|
|
|
- A test account for the corresponding service, which holds example data of all the imported data types, with enough variation to catch most edge cases
|
|
|
- Mocking for the tests dependent on the external service
|
|
|
- There is a Docker file that installs all requirements to run the plugin
|
|
|
- CI runs tests to see whether all data types are downloaded, stored and connected in the Pod
|
|
|
- Authentication is implemented
|
|
|
- A clear description of how credentials are made available to the plugin, in order to enable front end and platform developers to implement that
|
|
|
- A clear description of what trust we are asking from users, e.g. are they storing their credentials on the server their Pod is hosted, is communication encrypted, etc.
|
|
|
- The plugin has comprehensive documentation on the:
|
|
|
- Usage
|
|
|
- Implementation
|
|
|
- Data fields imported, including datatypes of those fields
|
|
|
- What data is not imported
|
|
|
- Frequency the plugin can run (this should be <5 min for social services, and not e.g. only daily because of use of GDPR requests)
|
|
|
- Time it takes to run the plugin
|
|
|
- System requirements (RAM, CPU, disk and others if relevant)
|
|
|
- The authentication flow: What login mechanism is used, how is 2FA handled, etc. |