Skip to content

Latest commit

 

History

History
58 lines (49 loc) · 3.41 KB

operating_model.md

File metadata and controls

58 lines (49 loc) · 3.41 KB
Raw

OpenDSR Operating Model

Introduction

This document defines the operations of the OpenDSR group, including:

  • Approve changes to the specification via Git pull requests
  • Routinely publish new versions of the specification
  • Convene as a group to make operating model decisions
  • Collaborate towards enriching OpenDSR resources (wiki, sample code, etc.)
  • Co-champion the OpenDSR specification towards greater adoption

Roles

People interact with OpenDSR via two types participation: Working Group

  • People who steward and lead the OpenDSR spec.
  • People who operate the OpenDSR GitHub repo, publish new versions of the specification, collaborate to promote the specification in-market, etc.
  • All community participation is also expected from Working Group members.
  • Active participation is expected from working group members.

Community

  • People who implement the OpenDSR spec to receive and track GDPR data subject requests.
  • People who ask questions on Github, submit pull requests, contribute to the wiki, etc.
  • Community members may submit Pull requests to add their company and logo to the public site

Working Group

This is an open specification, there are no limits to who can implement or who can apply to be in the Working Group (including competitors of any existing members). The Working Group is composed of:

  • Working Group is composed of members from mParticle, AppsFlyer, Braze and Amplitude.
  • Participants are encouraged to be from product, engineering and privacy/legal/compliance roles as the content is technical.

What is expected of working group members?

The Working Group drives the OpenDSR initiative:

  • Answering GitHub issues and interacting with the community at large
  • Reviewing and commenting on GitHub pull requests
  • Authoring and reviewing Github wiki pages and other resources to help the community
  • Participating in quarterly meetings with other working group members
  • Building support for OpenDSR into your products
  • Champion the OpenDSR initiative in your day-to-day discussions

How are new working group members added?

  • New members must be proposed and receive 75% support from existing working group members
  • New members must be judged on the positive contributions and domain knowledge, not on existing biases or marketplace influences (competition)

How do working group members leave?

  • Existing members may elect to resign their membership or may be remove due to inactivity.

Specification Updates

A few simple rules will help keep the project running and the repo clean:

  • The repo is the truth, anything left unpublished hasn’t actually happened yet
  • Goal of responding to new issues within 3 days
  • Normal pull requests require 2 members to approve before they are accepted
  • Large pull requests require 3 members to approve before being accepted
  • Most conversation around issues and pull requests should happen publicly in GitHub
  • If consensus cannot be reached via discussion, members are encouraged to collaborate offline and update the discussion threads afterwards
  • Specification will use Semantic Versioning (https://semver.org/) to organize changes

Housekeeping

  • This operating model, license and contribution guidelines are all included in the Repo and are subject to the same change processes
  • Quarterly working group conference calls to discuss outstanding issues and iterate on this operating model
  • Contribution guidelines are defined in the CONTRIBUTING.md file in the repo