mirror of
https://github.com/boostorg/website.git
synced 2026-01-19 04:42:17 +00:00
383 lines
18 KiB
HTML
383 lines
18 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 Library Submission Process</title>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<link rel="icon" href="/favicon.ico" type="image/ico" />
|
|
<link rel="stylesheet" type="text/css" href=
|
|
"/style-v2/section-development.css" />
|
|
<!--[if IE 7]> <style type="text/css"> body { behavior: url(/style-v2/csshover3.htc); } </style> <![endif]-->
|
|
<script defer data-domain="original.boost.org" src="https://plausible.io/js/script.js"></script></head><!--
|
|
Note: Editing website content is documented at:
|
|
https://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 Library Submission Process</h1>
|
|
</div>
|
|
|
|
<div class="section-body">
|
|
<p>This page describes the process a library developer goes
|
|
through to get a library accepted by Boost.</p>
|
|
|
|
<p>See the <a href="requirements.html">Boost Library
|
|
Requirements and Guidelines</a> page for issues of content.</p>
|
|
|
|
<h3>Steps for getting a library accepted by Boost:</h3>
|
|
|
|
<ul class="toc">
|
|
<li>
|
|
<a href="#Learn">1. Learn about Boost</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#interest">2. Determine interest</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#Development">3. Start Development</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#Refinement">4. Refinement</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#Seconded">5. Getting seconded for review</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#Seeking">6. Seek a Review Manager</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#Review">7. Formal Review</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#SitePosting">8. Web site posting</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#People">9. People page</a>
|
|
</li>
|
|
|
|
<li>
|
|
<a href="#Lifecycle">10. Lifecycle</a>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a name="Learn" id="Learn"></a>1. Learn about Boost</h2>
|
|
|
|
<p>Follow posts on the <a href="/community/groups.html#main">main
|
|
developers mailing list</a> for a while, or look through the
|
|
<a href="/community/groups.html#archive">archives</a>. Explore
|
|
the <a href="/">web site</a>. Learn the <a href=
|
|
"requirements.html">Requirements</a>. Read the rest of this
|
|
page to learn about the process. Search the web to get an idea
|
|
of the commitment required to get a library into Boost.
|
|
</p>
|
|
|
|
<p>There is a culture associated with Boost, aimed at
|
|
encouraging high quality libraries by a process of discussion
|
|
and refinement. Some libraries get past community review
|
|
in less than two years from first concept, but most take longer,
|
|
sometimes a lot longer. Five to ten years to get a library past
|
|
review and into Boost is not unheard of, and you should prepare
|
|
yourself for the personal investment required.</p>
|
|
|
|
|
|
<h2><a name="interest" id="interest"></a>2. Determine
|
|
interest</h2>
|
|
|
|
<p>While participation in reviews for other submissions is not a
|
|
prerequisite for submitting a library to Boost, it is highly
|
|
recommended; it will acquaint you with the process and the
|
|
emotional demands of a formal review. There's nothing that quite
|
|
deflates the ego like having brilliant members of the C++
|
|
community critiquing your work, but, alas, it's worth it!</p>
|
|
|
|
<p>Potential library submitters should be careful to
|
|
research the prior art before beginning to design a
|
|
new library. Unfortunately, now and then folks arrive at Boost
|
|
with a new library into which they have invested many hours, only
|
|
to find that Boost already has that functionality, and sometimes
|
|
has had it for years. Candidates should also research libraries being
|
|
developed by others intended for Boost - if you have an itch
|
|
to scratch, often so have had others and collaboration
|
|
developing their library is usually considerably more efficient
|
|
than going at it alone.</p>
|
|
|
|
<p>Potential library submitters should also be careful to
|
|
publicise, canvas for, and gauge interest in their library,
|
|
ideally before beginning it, but certainly before submitting it
|
|
for review. Even a superbly designed library can fail review if
|
|
there isn't enough interest in the subject matter; We can only
|
|
review libraries with enough appeal to form a viable peer
|
|
review. Ensuring that enough people are interested in your
|
|
potential library goes a long way to ensure that.</p>
|
|
|
|
<p>There are many places to publicise and canvas for a library.
|
|
The Boost developers <a href="/community/groups.html">mailing
|
|
list</a> ought to be your first stop in gauging interest
|
|
in a possible new C++ library. Be prepared to pivot your design
|
|
and focus until your proposed library finds traction. Other
|
|
places useful for gauging interest in a library might be <a href=
|
|
"https://www.reddit.com/r/cpp/">Reddit/r/cpp</a>.</p>
|
|
|
|
<p>A message to the Boost developers mailing list
|
|
might be as simple as "Is there any interest in a
|
|
library which solves Travelling Salesperson problems in linear
|
|
time?"</p>
|
|
|
|
<p>A bit of further description or snippet of code may be
|
|
helpful. By the way, the preferred format for messages on the
|
|
mailing list is plain text; not rich text, HTML, etc.</p>
|
|
|
|
<p>Avoid posting lengthy descriptions, documentation,
|
|
or code to the mailing list, and, please, no attachments.
|
|
The best place to provide lengthy material is via. a web link.
|
|
Project hosting services such as sourceforge, github, google
|
|
code, and bitbucket serve well for this purpose.</p>
|
|
|
|
|
|
<h2><a name="Development" id="Development"></a>3. Start
|
|
Development</h2>
|
|
|
|
<p>If response to an initial query indicates interest, then
|
|
by all means make your library publicly available if you haven't
|
|
already done so.</p>
|
|
|
|
<p>Please commit your code to a version control system such as
|
|
Git, and make your documentation available in HTML format on
|
|
a public website such as Github. An issue tracker such as the one
|
|
provided by Github is also highly recommended.</p>
|
|
|
|
<p>Your library should contain material as if it were on the
|
|
boost.org web site. The closer your library reflects the
|
|
final directory structure and format of the web site, the
|
|
better. This makes it possible for reviewers to simply copy
|
|
your code into the Boost distribution for testing.</p>
|
|
|
|
<p>Please verify that your library compiles and runs under
|
|
at least two compilers. This flushes out obvious portability
|
|
problems.</p>
|
|
|
|
<p>It is recommended that you release your code under the Boost
|
|
Software License; see the <a href=
|
|
"requirements.html">Requirements</a> page for more
|
|
information.</p>
|
|
|
|
|
|
<h2><a name="Refinement" id="Refinement"></a>4. Refinement</h2>
|
|
|
|
<p>Discuss, refine, rewrite. Repeat until satisfied.</p>
|
|
|
|
<p>The exact details of this process varies a lot. Usually it
|
|
is public, on the mailing list, but frequently discussion
|
|
happens in private emails. For some libraries the process is
|
|
over quickly, but for others it goes on for months. It's
|
|
often challenging, and sometimes veers into completely
|
|
unexpected directions.</p>
|
|
|
|
<p>The <a href="/community/groups.html#archive">archive</a> of
|
|
past messages is one way to see how this process worked for
|
|
other Boost libraries.</p>
|
|
|
|
<p>To get an idea of best practices with some samples of script
|
|
and code in existing Boost libraries, see the
|
|
<a href="https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook">
|
|
Best Practices Handbook</a> on the Boost wiki.</p>
|
|
|
|
|
|
<h2><a name="Seconded" id="Seconded"></a>5. Getting seconded
|
|
for review</h2>
|
|
|
|
<p>When you feel that your library is ready for entry into Boost,
|
|
you need to find at least one member (but preferably several) of
|
|
the Boost community who is willing to publicly endorse your
|
|
library for entry into Boost. A simple method of achieving this
|
|
is to post to <a href="/community/groups.html">the Boost
|
|
developers mailing list</a> a short description of your
|
|
library, links to its github and documentation, and a request for
|
|
endorsements.</p>
|
|
|
|
<p>It is expected that those who endorse a library for review
|
|
will have performed at least a cursory check of the library's
|
|
suitability for Boost in terms of documentation, fit with
|
|
the rest of Boost and usefulness. A public endorsement of a
|
|
library for review means that from an initial glance, they
|
|
believe that the library has a reasonable chance to be accepted
|
|
during a formal review. The expectation is that these endorsers
|
|
will themselves review of the library during formal review
|
|
period, though this is not binding.</p>
|
|
|
|
<p>Once you have a list of people who have publicly endorsed
|
|
your library for review, email <a
|
|
href="/community/reviews.html#Wizard">the Review Wizards</a>
|
|
to request that your library be added to <a
|
|
href="/community/review_schedule.html">the review queue</a>
|
|
where the following information will be shown:</p>
|
|
|
|
<ul>
|
|
<li>Submission</li>
|
|
<li>Submitter</li>
|
|
<li>Links to Source (GitHub), Documentation (HTML website)
|
|
and any Incubator entry</li>
|
|
<li>Names of members who endorse this submission for review</li>
|
|
<li>Review Manager</li>
|
|
<li>Review Dates</li>
|
|
</ul>
|
|
|
|
<p>
|
|
<span>⚠</span> In order to avoid any conflicts of interest a potential
|
|
review manager is expected to disclose to the Boost Community if they have
|
|
any relationship to the author of the library or the library itself.
|
|
</p>
|
|
|
|
<h2><a name="Seeking" id="Seeking"></a>6. Seek a Review
|
|
Manager</h2>
|
|
|
|
<p>In order to schedule a formal review, the author must find a
|
|
capable volunteer to manage the review. This should be someone
|
|
with knowledge of the library domain, and experience with the
|
|
review process. See <a href="/community/reviews.html">Formal
|
|
Review Process</a> for the responsibilities of the review
|
|
manager.</p>
|
|
|
|
<p>Authors can find community members interested in managing
|
|
reviews through discussion of the library on the developer
|
|
list. If no one steps forward to volunteer to manage the
|
|
review, it is appropriate to contact an experienced Boost
|
|
member who showed interest in the library. Be considerate that
|
|
managing a review is a serious commitment; for this reason,
|
|
it's better to contact the member off-list.</p>
|
|
|
|
<p>If you cannot find a review manager after 3 weeks using the
|
|
means above, and your submission is targeting eventual
|
|
standardization, there is a list of Boost regulars who are also
|
|
WG21 committee members who have volunteered to act as review
|
|
managers in such cases. Please try them in the order listed.
|
|
They are: Zach Laine, Micheal Caisse, Matt Calabrese, Edward
|
|
Diener, Louis Dionne, Vinnie Falco, Glen Fernandes, and David
|
|
Sankel.</p>
|
|
|
|
<p>Once a potential review manager has been identified, <a
|
|
href="/community/reviews.html#Wizard">contact the
|
|
review wizards</a> for approval. The wizards approve review
|
|
managers based on their level of participation in the Boost
|
|
community.</p>
|
|
|
|
<p>The review wizards will coordinate with both the author and
|
|
review manager to schedule a date convenient for both.</p>
|
|
|
|
<p>See <a href="/community/reviews.html">Formal Review
|
|
Process</a> for details.</p>
|
|
|
|
|
|
<h2><a name="Review" id="Review"></a>7. Formal Review</h2>
|
|
|
|
<p>Before your formal review begins, double-, triple-, and
|
|
quadruple-check your library. Verify that every code example
|
|
works, that all unit tests pass on at least two compilers on at
|
|
least two major operating systems, and run your documentation
|
|
through a spelling and grammar checker.</p>
|
|
|
|
<p>Please do not modify your library on its master branch
|
|
during a review. Instead, modify a separate develop branch in
|
|
response to feedback and reviews. For bigger ticket items of
|
|
work, open issues on your issue tracker so interested people can
|
|
track the fixing of specific issues raised.</p>
|
|
|
|
<p>The review manager will consider all the reviews made by
|
|
members of the community and arrive at a decision on
|
|
whether your library is rejected, conditionally accepted or
|
|
unconditionally accepted. They will post a report summarising
|
|
the decision publicly. If conditions are attached to
|
|
acceptance, you will need to implement those conditions or
|
|
else undergo an additional formal review.</p>
|
|
|
|
|
|
<h2><a name="SitePosting" id="SitePosting"></a>8. Boost web site
|
|
posting</h2>
|
|
|
|
<p>Once an accepted library is ready for inclusion on the Boost
|
|
web site, the submitter is typically given Boost repository
|
|
write access, and expected to check-in and maintain the library
|
|
there. Contact the moderators if you need write access or
|
|
direct use of the repository isn't possible for you.</p>
|
|
|
|
|
|
<h2><a name="People" id="People"></a>9. People page</h2>
|
|
|
|
<p>If the boost.org web site doesn't already have your capsule
|
|
biography and picture (optional, with not-too-serious pictures
|
|
preferred!), please send them to the Boost webmaster. It is up
|
|
to you as to whether or not the biography includes your email
|
|
address or other contact information. The preferred picture
|
|
format is .jpg, but other common formats are acceptable. The
|
|
preferred image size is 500x375 but the webmaster has photo
|
|
editing software and can do the image preparation if
|
|
necessary.</p>
|
|
|
|
|
|
<h2><a name="Lifecycle" id="Lifecycle"></a>10. Lifecycle</h2>
|
|
|
|
<p>Libraries are software; they lose their value over time if
|
|
not maintained. Postings on the Boost developers or users
|
|
mailing lists can alert you to potential maintenance needs;
|
|
please plan to maintain your library over time. If you no
|
|
longer can or wish to maintain your library, please post a
|
|
message on the Boost developers mailing list asking for a new
|
|
maintainer to volunteer and then spend the time to help them
|
|
take over.</p>
|
|
|
|
<p>Orphaned libraries will be put in the care of the <a href=
|
|
"https://svn.boost.org/trac/boost/wiki/CommunityMaintenance">Community
|
|
Maintenance Team</a>.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div id="sidebar">
|
|
<!--#include virtual="/common/sidebar-common.html" -->
|
|
<!--#include virtual="/common/sidebar-development.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>
|