Aragon Client Product Development Pipeline

As the Product Working Group starts to take shape, I would like to propose a product development pipeline for the Aragon client and its core internal APIs (e.g. aragonOS, aragonAPI, aragonPM).

Status Quo

The current flow (loosely) resembles something like this:

  1. An individual from a Flock team has idea
  2. Said individual proposes said idea to his own Flock team
  3. Said Flock team internally agrees they’d like to spend effort on said idea
  4. An individual from the originating Flock team MAY write a forum post to gain wider feedback
  5. An individual from the originating Flock team MAY write one or more Github issues tracking the idea
  6. An individual from a Flock team, usually the originating one, starts design work
  7. An individual from a Flock team, usually the originating one, starts implementation work
  8. An individual from the designing / implementing Flock team MAY attempt to coordinate with other Flock teams on its progress and/or gather feedback
  9. The implementing Flock team sends a pull request to one or more repos with their completed work
  10. Other Flock teams MAY review pull request, usually with low internal priority and low contextual awareness of the rationale behind changes

The current process is lacking inter-Flock coordination and has decreased Flock effectiveness numerous times over the prior two Aragon Network Vote periods (Jan - July, 2019). There are a lot of MAY s involved in coordinating efforts, which has been a problem when many repos are actively worked on and owned by different Flock teams.

My hope is that the Working Groups will be able to solve this.

Proposed Process

The goal of this process is to facilitate information sharing and contextual awareness over product changes proposed by various independent Flock teams. It has been designed to be in similar spirit to how EIPs are discussed in each Ethereum All Core Devs call, however, with less formality (for now).


The first three steps stay similar:

  1. An individual from a Flock team has idea
  2. Said individual proposes said idea to his own Flock team
  3. Said Flock team internally agrees they’d like to spend effort on said idea

The rest involves more “bureaucracy”:

  1. Originating Flock team MUST share an initial draft of the idea to the Product Working Group, to kickstart its discussion. Any relevant materials, such as feasibility studies or early wireframes, SHOULD be shared at this time.
  2. If the idea has secured a CHAMPION (by default this is the original Flock team, but may shift during discussions), and has been greenlit by the OWNER of the repos / products touched, continue. Otherwise, stop; the idea becomes deprioritized, and perhaps, is tracked somewhere.
  3. CHAMPION is responsible for further development of the idea, whose progress MUST be reported to the Product Working Group. CHAMPION may not undertake any work itself, but must arrange for at least the following (and ultimately make them available for others):
    • Feasibility study
    • High-fidelity design
    • Product scope and spec
    • Important dates (target release, etc.)
  4. At a sufficient stage, designs should be reviewed by either a Design Working Group or the OWNER
  5. At a sufficient stage, implementation work can begin and should be announced in the All Aragon Devs call. Most inter-Flock development coordination should now transition to this call, but pulling in product and design resources as required.
  6. OWNERs commit resources for reviewing and helping merge changes by agreed-to dates, given relevant buffers for each Flock team’s internal prioritization periods
  7. At any stage, CHAMPION or OWNER can suggest to deprioritize, pause, or cancel in-flight changes, but MUST receive [loose] consensus from the Product Working Group to do so

The above is not intended to be onerous nor difficult to apply. It’s main purpose is to do the following well:

  • Initiate high-level product and scoping discussions sooner
  • Provide contextual awareness and more information to all actors
  • Clarify expectations for involved actors

It also does not need to be followed for every change, especially smaller features. However, anyone may suggest to freeze a development so it can undergo this process (with the exception of developments initiated by their OWNER).

9 Likes

Feels like an awesome idea!!