Upcoming Reviews
-- We are proud of the past reviews and community members who worked on them. -
-Past Review Results and Milestones
+| Submission | +Submitter | +Review Manager | +Review Dates | +Result | +
|---|---|---|---|---|
| + Submission: {{ review.submission }} + | +
+ Submitter:
+ {% for submitter in review.submitters.all %}
+ {% avatar user=submitter avatar_type="with_name" %}{% if not forloop.last %} {% endif %} + {% empty %} + {{ review.submitter_raw|default:"-" }} + {% endfor %} + |
+ + Review Manager: + {% if review.review_manager %} + {% avatar user=review.review_manager avatar_type="with_name" %} + {% else %} + {{ review.review_manager_raw|default:"-" }} + {% endif %} + | ++ Review Dates: {{ review.review_dates }} + | +
+ Result:
+ {% for result in review.results.all %}
+
+ {% if not result.is_most_recent %} |
+
Boost Library Submission Process
+This page describes the process a library developer goes through to get a library accepted into Boost.
+Steps for Getting a Library Accepted by Boost
-Formal Reviews are Vital
-- Boost libraries are selected for their relevance, high quality, and fitness for purpose. The review - process ensures that only the best libraries with committed maintainers become part of the collection. - Volunteers who write reviews are performing a vital service for the community. They are heroes! -
- -Learn about Boost
+Follow posts on the Boost developers' mailing list for a while, or look through the message archives. Explore this website. Learn the Library Requirements. 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.
-How It Works
+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.
-
- 1. Determine Interest
-- Make sure your library is suitable for the collection by proposing it to the Boost community in the forum. - Existing authors will either endorse the library or explain why it is not appropriate or what might be - needed to make it a good fit. -
-Determine Interest
+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!
-
- 2. Post and Request a Manager
-- The Review Manager is the overseer for the review process of a library. To get the library on the schedule, - a suitable manager should volunteer. Post your library to the mailing list to find a volunteer manager. -
-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.
-
- 3. Prepare for Review
-- The time between the library endorsement and the beginning of the review on the schedule is a great - opportunity to make sure that the library meets the requirements, - including documentation and build scripts. 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. -
-Potential library submitters should also be careful to publicize, 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.
-
- 4. Review Period
-- For the two weeks after the review starts, engaged community members from the mailing list ask questions, - make comments, and often get into arguments about your library. Finally when they are done, they write - their summary containing their opinion of your library and, most importantly, whether to accept or reject it. -
-There are many places to publicize and canvas for a library. The Boost developers' mailing list 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 Reddit/r/cpp.
-
- 4. Accepted or Rejected
-- After the scheduled time has passed, the review manager retreats for a while to contemplate the results - and issue a verdict on whether or not the library will be added to Boost. -
-A message to the Boost developers mailing list might be as simple as "Is there any interest in a library which solves Traveling Salesperson problems in linear time?"
-Library Name Here
-About the library.. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla vitae elit libero, a pharetra augue. Maecenas faucibus mollis interdum. Nullam quis risus eget urna mollis ornare vel eu leo. Donec id elit non mi porta gravida at eget metus. Donec id elit non mi porta gravida at eget metus. Sed posuere consectetur est at lobortis.
-
Library Name Here
-About the library.. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla vitae elit libero, a pharetra augue. Maecenas faucibus mollis interdum. Nullam quis risus eget urna mollis ornare vel eu leo. Donec id elit non mi porta gravida at eget metus. Donec id elit non mi porta gravida at eget metus. Sed posuere consectetur est at lobortis.
-Library Name Here
-About the library.. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla vitae elit libero, a pharetra augue. Maecenas faucibus mollis interdum. Nullam quis risus eget urna mollis ornare vel eu leo. Donec id elit non mi porta gravida at eget metus. Donec id elit non mi porta gravida at eget metus. Sed posuere consectetur est at lobortis.
-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.
-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.
+ +Start Development
+If response to an initial query indicates interest, then by all means make your library publicly available if you haven't already done so.
+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.
+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.
+Please verify that your library compiles and runs under at least two compilers. This flushes out obvious portability problems.
+ +It is recommended that you release your code under the Boost Software License.
+ +Refinement
+Discuss, refine, rewrite. Repeat until satisfied.
+ +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.
+ +The mailing list archives of past messages is one way to see how this process worked for other Boost libraries.
+ +Alternatively, follow the status links in the previously submitted libraries listed in Past Review Results and Milestones.
+ +Getting Seconded for Review
+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 the Boost developers' mailing list a short description of your library, links to its github and documentation, and a request for endorsements.
+ +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.
+ +Once you have a list of people who have publicly endorsed your library for review, email the Boost developers' mailing list to request that your library be added to the Current Schedule where the following information will be shown:
+ +-
+
- Submission (Library name) +
- Submitter (author or authors) +
- Review Manager +
- Review Dates (start and end dates of the review period) +
- Links to the status of the review, given as announcements. +
Seek a Review Manager
+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 Managing Reviews for the responsibilities of the review manager.
+ +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.
+ +If you cannot find a review manager after three 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. 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.
+ +Once a potential review manager has been identified, contact the Review Wizards for approval. The wizards approve review managers based on their level of participation in the Boost community.
+ +The review wizards will coordinate with both the author and review manager to schedule a date convenient for both.
+ +Formal Review
+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.
+ +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.
+ +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 summarizing the decision publicly. If conditions are attached to acceptance, you will need to implement those conditions or else undergo an additional formal review.
+ +Fast Track Reviews
+To qualify for a fast track review:
+ +-
+
- The component must be small. +
- The technique must be already in use in Boost libraries and the new component provides a common implementation. +
- A full Boost-conformant implementation is available in the sandbox. +
- The review wizard determines that the proposal qualifies for fast track review. +
Fast Track Procedure
+-
+
- The Boost review wizard posts a review announcement to the main Boost developer's list. The fast track 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. +
- After the review period ends, the submitter will post a review summary containing proposed changes to the reviewed implementation. +
- The review wizard will accept or reject the proposed library and proposed changes. +
- After applying the proposed changes, the component is checked into the repository like any other library. +
Mini-Reviews
+It is possible that in the review process some issues might need to be fixed as a requirement for acceptance. If a review does result in conditions on acceptance, the review manager may request a Mini-Review, at a later date, to determine if the conditions have been met. The Mini-Review is usually conducted by the same review manager.
+ +Boost Website Posting
+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.
+ +People Page
+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.
+ +Lifecycle
+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.
+ +Orphaned libraries will be put in the care of a maintenance team, pending a search for a new maintainer.
+ +Library Maintainer's Rights and Responsibilities
+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.
+ +You will be expected to respond to reasonable bug reports and questions on time and to participate as needed in discussions of your library on the Boost mailing lists.
+ +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.
+ +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.
+ +Libraries which have been abandoned will be put in care of a maintenance team.
+ +Upcoming Reviews
-Upcoming Reviews
+| Submission | +Submitter | +Link | +Review Manager | +Review Dates | +
|---|---|---|---|---|
| + Submission: {{ review.submission }} + | +
+ Submitter:
+ {% for submitter in review.submitters.all %}
+ {% avatar user=submitter avatar_type="with_name" %}{% if not forloop.last %} {% endif %} + {% empty %} + {{ review.submitter_raw|default:"-" }} + {% endfor %} + |
+
+ Link:
+ + + + Github + + + + |
+ + Review Manager: + {% if review.review_manager %} + {% avatar user=review.review_manager avatar_type="with_name" %} + {% else %} + {{ review.review_manager_raw|default:"-" }} + {% endif %} + | ++ Review Dates: {{ review.review_dates }} + | +
Overview
Reviews are scheduled when the review wizards approve a review manager and agree with the manager and - author on dates. See Review Process for more information. + author on dates. See Review Process for more information.
In addition to upcoming reviews, the schedule includes recent reviews already completed; that helps track @@ -79,8 +83,8 @@ In order for a review to proceed, a Boost member must volunteer to manage the review. This should be someone with experience with the review process and knowledge of the library's domain. Reviewers have been celebrated and recognized for contributing to some of the greatest revolutionary programs. Be a leader and make an impact - within the Boost community! Contact Mateusz Loskot (mateusz@loskot.net) or - John Phillips (johnphillipsithaca@gmail.com) to become a reviewer. + within the Boost community! Contact Mateusz Loskot (mateusz@loskot.net) or + John Phillips (johnphillipsithaca@gmail.com) to become a reviewer.