Re: [boost] Languishing review requests
Checks the submission to make sure it really is complete enough to warrant formal review.
Not really required. The reviewers will be quick to point that out.
This is a critical requirement. If libraries that are not ready are regularly put up for review, than potential reviewers will just get frustrated with half completed libraries. I have 5-6 half-completed libraries myself that I could put up for review.
Finalizes the schedule with the Review Wizard and the submitter.
Not required. The submitter can do that.
Another very important requirement. A reliable scheduling mechanism is important to maintain the integrity of the review process. Just letting people schedule whatever they want whenever they want would be very chaotic.
Posts a notice of the review schedule on the regular boost mailing list, the boost-users mailing list, and the boost-announce mailing list.
The submitter can do that.
No. The submitter should not need to do that.
Inspects the Boost library catalogue for libraries which may interact with the new submission.
The submitter or the reviewers can do that.
Non-issue. Everyone can now give any input they wish as to potential interactions that the proposed library has with existing libraries.
Urges people to do reviews if they aren't forthcoming.
The submitter has an incentive to do that. Lack of reviews leads to autoreject.
No. The number of reviews should have no bearing on the review managers decision. Some libraries have very limited use-cases, and are quite obscure. An experienced, knowlegable "review manager" will see through the lack of reviews and still be able to make a decision as to whether the boost would benefit from adding a given library.
Follows review discussions regarding the library, moderating or answering questions as needed.
Moderating rarely needed. Following/answering needs to be done by submitter.
I'm suprised you feel this way. A moderater can be a huge benifit to the flow of a discussion.
Asks the review wizard for permission to extend the review schedule if it appears that too few reviews will be submitted during the review period.
The review can take as long as necessary to gather a sufficient number of reviews. There is no need for a deadline. If we decide to keep the current scheme, the submitter can ask for the extension.
In general, its up the review manager to deciede how long is needed. The ten day review period is just a rule of thumb. The review manager, if they choose, can continue to lead a discussion and take reviews long after the "initial" review period is over. The larger, more complicated libraries generally have taken about 20 days to review, with about 10-20 days more for follow ups.
Decides if there is consensus to accept the library, and if there are any conditions attached.
It is the responsibility of the submitter to prepare a summary of the reviews linking to them and to work with the reviewers to address their concerns. The summary is posted to the list and the moderators decide whether to accept the library.
The moderators are the most active contributers to the main-line code. In my mind, they are certainly among the most talented programmers in the world. Their time is expensive. They should not be asked to do even more. Quite the opposite, they should be asking us free-loaders to step up.
Posts a notice of the review results on the regular boost mailing list, the boost-users mailing list, and the boost-announce mailing list.
The moderators do that.
No. The moderators should not be asked to do that. Thats a task that could easily fall to someone else
on Wed Jun 06 2007, "Tom Brinkman" <reportbase-AT-gmail.com> wrote:
Posts a notice of the review schedule on the regular boost mailing list, the boost-users mailing list, and the boost-announce mailing list.
The submitter can do that.
No. The submitter should not need to do that.
Yes, I think another thing that's being overlooked is the role played by a review manager of helping the submitter (for lack of better words) to be comfortable. Announcing on his or her behalf is just one of those things that makes the submitter feel as though he or she is not "doing this entirely alone." Much as I wish it were otherwise, submitting a library to our process can be daunting, and having a review manager can help with that, if only a little. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
on Wed Jun 06 2007, "Tom Brinkman" <reportbase-AT-gmail.com> wrote:
Posts a notice of the review schedule on the regular boost mailing list, the boost-users mailing list, and the boost-announce mailing list.
The submitter can do that.
No. The submitter should not need to do that.
Yes, I think another thing that's being overlooked is the role played by a review manager of helping the submitter (for lack of better words) to be comfortable. Announcing on his or her behalf is just one of those things that makes the submitter feel as though he or she is not "doing this entirely alone."
Much as I wish it were otherwise, submitting a library to our process can be daunting, and having a review manager can help with that, if only a little.
This point may deserve a little expansion. When I ran the review of the units library, one of the first things I did after volunteering was to go back and look at the discussion of Andy Little's quantitative units submission. I was a part of this conversation, but I wanted to be sure I recalled it clearly. One of the things that struck me was that there were really two separate discussions tangled together. One was about the quality of implementation and documentation of the library Andy made, and the other was about whether his design goals were the right choice. Unfortunately, in much of the review the posts weren't clear about which of the two issues they were concerned about. I don't think any of us had considered it that way while we were doing the review. Before the review of the units library, I wrote to Matthias and Steven and suggested that we try to keep the two discussions clearly separated. Mathias had also participated in the review of Andy's library, and the discussions in the review drove many of his design decisions. He made some choices in design that were very different from Andy's and he understood that not everyone would agree. In my opinion, trying to make that distinction clear was an important part of making the review as productive as it was. Also, when the question came up after the library was accepted about what makes this library different from Andy's, it was easy to answer and support. This is the sort of process that someone who has been part of the boost developer list for years and who has participated in reviews will know to do, but some very good libraries are submitted by people who don't have such a long history with boost. We could say that it is tough for them, and they should do their homework, but I prefer providing a little more support than that. John
participants (3)
-
David Abrahams -
John Phillips -
Tom Brinkman