PeeringDB Product Committee
- Purpose is to study and recommend feature needs.
- Interested in volunteering? Contact email@example.com.
PeeringDB Product Committee Charter
Approved by Board July 7th, 2017
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.
- 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 evangelisation 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.
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.
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.
- Questions and suggestions for the Product Committee can be sent to firstname.lastname@example.org
- Key development communication and community input gathering efforts will be conducted via the PeeringDB Governance Mailinglist email@example.com
- All issues and the product roadmap and feature backlog can be found at https://github.com/peeringdb/peeringdb/issues
Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair.
PeeringDB Common Committee Charter Provisions:
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.
- May 6th, 2021: Meeting Notes
- April 1st, 2021: Meeting Notes
- March 11th, 2021: Meeting Notes
- February 4th, 2021: Meeting Notes
- January 7th, 2021: Meeting Notes
- December 3rd, 2020: Meeting Notes
- November 5th, 2020: Meeting Notes
- October 1st, 2020: Meeting Notes
- September 3rd, 2020: Meeting Notes
- August 6th, 2020: Meeting Notes
- July 2nd, 2020: Meeting Notes
- June 4th, 2020: Meeting Notes
- May 7th, 2020: Meeting Notes
- April 2nd, 2020: Meeting Notes
- February 6th, 2020: Meeting Notes
- January 9th, 2020: Meeting Notes
- November 14th, 2019: Meeting Notes
- October 3rd, 2019: Meeting Notes
- September 5th, 2019: Meeting Notes
- August 8th, 2019: Meeting Notes
- July 11th, 2019: Meeting Notes
- June 7th, 2019: Meeting Notes
- May 2nd, 2019: Meeting Notes
- March 7th, 2019: Meeting Notes
- February 7th, 2019: Meeting Notes
- January 3rd, 2019: Meeting Notes
- December 6th, 2018: Meeting Notes
- November 1st, 2018: Meeting Notes
- October 4th, 2018: Meeting Notes
- September 6th, 2018: Meeting Notes
- July 5th, 2018: Meeting Notes
- June 7th, 2018: Meeting Notes
- April 5th, 2018: Meeting Notes
- March 14th, 2018: Meeting Notes
- January 4th, 2018: Meeting Notes
- December 7th, 2017: Meeting Notes
- October 12th, 2017: Meeting Notes
- August 3rd, 2017: Meeting Notes
- July 6th, 2017: Meeting Notes
- June 1st, 2017: Meeting Notes
- April 13th, 2017: Meeting Notes
- March 21st, 2017: Meeting Notes
- Yan Berthier
- Kayla Clifford
- Matt Griswold (Vice Chair)
- Greg Hankins (Outreach Liaison)
- Martin Hannigan
- Aaron Hughes (Board Liaison)
- Stephen McManus (Chair)
- Arnold Nipper
- Yolandi Robinson
- Job Snijders
- Leo Vegoda (Product Manager)