QC: Liability Guidelines

Liability Guidelines for the DLN Community Quality Control Project

DLN leadership has had a lot of good advice come in from several high profile FOSS leaders regarding liability and what they need from the service. As we lack someone with a legal background i’m very grateful to hear from preople such as Marius from UBports on what’d create the most viable solution. Thank you to everyone who’s reached out to Michael and Ryan for the information they’ve been able to feed to us.

A knock on benefit will be a reduction in project scope meaning faster completion and easier moderation/maintenance for a much more streamlined approach.

@jakesco and @goldfish92 are already leading the charge on user stories after @goldfish92 lit the fire last meeting: https://devops.destinationlinux.network/index.php/f/4687
DLN Community Project - Quality Control Platform - #118 by jakesco

The liability boundaries for the DLN QC Community Project are as follows:

  • Testers:
    • Account creation and storage should contain bare minimum necessary information to meet scope.
    • Hardware collection:
      • Consent driven with proactive upfront transparency.
      • Least intrusive means of collection while still meeting developer filtration needs.
      • Easily verifiable means of collection (keep it simple).
  • Project Managers:
    • Account creation and storage should contain bare minimum necessary information to meet scope.
    • All testing, conversation or social aspects should occur on the Project Managers’s platform, not the QC Platform.
    • Ability to request platform approval for adding their project to a list of participating projects that testers can see.
    • Ability to filter hardware belonging to testers without strong identifiers (Ex: “A” tester has “X” hardware).
    • Ability to push a project to testers with particular hardware.
  • Infrastructure:
    • The project should seek to spread hosting liability across established and well trusted service(s).
    • Strong preference for FOSS based with generic APIs to avoid lock-in. (+1 @kobberholm)