Boost logo

Boost :

Subject: Re: [boost] The problems with Boost development
From: John Phillips (phillips_at_[hidden])
Date: 2010-03-19 23:28:39


Andrey Semashev wrote:
> ...
> First, here are my top 3:
>
> 1. The review procedure is failing to deliver new libraries to the users
> in a reasonable time frame. Some very important libraries stay in the
> queue for too long without even having a review manager assigned.

   For clarity - review managers aren't assigned, they volunteer. If no
qualified Booster is interested in the library enough to volunteer, then
they may not agree with you as to how important the library is.

>
> ...
> 3. Monolithic design limits development and adoption of Boost. A more
> modular approach is needed.

   This is an idea that seems to be reaching critical mass inside the
community. It has come up many times in the past year or two, and as is
seen in a different thread there are now people concerned enough with it
that they have built a proposed solution.

   Why didn't this happen earlier? As far as I can tell because this is
the first time people who were worried about the problem took the
additional step of making a potential solution.

> ...
>
> Now, some more details on the outlined issues.
>
> 1. The review procedure.
> ========================
>
> The topic raises rather often, there are suggestions from different
> participants, but it seems that nothing changes eventually. ...

   I at least have not seen a consensus of the community that would be
required to make a major change in the review policy. In specific, these
discussions are usually dominated by people who have been neither
managers nor developers of reviewed libraries. Some (such as you) do not
fit that description, but the fractional representation of experienced
reviewed developers or review managers in these discussions is usually
small. I think it would be unwise to make major changes in the system
without a strong consensus of the most experienced members of the community.

>
> Anyway, I think, we should identify the reasons of this stagnation. Of
> course, the first thing that comes to mind is the lack of time of the
> volunteers. True, I can barely comprehend the amount of time a review
> manager should dedicate to the review. This is especially true in case
> of big submissions to Boost. This amount of time should be reduced. The
> following ways of doing that come to mind (some were discussed earlier
> on the ML, but I'll rehash):

   I would point out that the increase of economic pressures around the
world, and the reduction of time for managers and reviewers to dedicate
to the review process was fairly well correlated. There may be a
mechanism here worth paying attention to.

>
> - Introduce the voting mechanism. Voting should be as easy as clicking
> on a yes/no link or icon on a web page + an optional small comment. No
> ML subscription required. The review manager may take into account those
> votes as an indication of public interest and appreciation of the
> submission.

   Again for clarity - This appears to be similar to Paul Bristow's and
others' suggestion that there be a pre-review approval phase. Is this
what you intend?

> - Separate the mechanism of posting a full review and the library
> discussion. It would make it easier to collect the formal reviews
> without having to read through all the discussion. Perhaps, a separate
> ML for formal reviews would suffice. A web page with a few fields to
> fill in to post the review would also be very helpful, especially for
> the occasional newcomers.

   I'm not sure I understand what you mean here. I see two possibilities.

   First, you may mean separate discussion about libraries under review
from the rest of the boost developer list discussion. If so, I don't
think it will have much effect. It is not usually hard to see which
posts are about reviews and which are not. In my experience managing
reviews, this has been a non-problem. Other managers may disagree, however.

   Second, you may mean separating the review submission from the
discussions about the library and the decisions that drove the
development that usually grow out of those submissions. If this is your
intent, then I strongly disagree. An important part of the role of the
manager is to clarify and distill those discussions and decide whether
there is some suggestion or requirement for the future development of
the library that is a product of the discussions. In a good discussion
of the library, by far the most valuable information for composing a
good review comes from the posts that are not the formal review
postings. It is the place where people who disagree provide their
reasons, where examples are composed and discussed, where any consensus
that ever forms can be found. Reading those discussions is essential to
producing a good review report and a well reasoned recommendation.

> - Reduce the number of formal questions for the review. IMHO, three
> questions of design, docs and implementation quality, plus the final
> yes/no verdict should suffice for the review. The rest should be optional.

   In the current process, all of the questions are optional. The
provided questions are suggested, but there are always reviews that
don't answer them all.

> - Provide automated ways of assisting the review, such as scripts for
> updating the web site for the review (e.g. post an announcement in the
> news section, prepare the aforementioned web page for posting reviews,
> etc.), formal mailings (review is upcoming, review has started, review
> is in progress, review has finished) and whatever other things needed.

   The current web site updates are done by the wizards. The review
managers have no work to do for them. The notifications to the list take
a cumulative total of a few minutes to create and send.

>
> Ideally, I would like to reduce the time needed for such routine things
> to a minimum.

   It could possibly be reduced, but only by a few minutes, since that
is all it takes. This is optimizing the part of the program that takes
1% of run time and hoping to get a meaningful reduction in the whole
program.

>
> Another reason is the lack of motivation. I think, it is fair to say
> that people that invest their time and effort into Boost should be
> rewarded somehow. I'm not saying that Boost should become a commercial
> software (please, no!), but the appropriate acknowledgement of their
> efforts should be in place (on the front page of the web site and the
> release notes). Perhaps, a donation system could be established, so that
> release and review managers do get monetary rewards, too. On the current
> stage I don't consider reviewers to be rewarded, because the library
> acceptance itself is a reward for them, as for the interested parties.
> But the library author is free to acknowledge them in the library
> credits page.

   There are a darn lot of people who work to make Boost work. Many of
them do so in relative obscurity and are not offended by that. They
deserve thanks for their efforts (My heartfelt thanks to all of you. I
know many of you do far more and harder work for Boost than I do.), and
maybe even buy them a beer if you see them at BoostCon. However, listing
them on the front page removes the focus from the reason why they do the
work. They can be part of the "People" page, if they choose and be
acknowledged there. I am personally against trying to funnel money to
some subset of the volunteers. Down that path lies endless arguments
about who deserves what fraction of the pot.

>
> And the third reason I'd like to outline is the lack of people. The
> problem is twofold. On one side, the entering barrier for a person into
> Boost is quite high. One has to be a quite experienced developer to
> participate in reviews, let alone to be a review manager. While the
> review manager should be experienced, I'm not sure the requirement is
> adequate with regard to the reviewers. I think it should be possible for
> the less experienced users to see if documentation and examples are
> clear and understandable, while the more advanced developers have more
> time to evaluate the implementation and the interface of the library.

   There is no requirement for reviewers to be highly experienced
experts. In fact, I have personally posted exactly the opposite on both
the developer list and the user list several times. (In my role as a
Review Wizard.) It is well understood that the view of someone not
familiar with the details of Boost, but instead a solid journeyman
programmer with an interest in using a library has a very valuable
perspective on the documentation, the interface, and several other
aspects of the library. I have a history of encouraging them to
contribute to reviews, but I am far from alone in that. Some people who
consider contributing to a review are intimidated by the level of the
conversation and worry that they will appear ignorant. This is a problem
I'm not sure how to solve. But I don't recall any instances of someone
being told they can't contribute, and I recall several instances of
someone prefacing comments by saying they are new, and being told that
the insights of new people are valued.

>
> The other side of the problem is that Boost is rather closed to its
> community. I don't know how it happens, but on independent news I
> regularly read of such projects as KDE, GNOME, Qt, Linux Kernel and
> others, but nearly nothing about Boost, which, I believe, has no less
> importance in the world of C++. The Boost web site changes rarely -
> essentially, the news column only lists recent Boost releases. For an
> outsider, nothing really happens around Boost, and that's sad. If Boost
> was more open and advertised on public (perhaps, not a good wording, but
> I can't come up with a better phrase now), I think, there would be much
> more activity in Boost, and during reviews in particular.

   I agree that finding a way to get a broader cross section of the
developer community outside of Boost involved in review discussions
would be good for the libraries. However, I should point out that
success at this will amplify the problems for the review managers and
developers.

   As an example, your recent Logging Library review produced a few
hundred relevant posts. Many of them long and thick with technical
details. Now imagine what happens if three times as many people are
involved. It is unlikely that the post volume will scale linearly, but
something like quadratically is more likely.

>
> To be continued...

   And I look forward to it.

   Please don't conclude from my post that I'm against anything changing
in the review process. I'm also not happy about some of the libraries
that have languished, and some of the other problems. However, I think a
healthy review process is essential for the health of Boost, so I will
very critically examine any suggestions put forward and share what I see
as potential problems.

                        John Phillips


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk