Re: [boost] The problems with Boost development

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