Review/Process

The process is a standard three weeks once the code is ready. Two weeks are left for review of the source and API, and is followed by a week of voting. During the review the code can be modified to appease the criticism, and it will be up to the submitter and review manager to decide if it makes sense to continue with a vote or postpone for a later review.

New submissions with major additions must run through a Boost Review cycle as described below. It is suggested that you post to the Development Newsgroup to gauge interest and identify it isn't already being worked on. Don't get discouraged from low response as this can be for several reasons, but hopefully a sign that others agree it should be in Phobos. And even if it is decided not to fit, if it is code you are interest in having, others are likely too and can be its own library.

Smaller additions such as expanding existing functionality or fixing bugs can skip the formal review process. Remember that it is volunteers running this which means pull requests could have long waiting periods before getting reviewed. You can use the newsgroups to peek more interest in the request.

Review Queue

Development and Release Process

The content below is waiting for approval.

Reviewer

A reviewer should speak out as early as possible if they feel a library/submission should never be included into Phobos. Similarly they should speak up when they wish for a submission to be included. This includes prior to the formal review.

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.

The goal of the 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 Phobos? If not, we hope to have provided enough constructive criticism for it to be improved and accepted at a later time.

Some things to consider while reviewing:

• The API is practically permanent once the module is accepted.
• Documentation should provide sufficient understanding on the use of the module.

Voting

Voting is announced on D.announce and a thread is started on D to submit votes.

The goal of the vote is to allow the Review Manager to decided if the community agrees on the inclusion of the submission.

• Place further discussion of the library in the official review thread.
  • If replying to an opinion stated during a vote, copy all relevant context and post in the official review thread.
• If you would like to see the proposed module included into Phobos
  • Vote Yes
• If one condition must be met
  • Vote Yes explicitly stating it is under a condition and what condition.
  • You may specify an improvement you'd like to see, but be sure to state it is not a condition/showstopper.
• Otherwise
  • Vote No
  • A brief reason should be provided though details on what needs improvement should be placed in the official review thread.

Approval wanted

A Phobos developer should also identify themselves as such, state their approval along with confirmation that the source can be merged into Phobos as is.

Requirements

Approval Wanted. http://www.boost.org/development/requirements.html#Requirements

There is no requirement that the submitter be active within the community, however keep in mind the Library Maintainers Rights and Responsibilities.

Requirements can be waved at community discretion.

• Licensed under the Boost Software License
• The author and copyright must be clear
• The library must be generally useful
• Must meet portability requirements below.
• The author must be willing to participate in the review and refine the submission accordingly.
• The code must reside within a branch of the Phobos library and follow the D Style Guide.
• Must have Phobos Quality.

Portability

• The submission's interface must be portable and not restricted to a particular compiler or operating system.
• A libraries implementation must, if possible, be portable and not restricted to a particular compiler or operating system.

At this time, there are no requirements to validate with LDC or GDC.

Submitter

As a submitter of a module you take the role as the primary maintainer and it is your responsibility to find a qualified volunteer to serve in your place if you so choose.

Your code and documentation will need to be licensed under the Boost Software License.

Approval wanted. http://www.boost.org/community/reviews.html#Maintainer

You will be expected to be available via email to respond to bug reports and questions. It is beneficial to follow the newsgroup and bug reports, but not necessary as long as your email can be located.

Improvements to your library are encouraged after the library approval, however any API changes must get further approval by the community; along with any significant additions to the API.

Patch submission including bug fixes and minor additions to a module do not place the same expectations on the submitter.

Review Manager

The Review Manager is an active member of the community with no connection to the library submission. The review manager will work with the submitter to make sure the submission is complete enough to warrant a formal review. See Requirements

• Announce review on D.announce and start a thread for review on D
• Follows review discussions moderating and answering questions to the best of their ability.
• Evaluates the need to extend the review.
• Decides if a vote should be postponed.
• Tallies votes and decides if there is consensus to accept the library and under what conditions.
• Announces results to D.announce with a summary.