Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale

Subject: Re: [boost] Updating the Boost Review Process Was: [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: John Phillips (phillips_at_[hidden])
Date: 2009-11-17 11:11:34

Jose wrote:
> On Mon, Nov 16, 2009 at 9:02 PM, John Phillips
> <phillips_at_[hidden]> wrote:
> > ...
> 
> Yes, this explains it clearly. But fuzzy criteria also leads to
> conflict on new situations.

   Rigid criteria also lead to conflict in some situations, but they 
provide less flexibility to try and fix such conflict.

> 
> It would be great if you could step in above and try to find a
> solution since one of problems seems to be the way the reviews were
> scheduled (a different approach is to ignore the problem and make it
> bigger than it is).

   Since I'm involved in this conversation, it should be obvious that I 
am not ignoring what is happening. However, taking action is not 
synonymous with doing what any one person wants.

> 
>>  I also don't think Boost is a good place for centralized design decisions.
> 
> If I understand it correctly, in a community there are no centralized
> decisions, but there are roles and yours seems the most important in
> this situation.

   In some communities there certainly are centralized decisions - see 
political science for numerous examples. However, I do not agree that 
the role intended by the Boost community for the Review Wizards is that 
of central planners for what should be and not be in Boost.

> > ...
> 100% in agreement. But the confrontation with different libraries is
> something that discourages new authors. As I said before, make it
> easier for the one that proposes a library as he is doing the hard
> work.

   I see no way to completely remove such confrontation, and the only 
effective ways to reduce it are more dependent on the library developers 
than on the review process. The list can and does encourage developers 
who are working on common problems to work together and develop a joint 
vision. Such threads are not uncommon if you look at list history and 
the geometry libraries have been encouraged to do this as well. However, 
not all developers take such well intentioned advice for any number of 
reasons.

   Everyone certainly agrees that the work of a Boost developer is hard 
and that reasonable steps should be taken to keep it as easy as is 
possible, but I am not convinced that adding layers of extra work to the 
review process is the way to accomplish that.

> 
>> ..
> 
> Ok, It's a solution, maybe not the best one but I lack the in-depth
> expertise judge.

   I find this comment a little confusing and possibly frustrating. 
Maybe I'm misunderstanding it so correct me if needed. However, this 
reads as you saying that you lack the in depth knowledge to know if 
Fernando made a good decision in accepting the Polygon library. If so, 
why in the world have you said several times that his decision should be 
overturned? I would think such a statement can only be made if the 
person making it has clear technical reasons to back up the assertion.

> 
>> ...
> 
> Just read the reviews, and you'll see people mentioning that the
> confrontation is not good, how did we get into this mess,
> how did this happen .. I know, the easiest is to say there is not a
> problem so there is no need for a solution. The schedule was bad and
> that could have been fixed, the review could have been cancelled, ..!

   First, as I pointed out elsewhere, I did read the reviews and there 
were some strong opinions both for and against the library. The basis 
for making a good decision in such a case is an understanding of the 
technical details and the use cases, combined with careful 
consideration. If you wish to argue that the decision was wrong, then 
use these as the basis of your discussion. If you make a good argument 
of this sort, then you might even get what you want.

   However, in my own experience as a review manager I can tell you that 
there are sometimes very strongly held opinions in reviews that are 
simply technically wrong. So, just having a strong opinion against the 
library is not a good argument to overturn the review. (This should not 
be read to imply that the opinions against Polygon were technically 
wrong. I have not put the work into the technical details to have an 
opinion on that.)

   You have stated many times that the Wizards (Ron and I) could have 
canceled the Polygon review. No, we could not unless we can travel 
backward in time. The review for Polygon ran from late August to early 
September. At the time of the review, it was the only geometry library 
that had been submitted for review. Barend had posted many times on the 
list about the library he was working on and it produced many lively 
discussions, but the library had not been submitted for review.

   The first contact requesting a review was an email he sent in early 
October. That is more than a month after the Polygon review ended. The 
same day, I wrote Fernando to request that he hurry with producing the 
review result so people could know the outcome for Polygon before the 
GGL review began.

   As he stated, producing the results was delayed by his work 
obligations. As a pure volunteer organization we have to understand that 
this will happen sometimes. It is already hard to get qualified review 
managers; imagine how much harder it would be if we required that 
managers can't respond to changes in their work conditions and have some 
leeway for delay. There is such a thing as too much delay, and if you 
check the review history you will find that I have stepped in in the 
past and taken over managing in such a case. It is quite possible that I 
will be doing so again, soon, unfortunately. This is a major time sink 
for me, but it is also part of my role.

   So, the real choices would be to not allow a review result after the 
review was completed and the work done or to refuse to schedule the 
Polygon review because there was the possibility that GGL would someday 
be submitted for review. Both of these strike me as far worse choices 
than what has happened so far.

> 
> I understand that Boost has a close-knit community at its core and
> many users like me are spectators, but improving the review process is
> good for everybody and others suggestions have come up, not just mine!
> 
> regards

   I entirely agree that the process can be improved and that looking 
for improvements should be a constant goal. However, the review is 
central to what Boost is and how it works, so all ideas for changing it 
should be subjected to very careful (almost ruthless) scrutiny. There is 
nothing personal in this, it is just something I think everyone in the 
community should do in such a case.

   As for changing the process - I do not think that Ron and I have the 
authority to do so unilaterally. It should require a broad consensus 
across the Boost community. This should especially include input from 
developers who have been through the review process as submitters and as 
review managers.

                        John