Jose wrote:
On Mon, Nov 16, 2009 at 9:02 PM, John Phillips <phillips@mps.ohio-state.edu> 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