mirror of
https://github.com/boostorg/website.git
synced 2026-02-14 01:12:09 +00:00
373 lines
17 KiB
HTML
373 lines
17 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]-->
|
|
</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 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>Subscribe to 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>. Click
|
|
around the <a href="/">web site</a>. Understand the <a href=
|
|
"requirements.html">Requirements</a>. Read the rest of this
|
|
page to learn about the process. Do some research on google
|
|
to study 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 being struck, 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 prior reviews is not a prerequisite
|
|
for submitting a library to Boost, it is highly recommended
|
|
because it will acquaint you with the process and the emotional
|
|
demands of a formal review.</p>
|
|
|
|
<p>Potential library submitters should be careful to
|
|
research the prior art before beginning to design a
|
|
new library. Too often we see people 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. They 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 less work
|
|
than developing your own.</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. One can build a beautiful cathedral of awesome design,
|
|
but due to the nature of the Boost review procees, we can only
|
|
review libraries with enough mass appeal to form a viable peer
|
|
review. Ensuring that enough people are interested in your
|
|
potential library goes a very long way to achieving 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> and the <a href="http://blincubator.com">Boost Library
|
|
Incubator</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. Messages should be plain text; not rich text, HTML,
|
|
etc.</p>
|
|
|
|
<p>Please don't post lengthy descriptions, documentation, or
|
|
code to the mailing list, and no attachments, even small ones.
|
|
Please make lengthy material available on the web. You can use
|
|
a project hosting service such as sourceforge, github, google
|
|
code, bitbucket etc.</p>
|
|
|
|
|
|
<h2><a name="Development" id="Development"></a>3. Start
|
|
Development</h2>
|
|
|
|
<p>If response to an initial query indicates interest, then
|
|
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 Githib. An issue tracker such as one
|
|
provided by Github is also highly recommended.</p>
|
|
|
|
<p>Your library should contain material as if on the
|
|
boost.org web site. The closer your library mirrors 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>
|
|
|
|
<p>You can receive preliminary feedback and reviews by
|
|
submitting your library to the <a href=
|
|
"http://blincubator.com">Boost Library Incubator</a>.</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. Sometimes it
|
|
is public, on the mailing list, sometimes a lot of discussion
|
|
happens in private emails. For some libraries the process is
|
|
over quickly, for others it goes on for months. It's
|
|
often challenging, and sometimes leads off in 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>Some best practices ideas with samples of script and code
|
|
and links into source code in existing Boost libraries can be
|
|
<a href="https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook">
|
|
found on the Boost wiki</a>.</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 a lot
|
|
more) of the Boost community who will publicly endorse
|
|
with their names and reputation 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> with a short description of your library, links
|
|
to its github and documentation, and ask for endorsements.</p>
|
|
|
|
<p>It is expected that those who endorse a library for review
|
|
will have performed 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 a cursory check, they believe
|
|
that a library stands some chance of being accepted during a
|
|
formal review. It is also expected that they will provide a
|
|
review of the library when the formal review is undertaken,
|
|
though this is not binding.</p>
|
|
|
|
<p>Once you have a list of people who have publicly endorsed
|
|
your library for review, you can email <a
|
|
href="/community/reviews.html#Wizard">the Review Wizards</a>
|
|
to ask for your library to 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>
|
|
|
|
|
|
<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>Once a potential review manager has been found, <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 the author and
|
|
review manager to schedule a date convenient for the author and
|
|
review manager.</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, quadruple check your
|
|
library. Check 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 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
|
|
their 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 and help someone
|
|
else take over as the library maintainer.</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>
|