The below is a mildly edited document (mostly to remove details on a git
based way of implementing what is now left as "TODO: Archive full review
case documents somewhere?") of something I wrote _years_ ago.
I sent essentially this to Martin Winter on the 20th of January,
**2015**, and he _rejected_ it.
If/when it is appropriate, this will be the basis for technical
governance here.
--paul
# Quagga Technical Steering Committee (QTSC) Charter
******************************************************
# Overview
The Quagga Technical Steering Committee (QTSC) steers the technical and
architectural direction of Quagga according to the Objectives of the
project, on the authority devolved to it by the founder.
All technical changes to the Quagga software must have QTSC approval,
explicit or implicit. Many proposed changes will raise no architectural
concerns, and so need no more than a no-overhead, cursory "fast track"
review. A few changes may require a "full" review by QTSC..
Membership of the QTSC is open to all those in good standing in the Quagga
community, who have made useful technical contributions to the project and
have demonstrated the requisite people skills, as judged by the existing
members. Anyone wishing to sit on the QTSC is invited to introduce
themselves to a QTSC member (on or off list) and ask to be considered.
Note: Contributing reviews of the code contributions of others is a very
valuable technical contribution to the project.
QTSC discussions should generally be conducted in public. _All_ Quagga
community members are welcome to participate in these discussions. However,
non-QTSC-members should refrain from voting.
# Members of the QTSC {#members}
* [Paul Jakma](mailto:paul@jakma.org)
# Former members
# Functions of the QTSC
The QTSC exists to review and approve all changes to Quagga for
architectural consistency and soundness. The QTSC develops the processes
and documentation needed to support this, and assists those contributors
seeking a review.
The QTSC may appoint people to carry out integration duties, and devolve
other powers as it sees fit.
QTSC reviews and approval processes fall into two categories:
* Fast-track (see [Fast-track Review](#fasttrackreview))
* Full (see [Full Review](#fullreview))
Pending proposals to the QTSC are triaged by a QTSC member, who will direct
them the correct process.
Contributors may pre-emptively apply for a full-review, if they believe it
may be required. In particular, for more complicated changes with
architectural impact, the contributor may wish to file for a review _before_
any significant implementation to obtain approval on the direction in
advance.
Formal voting may not always be necessary, but can occur as described in
[Voting](#voting).
## Fast-track review {#fasttrackreview}
The fast-track review is a very light-weight process, and is the default
process for any contributions. No action is required for this process from
contributors.
Fast-track allows bug-fixes and other clearly minimal-architectural impact
proposed commits to Quagga to be quickly approved with the minimum of
intervention.
Any QTSC member may assign a new proposal fast-track status, if they
do not see any architectural concerns. Any other QTSC member may reassign
such a proposal from fast-track to full review.
A new proposal is assigned to fast-track review by queueing the patch
onto the FASTTRACKBRANCH branch in Quagga git.
At intervals a motion is put to the QTSC to approve all outstanding
fast-track contributions for merging to the Quagga 'master' branch. The
motion should give an overview of the commits (e.g. using _"git log
--abbrev-commit --pretty=oneline"_), and the voting deadline should be at
least 7 days.
The motion is carried if no there are no opposing votes. In which case the
FASTTRACKBRANCH should be merged to 'master' by one of the integrators.
Any QTSC member may change the status of a contribution from fasttrack to
full, by moving the commit from the FASTTRACKBRANCH branch to the
REVIEWBRANCH branch.
A QTSC member who changes a contribution from fast-track to full review must
ensure the contributors are informed to ensure the contributors know they
are required to prepare a full review.
## Full review {#fullreview}
The Full review approval is a more thorough process. The full review
required where a QTSC member believes a contribution has architectural or
other concerns that require the contributor to present the case for their
favoured option, including a comparison with the alternatives.
Changes to the following areas, in particular, would very likely raise
architectural concerns and so require full-review:
* Quagga Library APIs
* The ZServ protocol
* User visible UI, e.g. configuration or monitoring.
* Interactions between different daemons or sub-systems in Quagga
* The high-level arrangement of functionality within Quagga
The contributor must prepare a review document, using
governance/qtsc-review-template.txt. This is submitted to the QTSC, via a
shepherding member.
A QTSC member creates a full review case by emailing the review document to
list with the subject prefixed with "QTSC Review YMD.STRING:", where YMD is a
'%Y%m%d' discussion timeout, and STRING is an arbitrary short label to
identify the case. A timeout of at least 2 weeks is required for full
reviews. The QTSC (and any other interested parties) should discuss the
case with the contributor.
If there is a code contribution, this should be queued onto the REVIEWBRANCH
branch in git.
Once the indicated discussion timeout is reached, a motion should be put to
the QTSC to either:
* Approve the case
* Require modifications to the proposal
* Extend the discussion
* Reject the case
A case may be rejected by MIN(1/3rd, 2) of responding members. Otherwise, it
may be approved by a majority vote of responding members.
Requiring modifications be made to the case may be approved by a majority of
the responding members. Extending the discussion may be approved by a
majority of the responding members, with further discussion taking place
under the new time-out.
In cases where the contributor is asked to make updates, the contributor
must be informed.
TODO: Archive full review case documents somewhere?
## Housekeeping
The following tasks must be carried out:
* Pending requests to the QTSC must be triaged, where those requests do not
already have an interested member shepherding them.
* Votes on motions should be tallied once the voting deadline has been
reached, should the mover fail to.
* The pending fasttrack contributions must be sent out, approved and
integrated regularly.
* Full review cases should have their status tracked (Bugzilla, files in
git, email, etc.).
The QTSC should develop adequate processes, and assign a secretary to carry
out these tasks.
# Changes to this charter
This charter may be changed by a unanimous vote of responding members,
provided that a months notice of the motion is given to all members and that
the voting is left open for at least 14 days there-after.
# Motions and voting {#voting}
Motions to be put to the QTSC must be sent to the
[Quagga-dev](https://lists.quagga.net/mailman/listinfo/quagga-dev) email
list, with the subject prefixed with "QTSC Motion: ", and must state a
deadline for the vote on the motion in the beginning of the email in GMT.
Movers may withdraw their motion by replying to their original motion email
and prefixing "Withdraw: " to the Subject line. The body may be left empty,
or otherwise must explicitly state the motion is withdrawn at the beginning.
Movers are assumed to support their own motion. Remaining QTSC members vote
on motions by replying to the original motion email, retaining the subject
line and prefixing it with "Vote: " and then indicating their view by one of
the following means as the only word on the first line of the email:
Support the motion:
* Yes
* Aye
* +1
* Ack
Oppose the motion:
* No
* Nay
* -1
* Nack
Neutral:
* Neutral
* 0
Motions and ammendments should generally be discussed prior to voting. This
should be done by replying normally to the original "QTSC Motion" email or
any email in a thread there-of.
The mover is required to tally the votes on their motion once the voting
deadline has passed, and announce the result in a reply to their Motion
email.
Superflous automated prefixes (e.g. "Re: ", "[quagga-dev]", etc.) may be
stripped at the sender's discretion.
regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Philogyny recapitulates erogeny; erogeny recapitulates philogyny.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
based way of implementing what is now left as "TODO: Archive full review
case documents somewhere?") of something I wrote _years_ ago.
I sent essentially this to Martin Winter on the 20th of January,
**2015**, and he _rejected_ it.
If/when it is appropriate, this will be the basis for technical
governance here.
--paul
# Quagga Technical Steering Committee (QTSC) Charter
******************************************************
# Overview
The Quagga Technical Steering Committee (QTSC) steers the technical and
architectural direction of Quagga according to the Objectives of the
project, on the authority devolved to it by the founder.
All technical changes to the Quagga software must have QTSC approval,
explicit or implicit. Many proposed changes will raise no architectural
concerns, and so need no more than a no-overhead, cursory "fast track"
review. A few changes may require a "full" review by QTSC..
Membership of the QTSC is open to all those in good standing in the Quagga
community, who have made useful technical contributions to the project and
have demonstrated the requisite people skills, as judged by the existing
members. Anyone wishing to sit on the QTSC is invited to introduce
themselves to a QTSC member (on or off list) and ask to be considered.
Note: Contributing reviews of the code contributions of others is a very
valuable technical contribution to the project.
QTSC discussions should generally be conducted in public. _All_ Quagga
community members are welcome to participate in these discussions. However,
non-QTSC-members should refrain from voting.
# Members of the QTSC {#members}
* [Paul Jakma](mailto:paul@jakma.org)
# Former members
# Functions of the QTSC
The QTSC exists to review and approve all changes to Quagga for
architectural consistency and soundness. The QTSC develops the processes
and documentation needed to support this, and assists those contributors
seeking a review.
The QTSC may appoint people to carry out integration duties, and devolve
other powers as it sees fit.
QTSC reviews and approval processes fall into two categories:
* Fast-track (see [Fast-track Review](#fasttrackreview))
* Full (see [Full Review](#fullreview))
Pending proposals to the QTSC are triaged by a QTSC member, who will direct
them the correct process.
Contributors may pre-emptively apply for a full-review, if they believe it
may be required. In particular, for more complicated changes with
architectural impact, the contributor may wish to file for a review _before_
any significant implementation to obtain approval on the direction in
advance.
Formal voting may not always be necessary, but can occur as described in
[Voting](#voting).
## Fast-track review {#fasttrackreview}
The fast-track review is a very light-weight process, and is the default
process for any contributions. No action is required for this process from
contributors.
Fast-track allows bug-fixes and other clearly minimal-architectural impact
proposed commits to Quagga to be quickly approved with the minimum of
intervention.
Any QTSC member may assign a new proposal fast-track status, if they
do not see any architectural concerns. Any other QTSC member may reassign
such a proposal from fast-track to full review.
A new proposal is assigned to fast-track review by queueing the patch
onto the FASTTRACKBRANCH branch in Quagga git.
At intervals a motion is put to the QTSC to approve all outstanding
fast-track contributions for merging to the Quagga 'master' branch. The
motion should give an overview of the commits (e.g. using _"git log
--abbrev-commit --pretty=oneline"_), and the voting deadline should be at
least 7 days.
The motion is carried if no there are no opposing votes. In which case the
FASTTRACKBRANCH should be merged to 'master' by one of the integrators.
Any QTSC member may change the status of a contribution from fasttrack to
full, by moving the commit from the FASTTRACKBRANCH branch to the
REVIEWBRANCH branch.
A QTSC member who changes a contribution from fast-track to full review must
ensure the contributors are informed to ensure the contributors know they
are required to prepare a full review.
## Full review {#fullreview}
The Full review approval is a more thorough process. The full review
required where a QTSC member believes a contribution has architectural or
other concerns that require the contributor to present the case for their
favoured option, including a comparison with the alternatives.
Changes to the following areas, in particular, would very likely raise
architectural concerns and so require full-review:
* Quagga Library APIs
* The ZServ protocol
* User visible UI, e.g. configuration or monitoring.
* Interactions between different daemons or sub-systems in Quagga
* The high-level arrangement of functionality within Quagga
The contributor must prepare a review document, using
governance/qtsc-review-template.txt. This is submitted to the QTSC, via a
shepherding member.
A QTSC member creates a full review case by emailing the review document to
list with the subject prefixed with "QTSC Review YMD.STRING:", where YMD is a
'%Y%m%d' discussion timeout, and STRING is an arbitrary short label to
identify the case. A timeout of at least 2 weeks is required for full
reviews. The QTSC (and any other interested parties) should discuss the
case with the contributor.
If there is a code contribution, this should be queued onto the REVIEWBRANCH
branch in git.
Once the indicated discussion timeout is reached, a motion should be put to
the QTSC to either:
* Approve the case
* Require modifications to the proposal
* Extend the discussion
* Reject the case
A case may be rejected by MIN(1/3rd, 2) of responding members. Otherwise, it
may be approved by a majority vote of responding members.
Requiring modifications be made to the case may be approved by a majority of
the responding members. Extending the discussion may be approved by a
majority of the responding members, with further discussion taking place
under the new time-out.
In cases where the contributor is asked to make updates, the contributor
must be informed.
TODO: Archive full review case documents somewhere?
## Housekeeping
The following tasks must be carried out:
* Pending requests to the QTSC must be triaged, where those requests do not
already have an interested member shepherding them.
* Votes on motions should be tallied once the voting deadline has been
reached, should the mover fail to.
* The pending fasttrack contributions must be sent out, approved and
integrated regularly.
* Full review cases should have their status tracked (Bugzilla, files in
git, email, etc.).
The QTSC should develop adequate processes, and assign a secretary to carry
out these tasks.
# Changes to this charter
This charter may be changed by a unanimous vote of responding members,
provided that a months notice of the motion is given to all members and that
the voting is left open for at least 14 days there-after.
# Motions and voting {#voting}
Motions to be put to the QTSC must be sent to the
[Quagga-dev](https://lists.quagga.net/mailman/listinfo/quagga-dev) email
list, with the subject prefixed with "QTSC Motion: ", and must state a
deadline for the vote on the motion in the beginning of the email in GMT.
Movers may withdraw their motion by replying to their original motion email
and prefixing "Withdraw: " to the Subject line. The body may be left empty,
or otherwise must explicitly state the motion is withdrawn at the beginning.
Movers are assumed to support their own motion. Remaining QTSC members vote
on motions by replying to the original motion email, retaining the subject
line and prefixing it with "Vote: " and then indicating their view by one of
the following means as the only word on the first line of the email:
Support the motion:
* Yes
* Aye
* +1
* Ack
Oppose the motion:
* No
* Nay
* -1
* Nack
Neutral:
* Neutral
* 0
Motions and ammendments should generally be discussed prior to voting. This
should be done by replying normally to the original "QTSC Motion" email or
any email in a thread there-of.
The mover is required to tally the votes on their motion once the voting
deadline has passed, and announce the result in a reply to their Motion
email.
Superflous automated prefixes (e.g. "Re: ", "[quagga-dev]", etc.) may be
stripped at the sender's discretion.
regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Philogyny recapitulates erogeny; erogeny recapitulates philogyny.
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev