PeeringDB Product Committee


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

Deliverables

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

Decision Policy

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


Workflow

Diagram of Workflow

The development roadmap is tracked using GitHub issues located at https://github.com/peeringdb/peeringdb/issues with the ZenHub overlay.

All members of the Product Committee take part in a Hot Seat schedule with a weekly rotation in order to monitor incoming github issues and ensure the follow-up of existing issues until they are either closed as non-implemented or moved to the backlog.

New Issues are evaluated to confirm that they are valid and coherent with the product vision, which may require asking the reporter for feedback. Issues that cannot be reproduced or where the solution is unclear are moved to Review. While in Review issues are discussed by the community and the Product Committee until a solution is determined.

Simple issues that do not require much discussion or have an obvious solution move directly to Backlog. Once in Backlog the issue can be returned to Review or Decide if necessary. The issue can also be marked as wontfix later.

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 their issue to the PeeringDB board if they disagree with the assessment by the Product Committee.

The product committee makes the final decision on how each issue is handled. If there are multiple ways to solve an issue it moves to Decide and the Product Committee then votes on the way to handle the issue. When the vote has been made the issue is moved to Backlog.

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.

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 and it is moved to In Progress by the developer. This would be decided by the Product Committee.

Every member of the Product Committee may label one issue a month as PC Candidate. An issues labeled as PC Candidate must have a solution for development fully specified within the Github issue before it can be considered for implementation. Once it is agreed with the developer that no more information is needed to be able to fix/implement an issue, it can be proposed for inclusion in the next sprint to the Product Committee mailing-list. The Product Committee (Vice) Chair will move the agreed upon issues to the Sprint column.

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 beta.

Meeting Notes

Members

Product Marketing and Community Outreach (non-voting member)