Dear list, at boostcon (which was awesome :) we talked about the "review manager starvation" that boost is suffering from. I have offered a proposal on this topic, which seemed to have found a good acceptance at Tuesday evening's session. I'd like to share this proposal on the list now, in order to develop a more concrete policy, based on the proposal and its discussion. Where does the motivation come from? There is a huge amount of motivation in the "boost process". People really work their butts off. But this motivation is not everywhere in "boost world". Obviously it is lacking in the field of being a review manager. The motivation is mostly in the field of developing and contributing high quality generic libraries: Being a boost contributor. * People have a general desire to contribute something useful. * Boost contributors generally are passionate about generic library development. * Boost as a high quality library collection is THE platform for a contributor to place its contribution. * The boost community and list is an opportunity to learn from an elite in the field of generic library programming. * The formal review is both a reality test of the quality of a contribution and an acknowledgement by the experts. * The motivation to get into boost is caused by its high standards, because it makes boost attractive. * This in turn motivates not everyone, but those who are passionate about high quality generic programming. Boost is like a beautiful woman that is not easy to win. And this is a good thing. Let's be honest: Being accepted into boost and winning a beautiful woman has this in common: It extends our ego for a large part. (Whether this is always wise is another story ... but that's where we're after). So this is my suggestion: (1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost. (2) Let's create a new role: The Review Manager Assistant (RMA), who does almost all the work that is needed to manage a formal review. (3) To take on the job as a review manager assistant will be a precondition for a contributor to submit his own library. So we are making the contributors lives even harder with this... We should give them something on "the other side of the coin": (4) Let's foster a general culture of acknowledgement in boost. (5) Contribution must not be discouraged by inaction. (6) Contribution to boost is a win win game: Even if a library is not accepted there will be a value for the contributor and the boost community. To make this more concrete: (ad 1) Standards: The list of standards that a library submitted for review has to fulfill should be very clear, so the contributor can prepare his lib using that check list *and* the RMA can check the submission thoroughly. This list should be more explicit and more transparent than what we have now: To fulfill the list of requirements for a submission which is checked by the RMA is then the first certifiable standard of quality that a library can obtain in the review process. Included in the list of requirement for first time contributors should be: (1.1) 2 previews on the boost mailing list OR 1 boostcon presentation with a sufficient feedback of interest from the community (1.2) Issuing reviews for 2 formal reviews of other contributors. (1.3) Being RMA for another library once. (ad 2) A Review Manager Assistant (RMA) ... (2.1) does all the work that is necessary to check a library submission, organizes the process, moderates and files a final report, (2.2) unburdens the review manager from all kinds of detail work, except for the final verdict. (2.3) rejects the library submission, if it not yet fulfills all requirements. An RMA will probably be highly motivated, because he learns all about the standards and the review process that helps him for his own library project. (ad 5) An RMA is not necessarily needed for a review. If no RMA is found the review manager can do the job himself (current procedure). If an RMA volunteers he can start to organizing the review process. He checks the lib and requests a review manager, if necessary. If no one steps forward, the RMA starts the review process, which can not be halted by mere inaction. Any acceptable review manager can take that role. If no one takes action, the review is managed by the RMA. The RMA files the final report on the review within 2 weeks after it ends. The RM declares the result within 4 weeks after the review on the basis of the RMA's summary. (ad 6) Based on the high standards that are checked rigorously by the RMA a library submitted to boost gets certified as "conforms boost standards" or similar, even if it fails to be accepted into boost. In addition to the accepted boost libraries, there will be a collection of associated libraries (boost friends) that can be listed on a web page and that officially are allowed to use some logo that informs about the certified state. (ad 4) This is a form of acknowledgement for those who took on the project of a boost contribution but didn't make it into the core collection and to make them friends or associates of boost rather than "boost losers". So this is my proposal. I wanted to post this on the list because it is a result of this years boostcon and also the topic is kind of urgent. On the other hand you can not expect me to participate very much in this discussion for the next week, because I am on vacations. I'm looking forward to your thoughts and I will be back next week. Cheers Joachim P.S.: BoostCon was really great this year! Lot's of interesting talks and the sessions that addressed topics of the boost community were quite inspiring and creative. Not to mention the picnic and jam session (very enjoyable despite cold weather).
Zitat von Joachim Faulhaber <afojgo@googlemail.com>:
(3) To take on the job as a review manager assistant will be a precondition for a contributor to submit his own library.
I don't even think that is much of a requirement. I offered to volunteer as a review manager, if only for the reason that the review queue will be shorter once my library is up for review. the response I got from the list and a review wizard was: - you should have a library in boost in order to be a review manager - the lack of review managers isn't the bottleneck of the review process right now, most libraries on the review queue aren't ready for review anyway.
(5) Contribution must not be discouraged by inaction.
(1.1) 2 previews on the boost mailing list OR 1 boostcon presentation with a sufficient feedback of interest from the community
I think (5) is very important (especially when you make it a requirement for reviews), and hard to accomplish. the previews I've seen posted barely got any response, which is no surprise when people don't even have the time to write REviews. so if previews will be a requirement for library submission, a lack of response on the list should not be interpreted as a lack of interest. and to generate some response, I think the PREview process should be formalized in a similar way the REview process is. my library preview (with full documentation) got almost no response, even though I know for a fact that there is interest for such a library from earlier threads, and I'm collaborating with 2 other boost library authors to make our libraries work together. Stefan
2010/5/15 <strasser@uni-bremen.de>:
Zitat von Joachim Faulhaber <afojgo@googlemail.com>:
(3) To take on the job as a review manager assistant will be a precondition for a contributor to submit his own library.
I don't even think that is much of a requirement. I offered to volunteer as a review manager, if only for the reason that the review queue will be shorter once my library is up for review.
This is interesting. You tried to invest your work, being review manager, in order pave the way for *your* library. And this is exactly what I am saying: We should harness the motivation where it is: At the library contributors. Moreover, you tried to apply a strategy to solve a problem that does not exist. The position of a library in the review queue has nothing to do with the date of its review. Look at the past reviews and how they are processed: The single crucial fact is whether you find a review manager that agrees to start the review. This shows another thing: There is an official statement on the Review Schedule web page: "Reviews are usually scheduled on a first-come-first-served basis" which is simply not true for the current practice. But based on this phony statement contributors may start to create ineffective strategies trying to secure their survival in this fatal queue.
the response I got from the list and a review wizard was:
- you should have a library in boost in order to be a review manager
obviously your contribution has been discouraged here. Work that you were willing to do has not been done. The review manager assistant role would allow for exactly this kind of contribution.
- the lack of review managers isn't the bottleneck of the review process right now, most libraries on the review queue aren't ready for review anyway.
which is another strange inconsistency, because a library should be only submitted for a formal review, if it fulfills all requirements for a boost library, so the review could start immediately.
(5) Contribution must not be discouraged by inaction.
(1.1) 2 previews on the boost mailing list OR 1 boostcon presentation with a sufficient feedback of interest from the community
I think (5) is very important (especially when you make it a requirement for reviews), and hard to accomplish. the previews I've seen posted barely got any response, which is no surprise when people don't even have the time to write REviews. so if previews will be a requirement for library submission, a lack of response on the list should not be interpreted as a lack of interest. and to generate some response, I think the PREview process should be formalized in a similar way the REview process is.
my library preview (with full documentation) got almost no response, even though I know for a fact that there is interest for such a library from earlier threads, and I'm collaborating with 2 other boost library authors to make our libraries work together.
If your lib gained attention throughout discussions, you have fulfilled the task of checking if there is interest for your lib. I have experienced the effect myself. Declaring a release or preview after some discussion often generates not a new discussion. (1.1) means that a check for interest has successfully been made which has often be made in the from of "preview". But this can be weakened to: (1.1) 2 previews on the boost mailing list OR 1 boostcon presentation OR a substantial amount of discussion or collaboration on the list that shows a substantial interest in the library. Best, Joachim
----- Original Message ----- From: "Joachim Faulhaber" <afojgo@googlemail.com> To: <boost@lists.boost.org> Sent: Sunday, May 16, 2010 6:33 AM Subject: Re: [boost] A Remedy for the Review Manager Starvation 2010/5/15 <strasser@uni-bremen.de>:
Zitat von Joachim Faulhaber <afojgo@googlemail.com>: - the lack of review managers isn't the bottleneck of the review process right now, most libraries on the review queue aren't ready for review anyway.
which is another strange inconsistency, because a library should be only submitted for a formal review, if it fulfills all requirements for a boost library, so the review could start immediately. _______________________________________________ The question is who will check that the library meets all the review requirements. If I have understood, the review withards can not take this completly in account, as this check is not an automatic task. So we can have libraries on the review schedule that are not ready for review. This can be also the case for libraries that have a review manager. As review manager of the Boost.Task library I can say that, when I accepted this role the library (Boost.Threadpool was named) was almost ready for review. The author changed the library with the intention, of course, of improving its own library and now the library is not ready for review. Should I request to remove myself as review manager, as now the library is not ready for review? Should we remove the libraries that are not ready for review from the review schedule? Should we add a role that checks if the library fullfils the review requirements before it is added? Best, Vicente
vicente.botet wrote:
The question is who will check that the library meets all the review requirements. If I have understood, the review withards can not take this completly in account, as this check is not an automatic task. So we can have libraries on the review schedule that are not ready for review.
Joachim has suggested that is the responsibility of the RMA. Presently, any author making the request must self-police before making the request.
This can be also the case for libraries that have a review manager. As review manager of the Boost.Task library I can say that, when I accepted this role the library (Boost.Threadpool was named) was almost ready for review. The author changed the library with the intention, of course, of improving its own library and now the library is not ready for review.
Should I request to remove myself as review manager, as now the library is not ready for review?
I don't see that as necessary.
Should we remove the libraries that are not ready for review from the review schedule?
Perhaps that is the wrong way to view this. Perhaps there should be a two-stage review queue. The first stage for author's requesting an RMA to look at standards compliance and general review readiness of a proposed library. The second stage for libraries that have passed the readiness review, possibly need a RM, and can be scheduled at any time. In such a system, Boost.ThreadPool may not have reached the second stage queue. If it did, it could have been reverted to the first stage queue due to the rewrite (not due to the name change, of course).
Should we add a role that checks if the library fullfils the review requirements before it is added?
That's the RMA suggestion from Joachim, which I think appropriate. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2010/5/17 Stewart, Robert <Robert.Stewart@sig.com>
vicente.botet wrote:
The question is who will check that the library meets all the review requirements. If I have understood, the review withards can not take this completly in account, as this check is not an automatic task. So we can have libraries on the review schedule that are not ready for review.
Joachim has suggested that is the responsibility of the RMA. Presently, any author making the request must self-police before making the request.
This can be also the case for libraries that have a review manager. As review manager of the Boost.Task library I can say that, when I accepted this role the library (Boost.Threadpool was named) was almost ready for review. The author changed the library with the intention, of course, of improving its own library and now the library is not ready for review.
Should I request to remove myself as review manager, as now the library is not ready for review?
I don't see that as necessary.
Should we remove the libraries that are not ready for review from the review schedule?
Perhaps that is the wrong way to view this. Perhaps there should be a two-stage review queue. The first stage for author's requesting an RMA to look at standards compliance and general review readiness of a proposed library. The second stage for libraries that have passed the readiness review, possibly need a RM, and can be scheduled at any time.
I'd like to keep things simple and make them more consistent and clear. Currently the idea and reality of the review schedule is simple, but it is not handled in a clear and consistent way. Therefore I think, introducing more levels is not helpful. An additional level is already proposed by Robert Ramey, Paul Bristow and others: The "incubator", or "boost candidates". Currently this status already exists and it is labeled: Libraries under construction. This list is maintained by the review wizards and published as part of their regular report. In addition there is the library under construction list on the wiki started by Vicente. In order to keep it simple and make it clearer and more consistent, my suggestion is, that the RMA checks the library thoroughly and only those libraries that fulfill the requirements stay in the review schedule. Checking the requirements of a library a lot of work. Ideally a contributor of a library in his role as RMA does this work thoroughly because he is motivated to study what it means to have a candidate library ready for review. He then accepts the library for the review schedule of rejects it, providing a list insufficiently fulfilled requirements for the submitter. This (1) Makes the review schedule smaller (2) Makes it status clear and consistent (3) Increases the overall quality of libraries in the schedule (4) which makes the job of reviewing a library more effective: We can concentrate on the most important points: Design, usefullness, originallity, ... instead of messing with things like completeness of tests or implementation of warning policies. Moreover, in my proposal, the RMA and the submitter can now schedule the library's review. Because of point (5) of my proposal: "Contribution must not be discouraged by inaction", contributor and submitter can now move on, using the momentum of the project. If a review manager is not there after the RMA accepted the submission there should be an appropriate time period of say 2 weeks to find him. If no one steps forward during that period of time, the RMA carries on managing the review. Best regards, Joachim.
On 17 May 2010 16:45, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Perhaps that is the wrong way to view this. Perhaps there should be a two-stage review queue. The first stage for author's requesting an RMA to look at standards compliance and general review readiness of a proposed library. The second stage for libraries that have passed the readiness review, possibly need a RM, and can be scheduled at any time.
+1 Given the cost of the formal review period, I think this is very sensible. I also like that it gives someone looking for a library a meaningful distinction between a sandbox directory and a review queue entry, since currently the difference is just "sent an email asking to get on the list", which doesn't tell me anything important.
strasser@uni-bremen.de
my library preview (with full documentation) got almost no response, even though I know for a fact that there is interest for such a library from earlier threads, and I'm collaborating with 2 other boost library authors to make our libraries work together.
This sort of thing happens for many reasons as you probably surmised already. The list is fast paced. It's possible that the timing of your preview was poor and that many missed it. It is also possible that there was little to be said that hadn't been said before. You are right in inferring interest from many directions, so I'm glad you weren't discouraged by the limited response to your preview. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 05/15/2010 08:49 AM, Joachim Faulhaber wrote:
So this is my suggestion:
(1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost. (2) Let's create a new role: The Review Manager Assistant (RMA), who does almost all the work that is needed to manage a formal review. (3) To take on the job as a review manager assistant will be a precondition for a contributor to submit his own library.
So we are making the contributors lives even harder with this... We should give them something on "the other side of the coin":
(4) Let's foster a general culture of acknowledgement in boost. (5) Contribution must not be discouraged by inaction. (6) Contribution to boost is a win win game: Even if a library is not accepted there will be a value for the contributor and the boost community.
Although I understand your motivation, I don't share the point of making things harder for potential library submitters. Boost needs more libraries, despite of the situation with reviews. The current standards are already quite high - perhaps, too high - to get new libraries inside, and raising the plank even higher doesn't look like a good idea to me. Also, I don't feel quite comfortable with the idea of giving the steering wheel of the review process to newcomers, which are probably not very experienced in Boost. I've always thought of review managers as of well-recognized and experienced Boost members, who have enough knowledge in the domain of the library being reviewed to understand the reasoning and make the just judgment in the end. Although the suggested RMA role has less responsibilities, the assistant still has to understand and steer the discussion in the right direction. Should he fail, it will have a major impact on the review quality and the final outcome.
On Sat, 15 May 2010 17:23:07 +0400 Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 05/15/2010 08:49 AM, Joachim Faulhaber wrote:
So this is my suggestion:
(1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost. (2) Let's create a new role: The Review Manager Assistant (RMA), who does almost all the work that is needed to manage a formal review. (3) To take on the job as a review manager assistant will be a precondition for a contributor to submit his own library.
So we are making the contributors lives even harder with this... We should give them something on "the other side of the coin":
(4) Let's foster a general culture of acknowledgement in boost. (5) Contribution must not be discouraged by inaction. (6) Contribution to boost is a win win game: Even if a library is not accepted there will be a value for the contributor and the boost community.
Although I understand your motivation, I don't share the point of making things harder for potential library submitters. Boost needs more libraries, despite of the situation with reviews.
+1 I currently have a number of libraries that would prove of utility for Boost, and have been sitting on them for some time, in some cases, over 2 years. Polishing them up, particularly with regard to documentation, keeps me from doing so for the mean time, not to mention the effort/ time to go that extra mile, in-between my other priorities. So I share Andrey's view with respect to the above. I expect any submission to be burdensome on my time, and making things more difficult, would make me think twice about bringing forward some rather worthwhile libraries.
The current standards are already quite high - perhaps, too high - to get new libraries inside, and raising the plank even higher doesn't look like a good idea to me.
-1 I know what you are getting at Andrey, but would not want to lower the bar on what goes into boost.
Also, I don't feel quite comfortable with the idea of giving the steering wheel of the review process to newcomers, which are probably not very experienced in Boost.
+1 I whole-heartedly agree on this one.
I've always thought of review managers as of well-recognized and experienced Boost members, who have enough knowledge in the domain of the library being reviewed to understand the reasoning and make the just judgment in the end. Although the suggested RMA role has less responsibilities, the assistant still has to understand and steer the discussion in the right direction. Should he fail, it will have a major impact on the review quality and the final outcome.
When I think about Joachim's post, it becomes clear what the issue is, and offer a suggestion - maybe some will agree: We have a shortage of review managers, and a shortage of solid (new) contributors to boost, and a number of libraries queued for review, or sitting idle, because there is not enough momentum to drive the process forward.. To up the count of review managers, and hence facilitate the process of evaluating and libraries, and cutting down on a growing review-queue, a better approach might be that once a library is accepted into boost, an author must take on a role of an RMA for some library in the queue, and drive that forward to full review. They'll be experienced up to a point, having gone through the submission process once before, but may need some mentoring along the way nonetheless. Question is, how many libraries from new-comers do we have, in order to cut down the load on existing review managers? Surely, not enough. That being said, existing library authors, should also be cycled through the review queue, ie. right now, I think review managers only raise their hand for the job if they happen to be interested in a particular library - maybe that should also change. And now, I think a little more about Joachim's mail, and the stated reception his ideas had at BoostCon (no, I wasn't there - but take Joachim on his word); and now also recall Beman's email of a while back, asking for persons to come forward and nominate themselves to moderate the list - because: "[existing moderators'] day job responsibilities have changed, or other distractions are preventing them from giving list moderation the attention it deserves." ..this makes me think that there is a call of sorts for "new-blood", because some boosters are moving on, in some respects (not necessarily entirely, but other responsibilities keep them away, and they may not be able to devote as much time as they once did, be it moderation or otherwise). Joachim's email is about addressing some of these issues; but I don't think it hits the mark - and instead likely to shorten queues for lack of submissions alone. I don't claim to have the answers, but I vote No on this one. And yes, I should put some time aside, and bring those libraries of mine forward, that can only be a good thing - and maybe Joachim might have his first RMA too. Cheers, -- Manfred
Manfred Doudar wrote:
Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 05/15/2010 08:49 AM, Joachim Faulhaber wrote:
(1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost.
Although I understand your motivation, I don't share the point of making things harder for potential library submitters. Boost needs more libraries, despite of the situation with reviews.
+1
I currently have a number of libraries that would prove of utility for Boost, and have been sitting on them for some time, in some cases, over 2 years. Polishing them up, particularly with regard to documentation, keeps me from doing so for the mean time, not to mention the effort/ time to go that extra mile, in-between my other priorities.
So I share Andrey's view with respect to the above. I expect any submission to be burdensome on my time, and making things more difficult, would make me think twice about bringing forward some rather worthwhile libraries.
Boost needs an active community. As Joachim pointed out, those submitting libraries are the most highly motivated to be active, so siphoning some of that energy to managing reviews is not unreasonable. If that burden is enough to thwart submission of a library, then it's reasonable to question the commitment of the author to support and maintain an accepted library.
The current standards are already quite high - perhaps, too high - to get new libraries inside, and raising the plank even higher doesn't look like a good idea to me.
-1
I know what you are getting at Andrey, but would not want to lower the bar on what goes into boost.
+1
Also, I don't feel quite comfortable with the idea of giving the steering wheel of the review process to newcomers, which are probably not very experienced in Boost.
+1
This is a misreading of the suggestion or its intent.
When I think about Joachim's post, it becomes clear what the issue is, and offer a suggestion - maybe some will agree:
To up the count of review managers, and hence facilitate the process of evaluating and libraries, and cutting down on a growing review-queue, a better approach might be that once a library is accepted into boost, an author must take on a role of an RMA for some library in the queue, and drive that forward to full review. They'll be experienced up to a point, having gone through the submission process once before, but may need some mentoring along the way nonetheless.
I don't agree with this approach only because after a library has been accepted, the author must typically spend a good deal of time addressing review issues, merge the code into trunk, and begin the process of support and maintenance. That will detract from interest and time to be a RM.
And yes, I should put some time aside, and bring those libraries of mine forward, that can only be a good thing - and maybe Joachim might have his first RMA too.
Please do. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Mon, 17 May 2010 11:16:06 -0400 "Stewart, Robert" <Robert.Stewart@sig.com> wrote:
Manfred Doudar wrote:
Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 05/15/2010 08:49 AM, Joachim Faulhaber wrote:
<snip..>
I currently have a number of libraries that would prove of utility for Boost, and have been sitting on them for some time, in some cases, over 2 years. Polishing them up, particularly with regard to documentation, keeps me from doing so for the mean time, not to mention the effort/ time to go that extra mile, in-between my other priorities.
So I share Andrey's view with respect to the above. I expect any submission to be burdensome on my time, and making things more difficult, would make me think twice about bringing forward some rather worthwhile libraries.
Boost needs an active community. As Joachim pointed out, those submitting libraries are the most highly motivated to be active, so siphoning some of that energy to managing reviews is not unreasonable.
+1 But note, that is not what I was objecting to. Here the suggestion is to roll in role of an RMA and library submitter into one - what I am saying is that both in their own right are process intensive. I'm all for raising the bar, but to put red-tape around submissions IMHO is misled, and should not be as strongly coupled to the lack of review-managers.
If that burden is enough to thwart submission of a library, then it's reasonable to question the commitment of the author to support and maintain an accepted library.
+1 You won't find any argument from me about that one.
The current standards are already quite high - perhaps, too high - to get new libraries inside, and raising the plank even higher doesn't look like a good idea to me.
-1
I know what you are getting at Andrey, but would not want to lower the bar on what goes into boost.
+1
Also, I don't feel quite comfortable with the idea of giving the steering wheel of the review process to newcomers, which are probably not very experienced in Boost.
+1
This is a misreading of the suggestion or its intent.
Even if it were a misreading of the intent, or suggestion - there will inevitably be new library submitters with that are not cognizant with Boost process or expectation, and I'd like to see clarification on how this proposal expects such persons to take on the role of RMA and oversee the expectations sought of them.
When I think about Joachim's post, it becomes clear what the issue is, and offer a suggestion - maybe some will agree:
To up the count of review managers, and hence facilitate the process of evaluating and libraries, and cutting down on a growing review-queue, a better approach might be that once a library is accepted into boost, an author must take on a role of an RMA for some library in the queue, and drive that forward to full review. They'll be experienced up to a point, having gone through the submission process once before, but may need some mentoring along the way nonetheless.
I don't agree with this approach only because after a library has been accepted, the author must typically spend a good deal of time addressing review issues, merge the code into trunk, and begin the process of support and maintenance. That will detract from interest and time to be a RM.
Note, I didn't say when a library submitter would next be called up for RM duties - but in writing what I did, it had also crossed my mind the duties that remain on submitters whose libraries have been accepted. I think it would stand to reason, that after process of merging into the trunk and addressing issues pertaining to post-acceptance, a library author would reasonably be called up to be an RM at some future time thereafter.
And yes, I should put some time aside, and bring those libraries of mine forward, that can only be a good thing - and maybe Joachim might have his first RMA too.
Please do.
I hope I just might. Cheers, -- Manfred
2010/5/15 Andrey Semashev <andrey.semashev@gmail.com>:
On 05/15/2010 08:49 AM, Joachim Faulhaber wrote:
So this is my suggestion:
(1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost. (2) Let's create a new role: The Review Manager Assistant (RMA), who does almost all the work that is needed to manage a formal review. (3) To take on the job as a review manager assistant will be a precondition for a contributor to submit his own library.
So we are making the contributors lives even harder with this... We should give them something on "the other side of the coin":
(4) Let's foster a general culture of acknowledgement in boost. (5) Contribution must not be discouraged by inaction. (6) Contribution to boost is a win win game: Even if a library is not accepted there will be a value for the contributor and the boost community.
Although I understand your motivation, I don't share the point of making things harder for potential library submitters. Boost needs more libraries, despite of the situation with reviews. The current standards are already quite high - perhaps, too high - to get new libraries inside, and raising the plank even higher doesn't look like a good idea to me.
What I am suggesting to add is to intensify the process of acquiring the full picture of the boost standards and the benefits and mechanics of the review process. As RMA a contributor not only learns about the boost standards and requirements from his own project, but by assisting in the review of a fellow's library. Looking from a different view always gives us new insights and options. And the motivation of the library contributors is used to help the Review Managers to get their job done with less effort.
Also, I don't feel quite comfortable with the idea of giving the steering wheel of the review process to newcomers, which are probably not very experienced in Boost. I've always thought of review managers as of well-recognized and experienced Boost members,
my basic assumption is that boost contributors are competent, skilled, passionate about generic programming and sometimes probably also pretty experienced in the field of interest. Being attracted from boost and undertaking the adventure (ordeal ;) to bring a library project into boost is simply not done by some half baked average skilled and mediocre motivated coders. At boostcon for instance, I have seen *very* gifted people that are not yet established boost authors. Why waste these resources.
... who have enough knowledge in the domain of the library being reviewed
a contributor might have an especially deep knowledge in the problem domain. He as RMA could support a seasoned booster willing to manage the review although being not an expert for the lib's specific problem domain.
... to understand the reasoning and make the just judgment in the end.
they can build a team and have more fun. Finally the RM decides anyway.
Although the suggested RMA role has less responsibilities, the assistant still has to understand and steer the discussion in the right direction.
I disagree here. The majority of reviews are steered by the reviewers, the participants in the discussion and the author. Most of the time the RM is impartial and does not influence the discussion. Moreover in the frequent case of a clear vote from the list, the RM can steer pretty little anyway.
Should he fail, it will have a major impact on the review quality and the final outcome.
Again, quality and outcome is mostly dependent on the reviewers, the participants in the discussion and the author. Regards, Joachim.
Joachim Faulhaber wrote:
(ad 2) A Review Manager Assistant (RMA) ... (2.1) does all the work that is necessary to check a library submission, organizes the process, moderates and files a final report, (2.2) unburdens the review manager from all kinds of detail work, except for the final verdict. (2.3) rejects the library submission, if it not yet fulfills all requirements.
Could you clarify how a review manager can make a "accepted/not accepted" decision in good faith without personally reading all discussion? This seems only possible RM considers RMA at least as experienced and himself, in which case why not such RMA cannot be a regular release manager. In other words -- if you force every author of proposed library to be an RMA, then, on the average, he might not be the best person to make decision on other libraries, and then you need a real RM to real all discussions and decide, which does not seem to improve on anything. - Volodya
2010/5/15 Vladimir Prus <vladimir@codesourcery.com>:
Joachim Faulhaber wrote:
(ad 2) A Review Manager Assistant (RMA) ... (2.1) does all the work that is necessary to check a library submission, organizes the process, moderates and files a final report, (2.2) unburdens the review manager from all kinds of detail work, except for the final verdict. (2.3) rejects the library submission, if it not yet fulfills all requirements.
Could you clarify how a review manager can make a "accepted/not accepted" decision in good faith without personally reading all discussion?
(1) The RM as a responsible human being has complete freedom to read as much as he wants from the discussion. (2) In many cases there is a clear majority vote, so the overall decision is pretty clear anyway. (3) Being a team the RM learns that the RMA is a very competent person and he develops confidence in the RMA's judgement. BTW this kind of delegation in decision making is very common in may areas. (4) The RM is not intended to be unburdened in all cases. If there is a controversial discussion and a tight vote, then the RM is requested to take responsibility and use his experience to find a final decision. Still the RMA may help as a partner in this decision process.
This seems only possible RM considers RMA at least as experienced and himself,
maybe he is and maybe not. Still points (1) and (2) can be applied.
in which case why not such RMA cannot be a regular release manager.
(1) because he usually is not independent. There may occur a (secret) culture of contributors to help each other to make it into boost. (2) A general mechanics of elites that only those who are already members control access.
In other words -- if you force every author of proposed library to be an RMA, then, on the average, he might not be the best person to make decision
the design is such that the RM has the responsibility to make the decision. Only the RMA does all to make his life easier.
on other libraries, and then you need a real RM to real all discussions and decide, which does not seem to improve on anything.
Best regards, Joachim.
Joachim Faulhaber wrote:
Joachim Faulhaber wrote:
Could you clarify how a review manager can make a "accepted/not accepted" decision in good faith without personally reading all discussion?
(1) The RM as a responsible human being has complete freedom to read as much as he wants from the discussion.
I see the RM as completely responsible for the decision in this proposal. How the RM reaches that decision must be, as it presently is, left to the RM's discretion. The RMA is an added resource that reduces the RM's administrative burden. I took Joachim's suggestion to be that the RMA would act as an RM, up to the point of announcing a decision on the list, instead passing collected and generated information to the RM for consideration. If the RM trusts the RMA's input, or the RM has independently verified the RMA's input, the RM may follow the RMA's decision, even going so far as to copy and paste the RMA's suggested summary message to the list. Given that the RMs will be selected from the current pool, which implies Boost experience, knowledge, judgment, etc., and we've trusted them heretofore, this suggestion would not violate current expectations. Joachim implied the notion of oversight, but could have been clearer on that point.
(2) In many cases there is a clear majority vote, so the overall decision is pretty clear anyway.
This is a case in which the RM can readily forward the RMA's report, thus saving the RM a great deal of time and effort. This is a point Joachim forgot to stress: the current (small) pool of potential RMs is busy and often unwilling to take on yet another *volunteer* responsibility.
(3) Being a team the RM learns that the RMA is a very competent person and he develops confidence in the RMA's judgement. BTW this kind of delegation in decision making is very common in may areas.
This also means that, should the RMA's own library be accepted into Boost in the future, the author can then be trusted to be a RM in the future. IOW, being an RMA is a means to train and mentor others to be competent RMs in the future. Simply being an accepted library author is scant proof of ability to be a RM.
(4) The RM is not intended to be unburdened in all cases. If there is a controversial discussion and a tight vote, then the RM is requested to take responsibility and use his experience to find a final decision. Still the RMA may help as a partner in this decision process.
There are likely cases in which those qualified to be RMs feel unequal to being the RM for a particular library because of a lack of domain knowledge. In such cases, an RMA with strong domain knowledge can augment the other characteristics desirable in a RM, so the team enables a potential RM to be the RM for a library which would otherwise avoid the role. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 17 May 2010 17:01, Stewart, Robert <Robert.Stewart@sig.com> wrote:
I took Joachim's suggestion to be that the RMA would act as an RM, up to the point of announcing a decision on the list, instead passing collected and generated information to the RM for consideration. If the RM trusts the RMA's input, or the RM has independently verified the RMA's input, the RM may follow the RMA's decision, even going so far as to copy and paste the RMA's suggested summary message to the list.
This sounds substantially like promoting the current pool of RMs to RWs, and letting new people into the RM pool. What good would an untrusted RMA be? If the RM has to independently verify everything said by the RMA, it seems like the RMA wasn't of any real use, since for a consensus issue, verification can't be done just by looking at the sources mentioned by an untrusted RMA.
Scott McMurray wrote:
On 17 May 2010 17:01, Stewart, Robert <Robert.Stewart@sig.com> wrote:
I took Joachim's suggestion to be that the RMA would act as an RM, up to the point of announcing a decision on the list, instead passing collected and generated information to the RM for consideration. If the RM trusts the RMA's input, or the RM has independently verified the RMA's input, the RM may follow the RMA's decision, even going so far as to copy and paste the RMA's suggested summary message to the list.
This sounds substantially like promoting the current pool of RMs to RWs, and letting new people into the RM pool.
The RWs don't make review decisions and aren't required, so far as I know, to follow reviews. RWs can intervene if something is amiss, of course. The goal of this proposal is, however, to get more people into the RM pool to accelerate reviews (when the lack of an RM is the problem).
What good would an untrusted RMA be? If the RM has to independently verify everything said by the RMA, it seems like the RMA wasn't of any real use, since for a consensus issue, verification can't be done just by looking at the sources mentioned by an untrusted RMA.
Most likely, an RM will be reading much, if not all, of the review traffic and will be forming an impression of the review direction. If the review is lopsided for or against a library, the RMA will have an easy job and the RM will likely not contradict the RMA's conclusions. In that case, the RM will still evaluate the draft announcement the RMA will write in order to help the RMA improve in the future. In that scenario, the RMA will reduce the RM's workload substantially. If the review is less certain, the RM will likely have to spend the usual amount of time reading all of the message traffic and producing an independent decision and announcement. If the RMA's decision or announcement differs substantially, then the RM can discuss the differences with the RMA in order to help the RMA improve. In that scenario, the RMA can actually increase the RM's workload, of course. This will help to increase the available pool of RMs while, it is hoped, leveraging the limited time of the current members of that pool. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2010/5/17 Scott McMurray <me22.ca+boost@gmail.com>:
On 17 May 2010 17:01, Stewart, Robert <Robert.Stewart@sig.com> wrote:
I took Joachim's suggestion to be that the RMA would act as an RM, up to the point of announcing a decision on the list, instead passing collected and generated information to the RM for consideration. If the RM trusts the RMA's input, or the RM has independently verified the RMA's input, the RM may follow the RMA's decision, even going so far as to copy and paste the RMA's suggested summary message to the list.
The most important function of an RMA is to *support* an RM so the RM can do his job with a minimal investment of time and that he can concentrate on the important issues: Evaluation of the controversial points of the discussion, weighting the conditionals and finding a final decision particularly if the discussion was controversial and the vote is tight. The way in which the RM wants to be supported is essentially up to him. But it is quite obvious that this usually will imply to do the jobs that cost time and work: * A thorough check if the submitted library fulfills the requirements. Currently this check has to be done by the RM. If it is not done thoroughly, the violated requirements tend to pop up during the review, which is usually annoying for the reviewers: In the past there where such instances: E.g. Missing tests, insufficient docs, examples didn't compile, too many warnings etc. indicating that RMs frequently lack time or motivation. Contributors, cause they are facing to undergo the same check, will likely be very good gatekeepers for that. For them doing the check thoroughly is effective, cause they learn for their own project. * Technical announcements: Advance notice, announcement of dates. * Compiling statistics and other technical summaries of the review. * Report about the review's result as a draft for the RM.
This sounds substantially like promoting the current pool of RMs to RWs, and letting new people into the RM pool.
The RMA usually will not make decisions and will not issue a final verdict about the acceptance of a library.
What good would an untrusted RMA be?
My basic assumption is that boost contributors are trustworthy, competent and passionate people. They are attracted by high quality generic programming and accept high standards and tough discussions. There are a lot of opportunities to gain trust in them: Postings about their work on the list. Participation in discussions. Often also boostcon participation / boostcon talks. The RMA job in an additional oppotunity. I am shure contributors that volunteer for RMA can be trusted in the vast majority of cases. And if there were a case where someone turns out to be a real failure? (1) The RM may cancel the collaboration with this RMA and look for another OR (2) does the job himself, in which case he has the same workload as he had in the old model. Regards, Joachim.
On 18 May 2010 07:13, Joachim Faulhaber <afojgo@googlemail.com> wrote:
My basic assumption is that boost contributors are trustworthy, competent and passionate people. [...] I am shure contributors that volunteer for RMA can be trusted in the vast majority of cases.
Then why not let them become RMs, and just allow the RWs to call a mistrial if they think it necessary?
2010/5/18 Scott McMurray <me22.ca+boost@gmail.com>:
On 18 May 2010 07:13, Joachim Faulhaber <afojgo@googlemail.com> wrote:
My basic assumption is that boost contributors are trustworthy, competent and passionate people. [...] I am shure contributors that volunteer for RMA can be trusted in the vast majority of cases.
Then why not let them become RMs, and just allow the RWs to call a mistrial if they think it necessary?
This would let the structure remain simpler, which would be nice. On the other hand: (1) RW's responsibility to observe reviews closely would grow substantially. This would imply much more work for them. (2) New contributors, although trustworthy, generally have less experience within boost. Therefore ... (3) ... new contributors may not be willing to take the responsibility for decisions although they may be willing to support a review. (4) Although a new contributor is likely to be more motivated, in his position he may not be as impartial as an already accepted boost author. He may tend to accept a fellows project in order to pave the way for his own library. He may tend to reject a competitors project, being afraid that its acceptance reduces the chances for his library. Best, Joachim.
On 18 May 2010 08:08, Joachim Faulhaber <afojgo@googlemail.com> wrote:
(1) RW's responsibility to observe reviews closely would grow substantially. This would imply much more work for them.
Is there a process for getting new RWs? The responsibility here is what your proposal has the RMs do, so perhaps what we need is for some of the current RMs to get promoted to RWs.
(2) New contributors, although trustworthy, generally have less experience within boost. Therefore ... (3) ... new contributors may not be willing to take the responsibility for decisions although they may be willing to support a review.
I think this is the best argument for your proposal. I've seen people worried about whether they're eligible to give a review, let alone manage one, so getting over that hurdle is good. I wonder though whether it couldn't be done the other way round, with a RM given a RW "mentor" who can help resolve the insecurities, and gives visibility for the RW team that would be making any decision about calling off a review.
(4) Although a new contributor is likely to be more motivated, in his position he may not be as impartial as an already accepted boost author. He may tend to accept a fellows project in order to pave the way for his own library. He may tend to reject a competitors project, being afraid that its acceptance reduces the chances for his library.
This is an interesting question, but I think orthogonal to which procedure. I suppose the question is whether domain experts -- which, to submit a competing library they probably would be -- are better used as RMs or Reviewers. Having them wear the reviewer hat and letting the domain non-expert RM deal with the bias might be the better way.
Scott McMurray wrote:
On 18 May 2010 08:08, Joachim Faulhaber <afojgo@googlemail.com> wrote:
(1) RW's responsibility to observe reviews closely would grow substantially. This would imply much more work for them.
Is there a process for getting new RWs? The responsibility here is what your proposal has the RMs do, so perhaps what we need is for some of the current RMs to get promoted to RWs.
The role of RW is to manage the general review process, not reviews. RW is a fixed role. By contrast, there are no RMs until someone volunteers to be one for a particular library. It is then that someone assumes responsibility for all of the expected work. Having an RMA means that a busy person who will not volunteer to be a RM for an upcoming library due to lack of time, might do so because the RMA can reduce the workload. The RMA is motivated to do the work for the many reasons already cited. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joachim Faulhaber Sent: Saturday, May 15, 2010 5:49 AM To: boost@lists.boost.org Subject: [boost] A Remedy for the Review Manager Starvation
So this is my suggestion: (1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost.
Strong disagreement - we need to make it *easier* to meet Boost Quality (and yet improve quality too). The main improvement should come from more eyes viewing the code - isn't that the strength of Open Source? To achieve this we need a way to get more 'candidate code' in real-life use by more people for a much longer period of time. Then more people are in a position to make an informed review (we are shorter of *reviewers* as much as review managers). And it should make it easier to find people willing to be review managers - they need to feel comfortable that they know a reasonable amount about the library. Robert Ramey's suggestions would help achieve this. (Sadly I was not able enjoy his bombastic delivery by attending BoostCon - distance, cost, time, Welcome from Homeland Security ... ;-) So I believe we most need a 'Boost Candidates' section with a much lower bar to entry, but with regular testing, and Trac. Paul PS We also need easier systems for uniform documentation - an important part of Quality is good documentation. --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
On Sat, May 15, 2010 at 1:07 PM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joachim Faulhaber Sent: Saturday, May 15, 2010 5:49 AM To: boost@lists.boost.org Subject: [boost] A Remedy for the Review Manager Starvation
So this is my suggestion: (1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost.
Strong disagreement - we need to make it *easier* to meet Boost Quality (and yet improve quality too).
The main improvement should come from more eyes viewing the code - isn't that the strength of Open Source?
To achieve this we need a way to get more 'candidate code' in real-life use by more people for a much longer period of time.
Ditto. That's the heart of the issue, I think.
<snip>
So I believe we most need a 'Boost Candidates' section with a much lower bar to entry, but with regular testing, and Trac.
Good idea. A two week formal review cannot replace the process of discovery and creativity that comes from interacting with and adapting to users over time. In order to mature in quality, new libraries don't need more reviewers, they need more users. I think if Boost packaged and distributed a separately branded, un-reviewed "Candidate" or "Friends" collection that could help incubate new libraries. Just brainstorming... Boost could do something similar to Debian's "unstable" release. Or you could extend the idea of Boost Sandbox with nightly builds and regressions, which would be enormously helpful to new libraries. There could be a regular Boost Sandbox "release" in the form of a .zip or tarball with a link on boost.com. The Sandbox could grow as desired, while only the most popular/useful/mature libraries come up for review and eventually graduate to become full-fledge Boost libraries. This could give boost users and new authors better access to each other without undermining the quality expectations of the official, peer-reviewed Boost release. Daniel Walker
On 15 May 2010 20:32, Daniel Walker <daniel.j.walker@gmail.com> wrote:
On Sat, May 15, 2010 at 1:07 PM, Paul A. Bristow
The main improvement should come from more eyes viewing the code - isn't that the strength of Open Source?
To achieve this we need a way to get more 'candidate code' in real-life use by more people for a much longer period of time.
Ditto. That's the heart of the issue, I think.
I'd also be interested in this. I picture three releases: 1) Boost.Candidate The goal here would be a quick way for people to grab what's out there, find something they're interested in, and, if possible, use it. I'd love to see this "released" automatically every week by a script. Getting in should be as easy as the developer adding the name of their sandbox subdirectory to a textfile in the sandbox root (which would be automatically removed if the script had any problem grabbing everything from that directory). 2) Boost.Main What we have right now. While it wouldn't need any changes, it might help the schedule to say that a library can't go to formal review until there are 3 "accept" preliminary reviews filed, which can be done at any point while the library in question is in Candidate. This would be released twice a year, say Q2 and Q4 (and people can always use it from candidate if they can't wait the extra 4 months over the current process). 3) Boost.Foundation A community vision of TR2. Essential parts that have passed some extra bar. I see this as for portability necessities and things needed to write other libraries, rather than implementations of specific things, so it would probably get Thread and MPL, but likely not GIL or CRC, for instance. I suspect less than half of the current libraries should end up in here. This would get one release a year in Q1, with a bugfix release in Q3 if needed. ~ Scott
On Sat, May 15, 2010 at 10:07 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joachim Faulhaber Sent: Saturday, May 15, 2010 5:49 AM To: boost@lists.boost.org Subject: [boost] A Remedy for the Review Manager Starvation
So this is my suggestion: (1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost.
Strong disagreement - we need to make it *easier* to meet Boost Quality (and yet improve quality too).
The main improvement should come from more eyes viewing the code - isn't that the strength of Open Source?
To achieve this we need a way to get more 'candidate code' in real-life use by more people for a much longer period of time.
+1 in principle, there is no substitute for feedback from actual use of a library, but IMO this contradicts with your disagreement: requiring 'candidate code' to be used in real life by more people would make it harder for library developers, not easier. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Emil Dotchevski Sent: Saturday, May 15, 2010 8:21 PM To: boost@lists.boost.org Subject: Re: [boost] A Remedy for the Review Manager Starvation
On Sat, May 15, 2010 at 10:07 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joachim Faulhaber Sent: Saturday, May 15, 2010 5:49 AM To: boost@lists.boost.org Subject: [boost] A Remedy for the Review Manager Starvation
So this is my suggestion: (1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost.
Strong disagreement - we need to make it *easier* to meet Boost Quality (and yet improve quality too).
The main improvement should come from more eyes viewing the code - isn't that the strength of Open Source?
To achieve this we need a way to get more 'candidate code' in real-life use by more people for a much longer period of time.
+1 in principle, there is no substitute for feedback from actual use of a library, but IMO this contradicts with your disagreement:
requiring 'candidate code' to be used in real life by more people would make it harder for library developers, not easier.
It would mean more work for developers dealing with the feedback while in 'candidate' mode, but it would make it *easier to achieve Boost Quality* and get over the bar. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Hi Paul, 2010/5/15 Paul A. Bristow <pbristow@hetp.u-net.com>:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joachim Faulhaber Sent: Saturday, May 15, 2010 5:49 AM To: boost@lists.boost.org Subject: [boost] A Remedy for the Review Manager Starvation
So this is my suggestion: (1) Let's increase the standards: Let's make it more difficult for a library to be accepted into boost.
Strong disagreement - we need to make it *easier* to meet Boost Quality (and yet improve quality too).
I don't intended my proposal to be in competition to the incubator ideas of yours and others that has also been presented by Robert Ramey at boostcon. I think both approaches can be helpful. The incubator approach helps to get more projects into an "active and attractive" state and to make it more easy to gather feedback about them. The RMA proposal helps to bring more momentum to the state where polished libraries want to achieve membership in the core boost colletion and to distribute the work to more and more motivated hands.
The main improvement should come from more eyes viewing the code - isn't that the strength of Open Source?
unfortunately I am afraid more lurking eyes won't make much of a difference. In the end some form of action is required, e.g. feedback, voting, reviewing. To facilitate this would surely be great.
To achieve this we need a way to get more 'candidate code' in real-life use by more people for a much longer period of time.
Then more people are in a position to make an informed review (we are shorter of *reviewers* as much as review managers).
And it should make it easier to find people willing to be review managers - they need to feel comfortable that they know a reasonable amount about the library.
Robert Ramey's suggestions would help achieve this.
I support many of Roberts and your ideas. But at least some of them seem to require a reasonable amout of work. Cheers, Joachim
participants (11)
-
Andrey Semashev -
Daniel Walker -
Emil Dotchevski -
Joachim Faulhaber -
Manfred Doudar -
Paul A. Bristow -
Scott McMurray -
Stewart, Robert -
strasser＠uni-bremen.de -
vicente.botet -
Vladimir Prus