[metaparse] Review Manager
Dear Review Wizards, I would like to volunteer to be Review Manager for the metaparse library, in agreement with Abel. We would like to suggest May 25 to June 07 for the review. If there are no objections, please sign me up. Regards, Christophe
On 2015-03-16 07:54, Christophe Henry wrote:
I would like to volunteer to be Review Manager for the metaparse library, in agreement with Abel. We would like to suggest May 25 to June 07 for the review. If there are no objections, please sign me up. Thank you Christophe.
I'd like to ask the maintainer of the Review Schedule webpage to update the Documentation and Source links of Metaparse: - Source: https://github.com/sabel83/mpllibs - Documentation: http://abel.web.elte.hu/mpllibs/metaparse/ Thanks, Ábel
Hello Abel,
Thank you for the updates. I will update the review schedule.
Best,
Ron
On 2015-03-16, at 1:15 PM, Abel Sinkovics
On 2015-03-16 07:54, Christophe Henry wrote:
I would like to volunteer to be Review Manager for the metaparse library, in agreement with Abel. We would like to suggest May 25 to June 07 for the review. If there are no objections, please sign me up. Thank you Christophe.
I'd like to ask the maintainer of the Review Schedule webpage to update the Documentation and Source links of Metaparse: - Source: https://github.com/sabel83/mpllibs - Documentation: http://abel.web.elte.hu/mpllibs/metaparse/
Thanks, Ábel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
This is about a week after C++Now 2015. I suppose that would work. Personally, I would like to see at least some reviews in the review pages of the incubator before we even start a review. The main purpose of the review queue in the incubator is to get reviews from a wider source and not limit the reviewers to a specific two week period. This library touches on a very narrow area where only the geekiest of the geekiest are in a position to understand and review it. This makes efforts to get more reviews even more important. I know it's off topic, but I'd like to see that a library have at least some number N of reviews on the incubator before we even schedule a review. I'm thinking of N ~ 5 ? Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/metaparse-Review-Manager-tp4673218p467325... Sent from the Boost - Dev mailing list archive at Nabble.com.
Hi Robert,
Personally, I would like to see at least some reviews in the review pages of the incubator before we even start a review. The main purpose of the review queue in the incubator is to get reviews from a wider source and not limit the reviewers to a specific two week period. This library touches on a very narrow area where only the geekiest of the geekiest are in a position to understand and review it. This makes efforts to get more reviews even more important.
I hope it's not only for the geekiest.
I know it's off topic, but I'd like to see that a library have at least some number N of reviews on the incubator before we even schedule a review. I'm thinking of N ~ 5 ?
Robert Ramey
Hmmm, wouldn't that mean setting the bar higher? Isn't it already high enough? It's not for me to decide but I don't favor this. Seeing the incubator as a way to get more reviews is ok for me, but as prerequisite? Regards, Christophe -- View this message in context: http://boost.2283326.n4.nabble.com/metaparse-Review-Manager-tp4673218p467325... Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG On 03/17/2015 10:24 AM, christophe.j.henry@gmail.com wrote:
I know it's off topic, but I'd like to see that a library have at least some number N of reviews on the incubator before we even schedule a review. I'm thinking of N ~ 5 ?
Hmmm, wouldn't that mean setting the bar higher? Isn't it already high enough? It's not for me to decide but I don't favor this. Seeing the incubator as a way to get more reviews is ok for me, but as prerequisite?
+1 In Christ, Steven Watanabe
christophe.j.henry wrote
Hmmm, wouldn't that mean setting the bar higher? Isn't it already high enough? It's not for me to decide but I don't favor this. Seeing the incubator as a way to get more reviews is ok for me, but as prerequisite?
OK - let me state it another way. I would like to avoid situations that have occurred in the past whereby libraries were reviewed with only a very small number of reviews. We could discuss what "small" is. I think we'd agree that 2 is "small" where 10 is not "small". FWIW my pick would be 5. If a library is rejected for lack of reviews, we've wasted time of the review manager and a two week review window - both scarce resources. If the first couple of reviews highlight some show stopping problem which forces the author either to retract his review request or accede to significant re-design - the review resources have also been wasted. if the review period falls at an inconvenient time for some key reviewers and they can't make a review in that time frame we've also lost good opportunity to maximize the effectiveness of the review. Now look at the incubator NOT as a pre-requisite but rather as way to minimize the possibility of a library getting rejected due to not getting enough serious reviews. Or maximizing the number of quality reviews. So I would encourage the libraries advocates to post their reviews on the incubator in advance of the formal review date. That's all I want to do ... (for now). I'll leave open the question of whether it's an effective usage of scarce resources to do a formal review if there are no existing reviews in he incubator.
Hmmm, wouldn't that mean setting the bar higher? Isn't it already high enough?
YES - it needs to be HIGHER!!! AND C++ needs MORE libraries. I'm aware that these two goals seem to conflict - that is why we need to evolve our procedures. As a user of boost - it seems that many, many, many times I want to look at a library and find way too much effort is required to understand and use the library. A big, recurring problem is poor documentation. Library authors consider it an afterthought rather than an integral part of the library. Another big recurring problem is library interface design. This results in a number of libraries where the authors state that they can't specify concepts because .... well I don't know. Usually it comes down to the fact that the library interface isn't really designed - it seems to just sort of "happen". Declining to raise our standards is a one way ticket to irrelevance. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/metaparse-Review-Manager-tp4673218p467338... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 3/18/2015 3:40 PM, Robert Ramey wrote:
christophe.j.henry wrote
Hmmm, wouldn't that mean setting the bar higher? Isn't it already high enough? It's not for me to decide but I don't favor this. Seeing the incubator as a way to get more reviews is ok for me, but as prerequisite?
OK - let me state it another way.
I would like to avoid situations that have occurred in the past whereby libraries were reviewed with only a very small number of reviews. We could discuss what "small" is. I think we'd agree that 2 is "small" where 10 is not "small". FWIW my pick would be 5.
If a library is rejected for lack of reviews, we've wasted time of the review manager and a two week review window - both scarce resources.
If the first couple of reviews highlight some show stopping problem which forces the author either to retract his review request or accede to significant re-design - the review resources have also been wasted.
if the review period falls at an inconvenient time for some key reviewers and they can't make a review in that time frame we've also lost good opportunity to maximize the effectiveness of the review.
Now look at the incubator NOT as a pre-requisite but rather as way to minimize the possibility of a library getting rejected due to not getting enough serious reviews. Or maximizing the number of quality reviews. So I would encourage the libraries advocates to post their reviews on the incubator in advance of the formal review date. That's all I want to do ... (for now). I'll leave open the question of whether it's an effective usage of scarce resources to do a formal review if there are no existing reviews in he incubator.
Hmmm, wouldn't that mean setting the bar higher? Isn't it already high enough?
YES - it needs to be HIGHER!!! AND C++ needs MORE libraries.
I'm aware that these two goals seem to conflict - that is why we need to evolve our procedures.
As a user of boost - it seems that many, many, many times I want to look at a library and find way too much effort is required to understand and use the library. A big, recurring problem is poor documentation. Library authors consider it an afterthought rather than an integral part of the library. Another big recurring problem is library interface design. This results in a number of libraries where the authors state that they can't specify concepts because .... well I don't know. Usually it comes down to the fact that the library interface isn't really designed - it seems to just sort of "happen".
Declining to raise our standards is a one way ticket to irrelevance.
The problem is that almost no one is using the incubator to show interest in a Boost library which may be on the review schedule. Unless a review is scheduled, which brings the attention of the library to others who may be interested in it, there is little personal interest from developers or users to look at some library. Once a review is scheduled and an announcement is made that library X will be reviewed shortly programmers become interested in that library. I agree there are cases where interest in a possible library occurs but that is almost always because it is mentioned in this mailing list and talked about by other developers or end-users. Hana is a recent case like that. But unfortunately merely adding a library to the incubator is not getting anybody interested in it. This is not a criticism of your work setting up the incubator but it is more about the fact that discussions on the Boost mailing lists pique people's interest much more than just adding a library to the incubator. So unless there is some fairly coninuous way of getting information about libraries on the incubator into the Boost mailing lists I do not see that requiring incubator interest in a library in order for that library to be reviewed is a viable path to go. I do agree with you completely that poor or haphazard attention to documentation, as in "I've developed library X which I might be interested to submit as a Boost library but as present there is no or little documentation, but what do you think about it since the source is at http:xxx and it is about Y and Z" does not personally interest me in any library. I am with you that without basic documentation a library could be the most brilliant thing since the theory of relativity and I would still have no interest in it. But that is separate from the issue of requirements of whether a library should be reviewed or not.
Edward Diener-3 wrote
The problem is that ... become interested in that library.
I agree there are cases where interest in a possible library occurs but that ...
I agree with all this - it's exactly what I'm trying to change.
So unless there is some fairly coninuous way of getting information about libraries on the incubator into the Boost mailing lists I do not see that requiring incubator interest in a library in order for that library to be reviewed is a viable path to go.
well, right now incubator interest is the only way we have of gaging if there's enough interest in a library to justify reviewing it. The review process has been a problem for years. I'm trying to make it better - albeit with limited success. Note that my target audience for the incubator is not so much the boost developer community but the C++ community at large. I'm hoping that "the rest of us" will find code there that solves problems lot's of people have. And that this code will include commentary from other users, good documentation (ideally annoyed by other users), access to test results, reviews and commentary, and access to repo history. I also want to make it easier for the wider community to contribute. It's great to have 4 meta programming libraries around - but isn't there room for a really well crafted class for "money".
I do agree with you completely that poor or haphazard attention to documentation ...
But that is separate from the issue of requirements of whether a library should be reviewed or not.
Correct - it's an orthogonal issue. But Hmmm - maybe we can just say that the library is approved subject to the documentation meeting certain standards. But I don't think that's working. I want to see a change in the way library programmers think about coding, documentation, concepts, library design and program correctness. These are not new ideas - I just want them to be taken more seriously. I think Boost only has a future if they are. I realize that that I'm on a personal quest here. I much appreciate the willingness of the boost community to indulge me here. Robert Ramey. -- View this message in context: http://boost.2283326.n4.nabble.com/metaparse-Review-Manager-tp4673218p467340... Sent from the Boost - Dev mailing list archive at Nabble.com.
Hi,
I would like to avoid situations that have occurred in the past whereby libraries were reviewed with only a very small number of reviews. We could discuss what "small" is. I think we'd agree that 2 is "small" where 10 is not "small". FWIW my pick would be 5.
If a library is rejected for lack of reviews, we've wasted time of the review manager and a two week review window - both scarce resources.
Thanks for worrying for my time ;-) I agree that my time is a scarce resource. So if I'm willing to risk it, and risk reviewer time too, it's because I think the library has merit and deserves a closer look. I also waited for requesting a review until Abel writes some good documentation and tutorial, which he did by now. Community, please have a look at it, I hope you will like what you see. The "Getting Started" part is really well done, and with the Online Demo, Abel went to great lengths to make us easy to try the library out. I have seldom seen a library come to review with such a good documentation.
If the first couple of reviews highlight some show stopping problem which forces the author either to retract his review request or accede to significant re-design - the review resources have also been wasted.
I thought this was the point of having to find a review manager and organize a review. There is always a risk that the library fails to pass the review. Otherwise, why have one?
well, right now incubator interest is the only way we have of gaging if there's enough interest in a library to justify reviewing it. The review process has been a problem for years. I'm trying to make it better - albeit with limited success.
Note that my target audience for the incubator is not so much the boost developer community but the C++ community at large. I'm hoping that "the rest of us" will find code there that solves problems lot's of people have. And that this code will include commentary from other users, good documentation (ideally annoyed by other users), access to test results, reviews and commentary, and access to repo history. I also want to make it easier for the wider community to contribute. It's great to have 4 meta programming libraries around - but isn't there room for a really well crafted class for "money".
I can only praise your efforts and it is one more tool to get quality libraries in Boost. But the "standard" one works sometimes too. We can have both. The bar is usually so high to find a review manager, if you find one, chances are that there is interest. Sure, maybe only from a few "geeks", but these geeks are usually the ones who use these tools to make new libraries.
I realize that that I'm on a personal quest here. I much appreciate the willingness of the boost community to indulge me here.
I personally do it happily and appreciate your commitment to the community. Regards, Christophe
christophe.j.henry wrote
If the first couple of reviews highlight some show stopping problem which forces the author either to retract his review request or accede to significant re-design - the review resources have also been wasted.
I thought this was the point of having to find a review manager and organize a review. There is always a risk that the library fails to pass the review. Otherwise, why have one?
Of course, but why pass up the opportunity to get some advance feedback? Such feedback will make the library less likely to fail. It's not either/or it's about making the review process easier and more effective.
I can only praise your efforts and it is one more tool to get quality libraries in Boost. But the "standard" one works sometimes too. We can have both. The bar is usually so high to find a review manager, if you find one, chances are that there is interest. Sure, maybe only from a few "geeks", but these geeks are usually the ones who use these tools to make new libraries.
The review process DOES work. I'm a huge fan of it. But we've had concerns for many years that it's hard to find review managers and that there aren't enough reviews. And the review process takes a lot of work. Imagine how much easier the the review process would be if there were already 5 reviews posted? How much easier would be be to get a review manager? As a thought experiment, consider what would happen if we already had 5 reviews. a) all reviews are wildly positive - review management is pretty simple b) all reviews are strongly negative - the review process would end there c) reviews are mixed - the most common case. The library author would be strongly motivated to address the complaints as soon as possible. The final review would more likely to move toward a) above. (BTW, I wonder if the improvement in documentation you refer to above is motivated by some feed back to the author). So you see, I'm not proposing an alternative to the review process. I'm trying to address the things which have made it less effective in the past without in anyway diminishing it's value - or even altering the prodedure itself. I think I found a good improvement with no downsides. So, I would encourage anyone who expects to participate in this review to post their review on the incubator at their earliest convenience. You'll have it done already when the review actually comes up, and you'll give the author the option to act on your feedback earlier and maximize his chances of getting his library accepted. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/metaparse-Review-Manager-tp4673218p467348... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 19 March 2015 at 14:05, Robert Ramey
christophe.j.henry wrote
If the first couple of reviews highlight some show stopping problem which forces the author either to retract his review request or accede to significant re-design - the review resources have also been wasted.
I thought this was the point of having to find a review manager and organize a review. There is always a risk that the library fails to pass the review. Otherwise, why have one?
Of course, but why pass up the opportunity to get some advance feedback?
Is there a reasonable assurance that he'll get it, or is it just adding latency to the process? Of the twenty-two libraries listed, there are a whopping three reviews, two of which are a review of your own library, and one of those is by you where you recommend that we don't accept it into Boost. Not exactly good odds... The incubator is an experiment. It may succeed, or it may fail. If someone wishes to tie their review to it, that's fine. If they don't wish to, that is fine too. We know that you want the incubator to succeed, but it is unfair to expect anyone to hold up a review of their library because of it. -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com (847) 691-1404
Nevin Liber wrote
Is there a reasonable assurance that he'll get it,
Well I got some - safe numerics review - and I found it extremely useful.
or is it just adding latency to the process?
lol - how does posting a review in advvance add latency to the process? It doesn't change the review date.
Of the twenty-two libraries listed, there are a whopping three reviews, two of which are a review of your own library, and one of those is by you where you recommend that we don't accept it into Boost. Not exactly good odds...
My recollection is a whopping 2 reviews. One was just a test of the system. Of course this is not an argument that posting an advance review is a bad idea. What harm can come from it?
The incubator is an experiment. It may succeed, or it may fail. If someone wishes to tie their review to it, that's fine. If they don't wish to, that is fine too.
of course
We know that you want the incubator to succeed, but it is unfair to expect anyone to hold up a review of their library because of it.
Perhaps some future review wizard might want to do such a thing, but so far certainly no one has suggested doing this it for this or any other library in the queue. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/metaparse-Review-Manager-tp4673218p467350... Sent from the Boost - Dev mailing list archive at Nabble.com.
Hello Christophe,
Thank you for volunteering to manage this review and suggesting review dates. I will add you to the review schedule.
Best,
Ron
On 2015-03-15, at 11:54 PM, Christophe Henry
Dear Review Wizards,
I would like to volunteer to be Review Manager for the metaparse library, in agreement with Abel. We would like to suggest May 25 to June 07 for the review. If there are no objections, please sign me up.
Regards, Christophe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (8)
-
Abel Sinkovics -
Christophe Henry -
christophe.j.henry＠gmail.com -
Edward Diener -
Nevin Liber -
Robert Ramey -
Ron Garcia -
Steven Watanabe