PeeringDB Product Committee

PeeringDB Product Committee Charter

Approved by Board July 7th, 2017

Scope

The PeeringDB Product Committee (PC) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community.

Out of scope

  • The PC does not drive PeeringDB improvements related to the administrative interfaces & functions used by the PeeringDB Admin Committee.
  • The PC does not consider PeeringDB improvements related to the server, storage, hosting or network infrastructure.

Deliverables

  • Gather inputs from stakeholders regarding the evolution of PeeringDB in terms of product features and overall long term objectives.
  • Formulate the long term objectives and validate them with the PeeringDB Board and the members of the PeeringDB Governance mailing list.
  • Document and maintain workflow process to handle requests and issues.
  • Maintain the product roadmap and feature request backlog and makes them publicly accessible.
  • Create and maintain PeeringDB product documentation and presentation materials.
  • Develop market outreach and evangelization to increase the uptake of PeeringDB use and improve data quality.
  • Propose new features or enhancements based on the long term objectives and validates significant product evolutions with key stakeholders.

Collaboration

The PC shall work with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations.

Participation

The PeeringDB Product Committee members serve a 2 years renewable term, potential volunteers may submit their candidacy to the PeeringDB Board. The product committee will select their own Chair and Vice Chair by simple majority vote. The Board may add or remove members at any time it deems necessary.

Communication

  • Questions and suggestions for the Product Committee can be sent to productcom@lists.peeringdb.com
  • The committee will use a range of mechanisms for communication and community input gathering efforts, including the PeeringDB Governance Mailinglist pdb-gov@lists.peeringdb.com
  • Decisions, including their rationale, will be documented in GitHub issues
  • All issues and the product roadmap and feature backlog can be found at in GitHub issues

Decision policy

Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair.

PeeringDB Common Committee Charter Provisions:

Dispute resolution

If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.

Committee Chair and Vice Chair

The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.

Decision making process and workflow

Product Committee members are responsible for driving the development of PeeringDB. To do this, GitHub issues are used to track proposed and in progress work. Product Committee members play two roles in driving forward work:

1) As a shepherd - responsible for driving consensus for a given issue
2) As a stakeholder - voting on a consensus that has been reached

Each Product Committee member will choose issues to shepherd to a decision. They will indicate responsibility for this task by assigning the issue to themselves and placing it in the Decide queue.

To decide whether we act on a given issue that has been reported, a stakeholder group will be formed. This group will consist of Product Committee members, who are responsible for representing the users of PeeringDB. A stakeholder group on a given issue must consist of at least three Product Committee members, including the shepherding member.

Any Product Committee member can be a stakeholder in the decision on an issue. They become a stakeholder on a given issue by either commenting on the issue on GitHub or participating in discussion of the issue on the Product Committee Mailing list. It is up to the shepherding member to help reach a unanimous consensus within the stakeholder group on what should be done with the issue - including not acting on it. If and only if there are opposing views on how to proceed, and unanimous consensus cannot be reached by the stakeholder committee members, decisions fall to the entire Product Committee (see below).

The final proposal of how to resolve each issue, along with votes from stakeholders must be documented in the GitHub issue to be considered to have reached consensus. Product Committee members must document any offline discussion in the GitHub issue to ensure transparency of the discussion process.

Issues in the Decide queue are regularly reviewed by the Product Committee to make sure the most impactful issues are being moved along to resolution. All issues in the Decide queue will be reviewed in the monthly Product Committee call to ensure stakeholders have reached consensus and to give members who have not participated in the issue an opportunity to participate.

After an issue with consensus has been reviewed, Product Committee members who disagree with the proposal have five days after the monthly Product Committee call to vote against the proposed solution, otherwise the issue will move to the backlog.

For any issues where consensus cannot be reached, an issue may move forward only if a quorum of 50% or more of the Product Committee has no more than 25% of the quorum in opposition to the issue.

Meeting notes

2024

2023

2022

2021

2020

2019

2018

2017

Members

  • Jeff Bartig
  • Yan Berthier
  • Jack Carrozzo - Chair
  • Yolandi Cloete
  • Matt Griswold - Vice Chair
  • Martin Hannigan
  • Peter Helmenstine
  • Paul Hoogsteder
  • Aaron Hughes - Board Liaison
  • Laurent Jarbinet
  • Stephen McManus
  • Arnold Nipper
  • Terry Sweetser
  • Leo Vegoda - Product Manager