PeeringDB Product Committee
- Purpose is to study and recommend feature needs.
- Interested in volunteering? Contact email@example.com.
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.
New Issues are evaluated to confirm they are legitimate, which may require asking the reporter for feedback. Issues that cannot be reproduced or where the solution is unclear are moved to Review. Moving from New Issues to Backlog does not need much discussion as it is easy to move the issue back or mark it as
Once an issue is determined to be valid and coherent with the product vision, it is moved to Backlog and labeled as either bug or enhancement. If the issue is considered not to be coherent with the product vision, it will be marked as
wontfix; the requester always has the option to forward his issue to the PeeringDB board if she disagrees with the assessment by the Product Committee.
If an issue is labeled as a bug, the severity will determine how it will be resolved. P1/P2 bugs are considered service impacting and will be treated by the software vendor under the maintenance agreement, P3/P4 bugs will be treated as product enhancement requests.
Once Product Committee, with developer involvement, decides that no more information is needed to be able to fix/implement an issue, it can move to PC Candidates, with a rough estimate. PC Candidates should be ordered with more important higher in the list.
Depending on the effort required to implement the issue, development will be done either on project basis or as part of the maintenance agreement. The Product Committee follows a budget release process to fund project based development efforts. Developments that fall within the budget envelope allocated to the Product Committee require no further approval by the board, however 75% of the Product Committee members must agree.
Sprint is the column that is next in the pipeline, encompassing everything that is approved to work on, so development starts immediately. This would be decided by the Product Committee.
All other PeeringDB projects also go through this issue board to decide on priority. For example, when something for peeringdb-py goes into a sprint, an issue will be made on the peeringdb-py project and accessed by the main board.
Done means the issue is completed in development and will be pushed to beta for review. Issues are not Closed until they are deployed to production
- March 21st, 2017: Meeting Notes
- April 13th, 2017: Meeting Notes
- June 1st, 2017: Meeting Notes
- July 6th, 2017: Meeting Notes
- August 3rd, 2017: Meeting Notes
- October 12th, 2017: Meeting Notes
- Eric Loos (Chair)
- Matt Griswold (Vice Chair)
- Karthik Arumugham
- Greg Hankins
- Aaron Hughes
- Martin J. Levy
- Stephen McManus
- Arnold Nipper
- Chris Phillips
- Kay Rechthien
- Bijal Sanghani
- Job Snijders