From: "Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com>
Jody Hagins wrote:
I believe I could have contributed in a non trivial manner to several reviews. However, by the time I see the announcement, download the materials, go through them, and try to keep up with the current comments, the review is over. I am so busy with work, family, coaching (American) football, and other activities, that the review periods usually seem too short (for me, at least).
This is also true for me. However, I think the review periods do not necessarily have to be extended. What has to be extended is the timeframe in which there will be no significant changes (interface & docs) to a candidate library. Libraries sometimes go through extensive changes right before the reviews start, which is probably the reason why people don't have a look beforehand. Maybe the review process should mandate a no-interface-and-docs-changes period of one month before the actual formal review starts, with announcements when this period begins?
Time is always a problem, and we most definitely need time to evaluate new libraries. The question is, when should the time be invested? I first notice new libraries when their formal review is announced. I may well have been part of design discussions along the way, but I won't have stopped to read through the documentation or code before the formal review. Thus, one or two weeks to do that and be part of an ongoing, often raging, discussion about the new library is demanding. To require N favorable reviews of a library before it can be submitted for list-wide review is questionable only because so much time will have elapsed between those reviews (due to the current backlog). Granted, you want to know that more than just the author think the library is good before putting it before the list, so such reviews seem obligatory. Perhaps the answer is that N reviews must be garnered for a library to be reviewed, and the formal review period can begin almost immediately thereafter -- subject to throttling. Then, there could be a review period of, say, a month, following which, the review manager can summarize the activity and determine subsequent actions. Yes, reviews can be really long that way and, as has been said, the code and documentation must not change during that period (though the author can, of course, maintain a separate development version as the review progresses). However, it would enable more people to review the libraries and would enable deeper reviews when warranted. The obvious problem is the number of simultaneous reviews that could be ongoing at a given point. I think that will only prove to be a problem initially as there are many libraries queued to be reviewed. Once the backlog is gone, there won't be so many new libraries to come on the scene as to make the review task onerous. Having more simultaneous reviews might be easier for some, too, as they might have a particular day available to conduct reviews, so several could be hammered out that day. With the current state, one can only conduct a single review on such an occasion. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;