2
0
mirror of https://github.com/boostorg/website.git synced 2026-01-26 07:02:23 +00:00
Files
website/community/reviews.html
2013-12-18 15:58:38 -03:00

389 lines
16 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Boost Formal Review Process</title>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<link rel="icon" href="/favicon.ico" type="image/ico" />
<link rel="stylesheet" type="text/css" href=
"../style-v2/section-community.css" />
<!--[if IE]> <style type="text/css"> body { behavior: url(../style-v2/csshover.htc); } </style> <![endif]-->
</head><!--
Note: Editing website content is documented at:
http://www.boost.org/development/website_updating.html
-->
<body>
<div id="heading">
<!--#include virtual="/common/heading.html" -->
</div>
<div id="body">
<div id="body-inner">
<div id="content">
<div class="section" id="intro">
<div class="section-0">
<div class="section-title">
<h1>Boost Formal Review Process</h1>
</div>
<div class="admonition">
<h2>Before Requesting a Formal Review</h2>
<p><strong>Read and follow the Boost <a href=
"/development/submissions.html">submission
process</a>.</strong> There are at least four steps a library
author must take before a formal review is requested.</p>
</div>
<div class="section-body">
<ul class="toc">
<li><a href="#Introduction">Introduction</a></li>
<li><a href="#Comments">What to include in Review
Comments</a></li>
<li><a href="#Results">Results</a></li>
<li><a href="#Review_Manager">Notes for Review
Managers</a></li>
<li><a href="#Submitters">Notes for Library
Submitters</a></li>
<li><a href="#Maintainer">Library Maintainer's Rights and
Responsibilities</a></li>
<li><a href="#Wizard">Review Wizard</a></li>
<li><a href="#Fast-Track">Fast Track Reviews</a></li>
</ul>
<h2><a name="Introduction" id=
"Introduction"></a>Introduction</h2>
<p>Proposed libraries are accepted into Boost only after
undergoing a formal review, where Boost mailing list members
comment on their evaluation of the library.</p>
<p>The final "accept" or "reject" decision is made by the
<a href="#Review_Manager">Review Manager</a>, based on the
review comments received from boost mailing list members.</p>
<p>Boost mailing list members are encouraged to submit Formal
Review comments:</p>
<ul>
<li>Publicly on the mailing list.</li>
<li>Privately to the Review Manager.</li>
</ul>
<p>Private comments to a library submitter may be helpful to
her or him, but won't help the Review Manager reach a decision,
so the other forms are preferred.</p>
<h2><a name="Comments" id="Comments"></a>What to include in
Review Comments</h2>
<p>Your comments may be brief or lengthy, but basically the
Review Manager needs your evaluation of the library. If you
identify problems along the way, please note if they are minor,
serious, or showstoppers.</p>
<p>The goal of a Boost library review is to improve the library
through constructive criticism, and at the end a decision must
be made: is the library good enough at this point to accept
into Boost? If not, we hope to have provided enough
constructive criticism for it to be improved and accepted at a
later time. The Serialization library is a good example of how
constructive criticism resulted in revisions resulting in an
excellent library that was accepted in its second review.</p>
<p>Here are some questions you might want to answer in your
review:</p>
<ul>
<li>What is your evaluation of the design?</li>
<li>What is your evaluation of the implementation?</li>
<li>What is your evaluation of the documentation?</li>
<li>What is your evaluation of the potential usefulness of
the library?</li>
<li>Did you try to use the library? With what compiler? Did
you have any problems?</li>
<li>How much effort did you put into your evaluation? A
glance? A quick reading? In-depth study?</li>
<li>Are you knowledgeable about the problem domain?</li>
</ul>
<p>And finally, every review should answer this question:</p>
<ul>
<li>Do you think the library should be accepted as a Boost
library? Be sure to say this explicitly so that your other
comments don't obscure your overall opinion.</li>
</ul>
<p>Many reviews include questions for library authors. Authors
are interested in defending their library against your
criticisms; otherwise they would not have brought their library
up for review. If you don't get a response to your question
quickly, be patient; if it takes too long or you don't get an
answer you feel is sufficient, ask again or try to rephrase the
question. Do remember that English is not the native language
for many Boosters, and that can cause misunderstandings.</p>
<p>E-mail is a poor communication medium, and even if messages
rarely get lost in transmission, they often get drowned in the
deluge of other messages. Don't assume that an unanswered
message means you're being ignored. Given constructively,
criticism will be taken better and have more positive effects,
and you'll get the answers you want.</p>
<h2><a name="Results" id="Results"></a>Results</h2>
<p>At the conclusion of the comment period, the Review Manager
will post a message to the mailing list saying if the library
has been accepted or rejected. A rationale is also helpful, but
its extent is up to the Review Manager. If there are
suggestions, or conditions that must be met before final
inclusion, they should be stated.</p>
<h2><a name="Review_Manager" id="Review_Manager"></a>Notes for
Review Managers</h2>
<p>Before a library can be scheduled for formal review, an
active boost member not connected with the library submission
must volunteer to be the "Review Manager" for the library.</p>
<p>The Review Manager:</p>
<ul>
<li>Checks the submission to make sure it really is complete
enough to warrant formal review. See the <a href=
"/development/requirements.html">Boost Library Requirements
and Guidelines</a>. If necessary, work with the submitter to
verify the code compiles and runs correctly on several
compilers and platforms.</li>
<li>Finalizes the schedule with the <a href=
"#Wizard"></a>Review Wizard and the submitter.</li>
<li>Posts a notice of the review schedule on both the regular
<strong><a href="mailto:boost@lists.boost.org" class=
"external">boost mailing list</a></strong> and the
<strong><a href="mailto:boost-announce@lists.boost.org"
class="external">boost-announce</a> mailing list</strong>.
<ul>
<li>The notice should include a brief description of the
library and what it does, to let readers know if the
library is one they are interested in reviewing.</li>
<li>If the library is known to fail with certain
compilers, please mention them in the review notice so
reviewers with those compilers won't waste time
diagnosing known problems.</li>
</ul>
</li>
<li>Inspects the Boost <a href=
"/doc/libs/release/libs/libraries.htm">library catalogue</a>
for libraries which may interact with the new submission.
These potential interactions should be pointed out in the
review announcement, and the author(s) of these libraries
should be privately notified and urged to participate in the
review.</li>
<li>Urges people to do reviews if they aren't
forthcoming.</li>
<li>Follows review discussions regarding the library,
moderating or answering questions as needed.</li>
<li>Asks the <a href="#Wizard">review wizard</a> for
permission to extend the review schedule if it appears that
too few reviews will be submitted during the review
period.</li>
<li>Decides if there is consensus to accept the library, and
if there are any conditions attached.</li>
<li>Posts a notice of the <a href="#Results">review
results</a> on the regular <strong><a href=
"mailto:boost@lists.boost.org">boost</a></strong> mailing
list, the <strong><a href=
"mailto:boost-users@lists.boost.org">boost-users</a></strong>
mailing list, and the <strong><a href=
"mailto:boost-announce@lists.boost.org">boost-announce</a></strong>
mailing list.</li>
</ul>
<p>In other words, it is the Review Manager's responsibility to
make sure the review process works smoothly.</p>
<h2><a name="Submitters" id="Submitters"></a>Notes for Library
Submitters</h2>
<p>See <a href="/development/submissions.html">Submission
Process</a> for a description of the steps a library developer
goes through to get a library accepted by Boost.</p>
<p>A proposed library should remain stable during the review
period; it will just confuse and irritate reviewers if there
are numerous changes. It is, however, useful to upload fixes
for serious bugs right away, particularly those which prevent
reviewers from fully evaluating the library. Post a notice of
such fixes on the mailing list.</p>
<p>Library improvements suggested by reviewers should normally
be held until after the completion of review period. If the
suggested changes might affect reviewer's judgments, post a
notice of the pending change on the mailing list.</p>
<h2><a name="Maintainer" id="Maintainer"></a>Library
Maintainer's Rights and Responsibilities</h2>
<p>By submitting a library to boost, you accept responsibility
for maintaining your library or finding a qualified volunteer
to serve as maintainer. You must be willing to put your library
and documentation under a Boost-compatible license.</p>
<p>You will be expected to respond to reasonable bug reports
and questions in a timely manner and to participate as needed
in discussions of your library on the boost mailing lists.</p>
<p>You are free to change your library in any way you wish, and
you are encouraged to actively make improvements. However, peer
review is an important part of the Boost process and as such
you are also encouraged to get feedback from the boost
community before making substantial changes to the interface of
an accepted library.</p>
<p>If at some point you no longer wish to serve as maintainer
of your library, it is your responsibility to make this known
to the boost community and to find another individual to take
your place.</p>
<h2><a name="Wizard" id="Wizard"></a>Review Wizard</h2>
<p>The Review Wizard coordinates the formal review
schedule:</p>
<ul>
<li>Maintains a list of review manager volunteers, in the
form of a queue, so that volunteers who least recently
managed reviews become the prime candidates for upcoming
reviews.</li>
<li>When a formal review is requested for a library:
<ul>
<li>Assign a review manager and suggests a schedule,
after checking (via private email) availability of the
volunteers at the top of review manager queue.</li>
<li>Finalize the schedule, once the review manager
verifies the library is actually ready for review.</li>
<li>Resolve schedule slips or other issues with review
managers and submitters.</li>
</ul>
</li>
<li>Maintains a schedule of both past and pending reviews, in
the form of the <a href="review_schedule.html">Review
Schedule</a> web page.</li>
<li>Resolves questions from review managers and library
submitters, who sometimes want a third opinion on questions
such as "Should we extend the review period because
...?"</li>
<li>Monitors the general review process, and makes minor
adjustments as needed, or queries the list about possible
major adjustments.</li>
</ul>
<p>The role of Boost Review Wizard is currently played by John
Phillips (johnphillipsithaca at gmail dot com) and Ronald
Garcia (rxg at cs dot ubc dot ca).</p>
<h2><a name="Fast-Track" id="Fast-Track"></a>Fast Track
Reviews</h2>
<p>To qualify for fast track review:</p>
<ul>
<li>The component must be small.</li>
<li>The technique must be already in use in Boost libraries
and the new component provides a common implementation.</li>
<li>A full Boost-conformant implementation is available in
the sandbox.</li>
<li>The Review Wizard determines that the proposal qualifies
for fast track review.</li>
</ul>
<p>Procedure:</p>
<ul>
<li>The Boost Review Wizard posts a review announcement to
the main Boost developer's list. The review period will
normally last for 5 days. No two fast track reviews will run
in parallel. Fast track reviews may run during full reviews,
though generally this is to be avoided.</li>
<li>After the review period ends, the submitter will post a
review summary containing proposed changes to the reviewed
implementation.</li>
<li>The Review Wizard will accept or reject the proposed
library and proposed changes.</li>
<li>After applying the proposed changes, the component is
checked into the repository like any other library.</li>
</ul>
</div>
</div>
</div>
</div>
<div id="sidebar">
<!--#include virtual="/common/sidebar-common.html" -->
<!--#include virtual="/common/sidebar-community.html" -->
</div>
<div class="clear"></div>
</div>
</div>
<div id="footer">
<div id="footer-left">
<div id="revised">
<p>Revised $Date$</p>
</div>
<div id="copyright">
<p>Copyright Beman Dawes, 2000.</p>
</div><!--#include virtual="/common/footer-license.html" -->
</div>
<div id="footer-right">
<!--#include virtual="/common/footer-banners.html" -->
</div>
<div class="clear"></div>
</div>
</body>
</html>