On 14/03/2017 12:20, Vinnie Falco via Boost wrote:

On Tue, Mar 14, 2017 at 8:01 AM, Niall Douglas via Boost wrote:

...

I look forward to seeing what people think.

These are great ideas, and I am glad someone is bringing this up!

With respect to payments, let me offer some thoughts. Boost is used around the world so it might be difficult to pay someone in Europe in USDs. How about using cryptocurrency (Bitcoin for example)? This solves the problem of receiving payment.

Boost has a long standing payment system setup which can pay out in any of a cheque, wire transfer, Paypal etc to any recipient in the world bar those not permitted by US law. It isn't handled directly by Boost, but rather by the SFF which manages Boost's money for us.

Where is this money coming from? Corporate sponsorships? I like it!

Boost has been accumulating more money than it spends for nearly a decade now. I believe we are the wealthiest open source org in the SFF's umbrella. However as has been found in the past, if there is a worthy cause then a drum can be banged to scare up donations from corporates. We as a community simply need to decide a consensus on what to do. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Tue, Mar 14, 2017 at 8:33 AM, Frédéric Bron via Boost wrote:

Slitghtly out of topic: I volunteered for reviewing boost.nowide on March 4th. Maybe I did not send my email to the right list (boost@)? Maybe we should make it clearer how to volunteer?

Hi Frédéric, E-mail the review wizard, Ron (Ronald Garcia, (rxg at cs dot ubc dot ca)), with your desire to manage the review. And thanks! Glen

I personally hope none of the suggestions 1, 2, 3, or 4, are implemented. I really worry about this desire to bring monetary value or payment into the Boost review process.

I also have some concerns when I see the same person put forward similar ideas that all revolve around paying or hiring individuals.

Every single major open source org has eventually ended up having to pay people to do the admin which keeps that org working if they wish to keep growing. And that's an empirical hard fact. Boost can decide to not do that, and to date it has decided to not do that. All empirical evidence suggests that that decision will gum up growth and put a natural cap on Boost's size and relevance to latest C++. A few years ago Boost had a problem of no new libraries at all in three years. That problem has been fixed, and I'll immediately admit surprise tinged with gratitude that it didn't require paying people to fix it. An ongoing current problem is lack of maintenance. A system of corporate sponsorship of maintenance has helped address that, and in some places it's worked well, but not in others. But I'll also admit surprise tinged with gratitude that anything non-monetary worked here at all. A big surprise to me is how much has been done on automated testing without paying people for it (though we did pay for some of their hardware and in some cases for renting infrastructure). My hat is off in thanks to those in question. Thank you. So, one could entirely argue and with good supporting evidence that you don't need to pay people to do this stuff, and you would be correct. However that does not mean that if you did pay people, that it wouldn't have gone a lot better again. And there is a much stronger argument that the fact I raised payment for stuff and people reacted violently against it helped get people to volunteer to solve the problem. So in a way, it's all good and it all helps.

Niall, I understand you have good intentions, and I (like many others) appreciate your administration of GSOC, but the repetition of these ideas looks frighteningly like you want to address any employment or financial needs that you have by getting Boost to hire you for more things. Maybe I'm drawing too many conclusions from your blog posts[1].

Heh. Funnily enough I'm coming towards the end of my active participation in C++, you've got about a year left of me being annoying before I step back majorly. Even this year you won't be seeing me at CppCon this year as I begin to step back. (To explain, we've been having children since 2013 for which my wife had to give up her career and I was the sole earner. She wishes to return to her career soon, and for which all my non-work time will be needed to support her, so no more outside-of-work coding for me for a few years until she's reestablished and back to earning. I'll be resigning from all things I volunteer for including all mailing lists, and doing nothing but basic maintenance on my open source libraries, no new code nor new features) You are right though that in *ideological* terms I think Boost and the C++ Standard Foundation ought to hire people to work on the wider C++ ecosystem, just as other major programming languages do. Whether that should be me or someone else should be the result of a competitive public tendering process.

I'm curious: The libraries that too niche or esoteric for any review manager to be interested (or reviewers to come forward) - to which libraries are you referring?

Safe Numerics is an excellent example. I've never used anything like such a thing, and despite it looking to me like a great library (and I did look over it in depth including its source code), I was aware enough of how little I knew about that domain. I definitely could not have review managed that library, I don't know enough about that domain at all to have a useful opinion.

In any case, I look forward to the mechanics of Boost being improved. I hope they're improved by better means that do not involve solving someone's employment needs.

Nobody is going to be employed permanently on bits of piece work, it's an awful life not knowing where rent will come from. Any of the remote working consultants I know prefer nice, long contracts where available, ideally six months or a year or longer. That said, when you're between those long contracts and during when you're negotiating new contracts (which can take two months like the one I'm negotiating right now has), if there were bits of small piece work available, I'm sure I and many others in this profession would put a bid in to fill the short gap at a very discounted hourly rate. That would be excellent value for money for the C++ ecosystem, and therefore a very rational system to establish. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 14/03/2017 12:57, Stefan Seefeld via Boost wrote:

But pushing for accelerated growth is certainly not among the things I would promote.

I know what you're saying. But remember the "crushing under its own weight" is an active choice of not reaching consensus on anything different by the community. We, as a group, choose to be crushed. We could choose different. We have the resources. I try to keep asking: "what is best for the larger C++ ecosystem?" * Is high quality peer review valuable? YES * Is a staging ground before standardisation valuable? YES So let's make Boost do those things as best we can. That means admitting as many high quality C++ libraries as we can, and encouraging as many people as possible to consider submitting their C++ library to Boost. I am afraid that means growing as fast as we can.

I always thought that the "self-organized" nature of Boost processes (including the review process) is a means to select the "generally useful" submissions from the "esoteric corner case" ones. In other words: if a library submitter can't gather enough interest in the wider community to find reviewers and a review manager, it implies the submitted project is finally not a good candidate for addition.

It's a valid point that I have significant sympathy with. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

None of these points involve the need to increase the amount of accepted libraries at any cost. As others have pointed out, Boost's livelihood does not directly depend on the number of accepted libraries but just on their quality. Adding money to the mix favors adding libraries at all cost, non-withstanding their quality or real-world-need, emphasizing the commercial aspect.

As you usual, you deliberately misquote or cherry pick quote people and then make a big song and dance about your reinterpretation of what they said. It's tiring and irritating. I never said payment for adding new libraries. I did say payment for new library REVIEWS and especially the **ADMIN** of reviewing them. Rejection of a submitted library is just fine. Letting submitted libraries stew for up to SEVEN years before getting reviewed is UNACCEPTABLE if Boost is to remain even remotely relevant. I now snip the usual Fear, Uncertainty and Doubt you like to sow Hartmut whenever actual REAL CHANGE is proposed or discussed, leaving us with this which had some value:

This would also raise a lot of questions I wouldn't even know how to start answering. Like:

- What's next? Letting library authors pay for their library being reviewed? After all THEY are the most interested parties in adding their work to Boost...

What has that to do with anything being proposed? Nothing.

- Or perhaps accepting 'donations' from companies earmarked for paying a review manager, further skewing the review process?

What has that to do with anything being proposed? Nothing. Totally separate matter.

- Will every review manager receive the money? Regardless of the quality of how the review is managed? What would be the criteria for a review manager doing a good enough job to receive the payment? Who decides on this? How many reviews would be a single person be allowed to perform?

These are good questions. Plenty of possibilities. None are showstoppers to the idea, not even remotely.

- Would previous review managers receive an equally generous payment for the libraries reviewed in the past? If yes - why, if no - why not?

Another good question, and again not insolvable in either direction. Not a showstopper. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 14.03.2017 17:53, Robert Ramey via Boost wrote:

"Only those who have managed a boost review can expect their library submissions to be to be reviewed."

The qualifications needed to write a boost-grade library and the qualifications needed to manage a review aren't the same. I don't think it's sensible to couple the two tasks in the suggested way. But I'm still concerned that most of the replies to the OP are far too short-sighted: While I can feel the pain of a developer waiting for a review, I don't think anything can be done about this, on a strictly administrative level. I'd actually be curious to see how many of the existing Boost libraries are actively being maintained or developed. Far too often a library managed to get through the review process, only to be orphaned later on because the original author has lost interest and or there wasn't enough critical mass in the user/developer community to keep the project going. In an ideal world, a library would start its life within an existing community of users and developers, so finding reviewers (including someone willing to manage the review process) shouldn't be hard. In contrast, if a library is stalled in the review queue, perhaps that hints at there not being enough interest to [use, develop, review] it ? So who would be helped if the review process was accelerated artificially ? What if the criteria for acceptance (into Boost) would be changed such that an active user and developer community was a prerequisite, as a way to predict the project's livelihood ? Again, this would work best if the library would be much more autonomous, so there was much less integration work required to bring a library on board. Boost wouldn't subsequently have to care for maintenance of the library. If a given library would be unmaintained for an extended period of time, it would simply be removed from Boost. No single person (or group of persons) would have to be responsible for certain tasks involving all of Boost (including but not limited to: building, testing, releasing), making the overall (umbrella) organization much simpler to manage and contribute to. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 3/14/17 16:07, Gavin Lambert via Boost wrote:

On 15/03/2017 12:00, Stefan Seefeld via Boost wrote:

...

On 14.03.2017 17:53, Robert Ramey via Boost wrote:

...

"Only those who have managed a boost review can expect their library submissions to be to be reviewed."

The qualifications needed to write a boost-grade library and the qualifications needed to manage a review aren't the same. I don't think it's sensible to couple the two tasks in the suggested way.

Perhaps I am wrong, but I think it's already coupled the other way around: currently in order to be a review manager you must first have submitted (or otherwise maintain) a successful Boost library.

It isn't coupled. The requirement is here: http://www.boost.org/community/reviews.html#Review_Manager -- Michael Caisse Ciere Consulting ciere.com

On 03/15/17 00:53, Robert Ramey via Boost wrote:

I propose the follwing text to be placed in the appropriate place.

"Only those who have managed a boost review can expect their library submissions to be to be reviewed."

I think this is not a good idea. This puts a lot more pressure on the library submitters, who already have to meet a quite high bar of quality set by Boost. Besides, a review manager is expected to be an expert (more or less) in the domain of the library being reviewed - something we can't tell if it's true or not about a new person who have just submitted his first library for a review.

On 3/14/17 6:22 PM, degski via Boost wrote:

On 14 March 2017 at 15:53, Robert Ramey via Boost wrote:

...

"Only those who have managed a boost review can expect their library submissions to be to be reviewed."

And the corollary: "Only those who had their library submission accepted are eligable to be a review manager."

The second does not follow from the first. It's not a corollary Robert Ramey

On 14 March 2017 at 22:25, Robert Ramey via Boost wrote:

A much more interesting question: Why did you not submit a review yourself? I think it would have been helpful to me as an author and to you in better understanding your own concerns.

Because I think the idea is flawed from the start. int x = 2 * 2; is wrong in principle, correct would be: int64_t x = 2 * 2; This is what happens in the CPU. C and C++ are wrong to allow multiplying two ints and assign the result to an int (the cpu does not do that!). Then of course there is the issue of two's-complement, clouding stuff even further. If one wants to be safe, the only real option is to use bignums (GMP, whatever). This is what implementations of languages like prolog and scheme do (I'm thinking of SWI-Prolog and Racket f.e.). Shifts (left of right) get a whole different meaning... Reals (floats, doubles, quads) are already so broken in many ways, that I wouldn't even like to comment. Even MPFR doesn't add much here, except increased (but still relative) precision. I'm of the opinion that the only real option (if one wants performance) is to be very aware, learned and carefull regarding the issues, when dealing with numbers in C or C++. And this is far from simple, signed zeros, subnormal numbers, infinities, NaN's, roundings... One of the review questions is: "would you use it?" Sorry, no! degski

degski wrote:

Because I think the idea is flawed from the start.

int x = 2 * 2;

is wrong in principle, correct would be:

int64_t x = 2 * 2;

That's what the library does (in 'automatic' promotion mode, which should be only mode in my opinion.) When you multiply two integers, one having range [0, M] and the other having range [0,N], you get an integer with range [0, M*N]. So safe * safe gives safe (almost).

On 15 March 2017 at 17:06, Andrey Semashev wrote:

...

This is what happens in the CPU.

Actually, no.

http://support.amd.com/TechDocs/25112.PDF (I didn't go through the 5 manuals to find a better quote, but they are there!) Chapter 3, Page 61. "Using 64-bit registers, the entire product can be produced with only one instruction: ; Multiply RAX by RBX. The 128-bit product is stored in RDX:RAX. 00000000 48 F7 EB imul rb" That you can't get at it (the full result) without some (inline) assembler is another issue. RAX is what's returned (as far as I remember) from a function, your truncating multiplication, the higher bits are waiting for you in RDX. I don't have a SPARC to my disposal, so cannot comment. degski

I also think that in order to improve the impact of Boost, certain libraries should be retired (at least those which are now standardised). (Bigger/More is not better, Niall) Some other stuff should really go, because those libraries are really no longer of this time. I'm thinking like BGL (the manual is a book!!!), multi-array (talk about clumsy) and several others, so somebody has an opportunity and is given a challenge to create something better. Also un-maintained libs are candidates for scrapping.

You may not remember that I have one of the most aggressive opinions on deprecation of anyone here. If I had my way: * All undermaintained libraries (as defined by unclosed issues) stripped from main distro at six months, with warnings each month privately, warnings to the public from four months onwards. There are libraries in the Boost main distro with open bug count nine years old. That's unacceptable in any set of libraries claiming to have quality. Last time I looked in detail (before the corporate sponsorship effort), about half of Boost libraries had maintenance issues, but there was a hardcore 20% that is damaging the Boost brand and those need to go. * All legacy libraries removed from main distro into a "legacy" distro. I am torn on libraries like SharedPtr, those are a tough call. I'd leave it up to the maintainer to choose e.g. StringRef is clearly legacy, StringView is not. * All C++ 14 only libraries put into a Boost 2.0 distro. * All libraries in the review queue put into a "Boost unreviewed" distro. I reckon about fifty libraries would remain in the main distro. Much more manageable and focused. And by "put into a distro", I do NOT mean release management, I mean an automated script on a cronjob. No manual quality control, that is kept only for the main distro. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 15/03/2017 11:19, Vinnie Falco via Boost wrote:

On Wed, Mar 15, 2017 at 4:53 AM, Niall Douglas via Boost wrote:

...

There are libraries in the Boost main distro with open bug count nine years old. That's unacceptable in any set of libraries claiming to have quality. Last time I looked in detail (before the corporate sponsorship effort), about half of Boost libraries had maintenance issues, but there was a hardcore 20% that is damaging the Boost brand and those need to go.

I've been using Boost for years now and I didn't even know about these libraries with maintenance issues. And knowing about those issues now does not deter me from continuing to use Boost - I will simply avoid the libraries with problems and continue to use the good ones. Can you provide some evidence that this problem has "damaged" the Boost brand?

The poor folk who have locked themselves into the unmaintained Boost.Iostreams generally come to regret it. Additionally it should never have passed peer review, its design is fundamentally flawed. There are increasing problems with Boost.ASIO as it gets ever further away from ASIO. Boost.Test before develop branch finally got merged to mainline was a real problem. Lots of wasted time for a lot of folk over many years. Some feel that the lack of cmake based build and test is a brand damaging problem. I'm less convinced of that personally, but then I generally only use the header only Boost libraries which don't suffer from being misbuilt by package repo maintainers etc. Some Boost libraries have muxed in support for the C++ 11 STL, others have not. That is causing big problems for some Boost users. I'd personally throw all the C++ 11 STL unhelpful libraries into deprecation by this stage. I'm not subscribed on stackoverflow to other Boost libraries, but as a general rule, frustration and pain expressed there is a good indicator of ongoing brand damage. Again, without an active policy making political leadership, there is nobody to identify brand damage, and even if identified, no means of addressing it. If we at least could segment the bad libraries into a "bad Boost" distro, it would be a huge improvement. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Once Boost libraries are decoupled and autonomous, the "Boost branding" would take on a different meaning, as users could more freely and deliberately pick what Boost library they want as part of their development (as well as runtime) platform.

This is something that certainly confused me when I first came to boost - initially I read that boost libraries were meant to be as independent as possible in the author docs, but then the actual libraries tend to be highly interdependent. Which creates exponential complexity in terms of maintenance.

On 15/03/2017 18:30, Olaf van der Spek wrote:

On Wed, Mar 15, 2017 at 5:16 PM, Niall Douglas via Boost wrote:

...

There are increasing problems with Boost.ASIO as it gets ever further away from ASIO.

Why is Boost Asio diverging from Asio?

Boost.ASIO has always had a more conservative update track to ASIO (Boost.ASIO is auto generated by script from ASIO), but since the Networking TS was voted in, only serious bug fixes from ASIO have been backported to Boost.ASIO as ASIO has effectively become unstable due to the pace of changes. Particularly big changes lie around the strands implementation judging from the noise of complaint about it. There are a fair few more big differences in API, features supported, scalability and so on. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 3/14/17 2:53 PM, Robert Ramey via Boost wrote:

All correct. This suggestion has been floating around since at least 2010. I think it's time to implement it. I propose the following text to be placed in the appropriate place.

"Only those who have managed a boost review can expect their library submissions to be to be reviewed."

This clearly states the rule and allows for some exceptions.

OK - I've endorsed one of Naill's ideas in the form of the above suggestion. a) I think it's simple to implement. b) if it doesn't work it's simple to retract. c) We've had the normal back and forth about it - with the usual number of tangents and side tracts and I don't see a strong argument against at least trying it out. So let's try this out. The only thing is I don't have any idea who has the authority to implement this. The Review Wizard could just start implementing it on his own - though I'm not sure he'd be comfortable with that. So I'll guess that its the steering committee. I'll send them a copy. Robert Ramey

+1 to everything Micheal said. Zach On Thu, Mar 16, 2017 at 9:49 AM, Michael Caisse via Boost < boost@lists.boost.org> wrote:

On 3/15/17 13:26, Robert Ramey via Boost wrote:

...

On 3/14/17 2:53 PM, Robert Ramey via Boost wrote:

...

All correct. This suggestion has been floating around since at least 2010. I think it's time to implement it. I propose the following text to be placed in the appropriate place.

"Only those who have managed a boost review can expect their library submissions to be to be reviewed."

This clearly states the rule and allows for some exceptions.

OK - I've endorsed one of Naill's ideas in the form of the above suggestion.

a) I think it's simple to implement. b) if it doesn't work it's simple to retract. c) We've had the normal back and forth about it - with the usual number of tangents and side tracts and I don't see a strong argument against at least trying it out.

So let's try this out.

The only thing is I don't have any idea who has the authority to implement this. The Review Wizard could just start implementing it on his own - though I'm not sure he'd be comfortable with that. So I'll guess that its the steering committee. I'll send them a copy.

Robert Ramey

(without my committee hat on)

This implies that the problem is a lack of review managers. I see my other email wasn't replied to. Perhaps because it is easier to talk about review managers. So let me sum up my other response to see if we can get some discussion here:

* 7 of 22 libraries in the queue have review managers assigned. One-third isn't great but it isn't a disaster. * Those 7 libraries with managers could represent back-to-back reviews for the next 2 - 4 months. * Libraries with a manager and no review date often represent a library that isn't completely ready to go. Part of the job of the manager is to ensure that the library is ready. This could be an indicator that the system is working. * Libraries with a manager and no review date can also mean that finding a date is complicated. * (both of the above observations are from personal experience) * Not having a review manager might be an indicator of not enough interest in a library. It is the job of the author to ensure there is enough interest by the community. Perhaps the author hasn't done enough promotion. Maybe more solicitation on the ML is required or perhaps people just don't find the solution interesting. One person saying, "that sounds like a neat library!" shouldn't constitute interest.

I don't have time right now to go back through the history of items in the review queue to determine if interest from the community was determined before the library was placed on the list. Just producing a library that the author finds interesting and useful doesn't make it a candidate for Boost.

I'd like to see a purging of the queue before we get all excited about finding managers.

* If a library doesn't have a manager, remove it from the queue. * Authors take the pulse of the community to determine interest. * If there is interest, the library gets placed back in the queue and solicitation of a manager can begin.

Lets not try and fix non-problems. Maybe review managers are a problem but I'm not convinced. Why am I not convinced? Because of candid discussions with past managers who had the same feeling as me: "I'm just not interested in any of the libraries in the queue." You will note that has obviously changed for me in the past few months.

michael

-- Michael Caisse Ciere Consulting ciere.com

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

On 3/16/17 11:24 AM, Edward Diener via Boost wrote:

I can totally respect the fact that potential review managers just are not interested in any library on the review queue that does not have a review manager. But I think that the paucity of those willing to be a review manager for libraries is still the problem.

Do you have any suggestions to address this? Robert Ramey

On 3/16/2017 5:53 PM, Michael Caisse via Boost wrote:

On 3/16/17 11:24, Edward Diener via Boost wrote:

...

On 3/16/2017 10:49 AM, Michael Caisse via Boost wrote:

...

<snip other stuff>

...

...

* Not having a review manager might be an indicator of not enough interest in a library. It is the job of the author to ensure there is enough interest by the community. Perhaps the author hasn't done enough promotion. Maybe more solicitation on the ML is required or perhaps people just don't find the solution interesting. One person saying, "that sounds like a neat library!" shouldn't constitute interest.

I dislike the idea that if someone creates a worthy library as a possible addition to Boost, and gets enough initial discussion so that an addition to Boost's review queue of that library is made, that person must continually promote that library so that there is enough interest in Boost so that someone, anyone, is willing to be the review manager for that library. Why should this always be necessary in the face of the fact that very few of the people who contribute to Boost, via discussions on this mailing list and work on various libraries or work on other areas of the Boost infrastructure, are willing to be review managers ? Certainly this situation is not the library submitter's fault. BTW this situation, vis a vis being a review manager, is not in any way a criticism of all those people who contribute to Boost and neither have the time or inclination or interest to server as a review manager for a library in the review queue.

It is up to the library submitter to garner interest in their library. Do you think that all of the libraries in the queue have shown that there is ample community interest?

I do not know the history of the libraries in the review queue. But I would imagine that each one garnered some interest before a request was made to add the library to the review queue. But interest and having someone willing to be a review manager are different things.

This implies that the problem is a lack of review managers. I see my other email wasn't replied to. Perhaps because it is easier to talk about review managers. So let me sum up my other response to see if we can get some discussion here:

I did intend to reply to your earlier email to say you made a lot of good points I hadn't considered. Unfortunately sick children intervened, I was stuck in Hospital A&E until 4am last night due to a fever we couldn't break (all ended up well, fever broke this morning). In your earlier email you made the extremely valuable point that one third of the queue is in the process of being cleared, which I hadn't considered. Let's assume my estimate that 25% of the queue would never pass a review due to a glaring deficiency. That means that the "real queue problem" is just 9 libraries. I also am pretty sure at least two of those libraries the author has given up on getting a review and so are stale, so it could be that the true backlog is just 7 libraries, or about 30% . That's manageable. It's a really a problem of *optics*. It *looks bad* to the wider public if we have a really big review queue well exceeding *15%* of all libraries already in Boost. As Edward says, it puts people off submitting, creates morale problems etc. Part of the solution I think needs the queue to be constructed and presented differently, and that is what the rest of this email is about.

* Not having a review manager might be an indicator of not enough interest in a library. It is the job of the author to ensure there is enough interest by the community. Perhaps the author hasn't done enough promotion. Maybe more solicitation on the ML is required or perhaps people just don't find the solution interesting. One person saying, "that sounds like a neat library!" shouldn't constitute interest.

That last sentence stood out for me i.e. "One person saying, "that sounds like a neat library!" shouldn't constitute interest." I began thinking that that could help a lot with preventing unready and uninteresting libraries entering the review queue in the first place. Here is my proposal: 1. All libraries in the review queue without managers attached are removed (including my own!) and the authors emailed to say the following new policy applies. The review queue is therefore emptied. 2. For a library to enter the review queue in future, it requires at least one (and preferably more) named members of the Boost community to publicly endorse the library to enter the review queue. Their names will be listed alongside the library in the review queue page at http://www.boost.org/community/review_schedule.html. 3. Endorsing a library has NO RELATION to review managing a library. Indeed if only one person endorses a library for review, they are not permitted to act as review manager. 4. To find someone to endorse a new library for review, the library author ought to ideally canvas for a library's motivation before they ever begin writing or designing it, but failing that they need to approach boost-dev and publicise their library seeking someone to publicly endorse it for review. Other forums work too e.g. reddit/r/cpp, the Incubator or anywhere else. Ideally I'd prefer if the Incubator *was* the place where people endorsed a library for review and their name automatically was added to the review queue page, but I appreciate that's a lot of scripting. I am personally highly unsure of Robert's suggestion (he claims it was mine, it was not) that every author of a library entering the queue needs to review manage a library first. Speaking for myself as someone who has managed a review three times now with a fourth time starting tomorrow, I would be highly unsuitable to make a recommendation on a domain far away from anything I've ever used, I'd be likely to recommend the wrong thing through ignorance. The above proposed policy effectively pushes the bottleneck higher up the chain, but I think that's no bad thing. Library authors, myself included, like to build cathedrals irrespective of whether anyone will ever use them nor appreciate them. Currently it's too easy to build a library nobody will ever use and get it into the review queue where it will languish for many years because no review manager will touch it. That part needs to change. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Am 16.03.2017 um 22:38 schrieb Robert Ramey via Boost:

On 3/16/17 1:47 PM, Niall Douglas via Boost wrote:

...

Here is my proposal:

2. For a library to enter the review queue in future, it requires at least one (and preferably more) named members of the Boost community to publicly endorse the library to enter the review queue. Their names will be listed alongside the library in the review queue page at http://www.boost.org/community/review_schedule.html.

3. Endorsing a library has NO RELATION to review managing a library. Indeed if only one person endorses a library for review, they are not permitted to act as review manager.

4. To find someone to endorse a new library for review, the library author ought to ideally canvas for a library's motivation before they ever begin writing or designing it, but failing that they need to approach boost-dev and publicise their library seeking someone to publicly endorse it for review. Other forums work too e.g. reddit/r/cpp, the Incubator or anywhere else. Ideally I'd prefer if the Incubator *was* the place where people endorsed a library for review and their name automatically was added to the review queue page, but I appreciate that's a lot of scripting.

I think the scripting is already in there. I think you could just say - in order to be officially reviewed it has to have two reviews in the incubator.

...

I am personally highly unsure of Robert's suggestion (he claims it was mine, it was not) that every author of a library entering the queue needs to review manage a library first.

Sorry. I thought that was your proposal. It's a worthy proposal in any case.

...

The above proposed policy effectively pushes the bottleneck higher up the chain, but I think that's no bad thing. Library authors, myself included, like to build cathedrals irrespective of whether anyone will ever use them nor appreciate them. Currently it's too easy to build a library nobody will ever use and get it into the review queue where it will languish for many years because no review manager will touch it. That part needs to change.

All this was/is behind the design of the inclubator. The idea was that reviewers who downloaded a library from incubator would try it out - likely because they needed it - and write a review. Sort of like Amazon. This would a) decouple reviews from 10 day review period. b) give authors earlier feedback - which they desperately need. c) automatically filter out bad and/or inconsequential ideas. d) increase the number of reviews available e) thereby making the review manager's job much easier. f) provide a cool netflix style rating for different aspects of the library if a library has garnered 5 or more reviews

In addition it would provide a permanent chain of comments documenting the history and resolved/unresolved with the library.

There are some 40? libraries posted and I'm happy about that. But I'm disappointed it hasn't had any noticeable impact on the review situation. That might be helped by improving it, but I'd probably not be motivated without a little bit more success. And improvements WOULD require significant scripting - which is agony for me. I'd like to see:

a) The comment mechanism transformed into a window into the developer's list. b) A method to clone a library directly from incubator. This would give me statistics on the number of people who have downloaded the libary. I could also likely capture the email address so I could automatically bug them to review the library. I think both of these would be helpful

So that's where we are on that.

Robert Ramey

I think, the idea behind the Boost Library Incubator is great. However, it probably should be advertised better. But I do not mean that Robert should tell the people more about it via the boost-mailing list. (He is already doing a good job doing that.) Instead, I would prefer a tighter coupling between the Boost website and the Boost Library Incubator website. Just looking at it from a more outside point of view I would say: The Boost website does not look sexy. It looks quite old-fashioned, has a lot of text, but how that is structured is not easy to grasp by a short glimpse. And except for finding the current download and the list of current libraries it is quite hard to find particular information fast (if at all). (The GSOC) For example, I just tried to find a reference to the Boost Library Incubator from the Boost website. I did not succeed. I thought, there must be a link somewhere (and there probably is) but I did not manage to find it. (Even when using the search-functionality I only got references to e-mails on boost mailing-lists that mentioned it.) If it would be advertised more prominently on the website it might get more attention. Or another example is Trac. It is really ugly and leaves the impression that not many issues are worked on. (We had this topic already in this mail-discussion.) (A short anecdote: When I first tried to use (= report issues to) Boost-Trac some years ago the website's response was so slow that it felt like being down. Luckily, these problems seem to be solved for some time now.) There is a reason, Github is so successful and people are using it (and in general prefer using it) despite the fact that Git is popular: It is easy to use _and_ it looks sexy. Probably, it would be a good idea to use some of the money Boost has to pay a professional web-designer to create a new, easier to use and appealing (aka "sexy") website. And then it should probably directly integrate the Boost Library Incubator. And if it were possible to rate the libraries (from the Incubator) with a simple (star-)system and allow reviews/comments directly via the website (both similar to Amazon) it would probably gather more interest. Just my 2 cents. Deniz Bahadir

I was going to say: The GSoC-students seem to have similar problems finding all the information they need. (There is a "Google Summer of Code" link under the "Community" menu on the Boost-website but from there I did not find the current GSoC project-page of Boost. A Google-search found it instead.)

Actually no, what you're seeing there is students who don't feel like reading the instructions and ask here if they really need to do work as the instructions say because they don't want to do the competency test, or read an instructions page longer than a few paragraphs. You may not be aware, but as part of our GSoC application will fill in an extensive list of links and documentation, and Google hand checks those for suitability before we are approved as an org. Any GSoC student cannot fail to be told what they need to do. Furthermore, I've cultivated extensively the SEO ranking of the GSoC information for Boost over the years, and each year I verify it ranks at the top of the search results for "google summer of code C++" and variations thereof. GSoC at Boost is one of the most competitive GSoCs around with an oversubscription ratio of at least 7:1 which suggests students are finding us easily. We set an extremely high bar, indeed so high it worries us that we are being exclusionary and Google since the recent admin changes is not massively happy with it either. However since I introduced the changes which raised that bar we've had much more successful summers, in the past about half the student projects were disappointing because the student just wasn't up to the coding ability needed. In the last few GSoCs we've had more problems with student work ethic than coding ability, which is a nice problem to have. Nevertheless it's a fine line to tread, and whoever takes over from me after my time as admin finishes will take a different balance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Fri, Mar 17, 2017 at 2:12 PM, Niall Douglas via Boost wrote:

...

Just looking at it from a more outside point of view I would say: The Boost website does not look sexy.

It looks quite old-fashioned, has a lot of text, but how that is structured is not easy to grasp by a short glimpse. And except for finding the current download and the list of current libraries it is quite hard to find particular information fast (if at all). (The GSOC)

You'll find plenty of this already reported in depth by me in posts past. I believe there was even a C++ Now talk or two by me on this topic. Most of current Boost infrastructure stopped being developed further from about 2009 onwards mainly due to a mix of lack of volunteers to do the work, and because any attempt to make any significant changes to infrastructure runs into major admin hurdles.

It'd be nice if stuff like this could be tracked in the (an?) issue tracker such that all discussion can be read in a single location.

On 17.03.2017 09:12, Niall Douglas via Boost wrote:

...

Just looking at it from a more outside point of view I would say: The Boost website does not look sexy.

It looks quite old-fashioned, has a lot of text, but how that is structured is not easy to grasp by a short glimpse. And except for finding the current download and the list of current libraries it is quite hard to find particular information fast (if at all). (The GSOC) You'll find plenty of this already reported in depth by me in posts past.

[...]

...

Or another example is Trac.

[...]

Trac would provide us continuity for when that happens.

[...] I'm really mystified by how almost any discussion on this list eventually turn magically into discussions about tools. It's the boost's community's main fetish. What most people here seem to agree on is how hard it is for Boost to change anything. So why don't we talk about the reasons for that, and how to improve, rather than waste our energy on tool discussions ? Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 17.03.2017 09:48, Niall Douglas via Boost wrote:

...

I'm really mystified by how almost any discussion on this list eventually turn magically into discussions about tools. It's the boost's community's main fetish. Well, everyone has an opinion on tooling e.g. love/hate on cmake.

Yeah, we all love bike-shed discussions. Let's have more of those. [...]

...

What most people here seem to agree on is how hard it is for Boost to change anything. So why don't we talk about the reasons for that, and how to improve, rather than waste our energy on tool discussions ? Every proposal I've ever made to fix this has been rejected. I've given up.

Right: solving the real problem is hard, so let's look for other (even unrelated !) problems instead. Someone cited the "looking for the keys under the street-light" parable already in this thread, which fits nicely, doesn't it. Stefan PS: happy St.Patrick's day ! ;-) -- ...ich hab' noch einen Koffer in Berlin...

On 3/17/17 3:10 AM, Deniz Bahadir via Boost wrote:

Probably, it would be a good idea to use some of the money Boost has to pay a professional web-designer to create a new, easier to use and appealing (aka "sexy") website. And then it should probably directly integrate the Boost Library Incubator.

And if it were possible to rate the libraries (from the Incubator) with a simple (star-)system and allow reviews/comments directly via the website (both similar to Amazon) it would probably gather more interest.

That's possible right now on the incubator. It doesn't include all the boost libraries - but it easily could. I would love to see a whole restructuring of the Boost website and all the stuff it's connected to. I agree it sorely needed. Actually the incubator is my vision for Boost 2.0 - an easily navigable facade/lense through which to view all of boost in a coherent way. But as has been noted, website scripting is may more hacky and problematic than C++, and that's saying something.

Just my 2 cents. Deniz Bahadir

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

...

The above proposed policy effectively pushes the bottleneck higher up the chain, but I think that's no bad thing. Library authors, myself included, like to build cathedrals irrespective of whether anyone will ever use them nor appreciate them. Currently it's too easy to build a library nobody will ever use and get it into the review queue where it will languish for many years because no review manager will touch it. That part needs to change.

I like the idea. Of course, regarding the endorsements, you now have to define who qualifies as "Boost member". Is it anyone who signed up for boost-dev mailing list?

I guess it probably is. We've not had problems with people gaming the review process to get a library in no matter what by flooding the review process with fake positive reviews. So I guess anyone on boost-dev is fine.

Another, similar suggestion. When we were planing for review with Robert, we were already aware of two people having informally committed to submitting a review. I liked the idea a lot. Maybe it can be formalized. One of the criteria for review-readiness could be to have at least N (where N = 2 or similar) people who declare that they would submit a review. This declaration is not binding.

Great idea, and I think that that would be the case in practice anyway.

This prevents the situations where a review ends in the rejection due to lack of reviewers. I am not sure if it is the same as endorsement.

Ok, I've asked boost-steering for feedback on this policy change. If they approve, I'll do up a beta of the Boost website for people to check, and if all okay it'll go live. The boost-steering policy change discussion request can be found at https://groups.google.com/d/msg/boost-steering/rJPWdYodmtQ/JjaS-Kj4BgAJ for those interested. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Niall Douglas wrote:

...

https://groups.google.com/d/msg/boost-steering/rJPWdYodmtQ/JjaS-Kj4BgAJ ... The proposed reformed policy page for submitting a library for review to Boost can be found at https://boost-website.nedprod.com/development/submissions.html.

The first link asks for at least one endorser, the second asks for two. Which one is correct?

On 19/03/2017 18:04, Glen Fernandes via Boost wrote:

On Sun, Mar 19, 2017 at 1:30 PM, Niall Douglas wrote:

...

The proposed reformed policy page for submitting a library for review to Boost can be found at https://boost-website.nedprod.com/development/submissions.html.

Why would the Boost review process page mandate "Reddit/r/cpp" as one of the places to solicit feedback about the new library submission?

It only refers to the "Determine Interest" section. I've found Reddit very, very useful in helping refine the popularity of a new library before I begin. pcpp for example took in a lot of feedback from there before I began. I also have them amazing in knocking documentation into new orbits of usefulness. The Outcome tutorial is mostly thanks to Reddit. Note Reddit is only suitable for those two steps alone. The reset of the submission process is boost-dev and Incubator only. I've tried to clarify the wording, try https://boost-website.nedprod.com/development/submissions.html again. And Peter, note the seconders needed is one person now. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

I’ve been following the conversation on the Review Schedule, and it seems to be converging on a nice solution. I had been thinking that it would be a good idea to purge the schedule and start anew. Note that there are some libraries have listed managers but have not been scheduled for review long after a manager volunteered, so it’s worth also double-checking libraries that have managers (minus those where a manager has volunteered this calendar year).

I have noticed the same thing: libraries with review managers attached that never seem to get reviewed. Ronald what would you think of an "expiry date" for libraries in the review queue? So, if no review happens six months after entry, they get purged?

I am not fond of listing Reddit in the same class of “determine interest” as boost-dev and the incubator. That may be a useful place to get feedback, but is outside the boost community, and there are likely other venues to consider aside from reddit if we’re going to cast a wider net.

I'm surprised at the antipathy to Reddit/r/cpp. A few years ago it wasn't worth visiting regularly, but now given the number of the C++ leadership regularly there I find myself there much more frequently than isocpp.org which I no longer visit much. But then I'm a populist, and that's unlike most people here. I've relegated the Reddit mention to a suggestion, see if you like the new wording. If you could suggest those "likely other venues to consider", that might be useful.

The text on the current page candidate is stricter in tone than the original wording in the suggestion to the steering committee:

"So before investing hundreds of hours of your time, use the Boost developers mailing list https://boost-website.nedprod.com/community/groups.html, the Boost Library Incubator http://blincubator.com/ and Reddit/r/cpp https://www.reddit.com/r/cpp/ as forums to gauge …”

versus

"To find someone to endorse a new library for review, the library author ought to ideally canvas for a library's motivation before they ever begin writing or designing it, but failing that they need to approach boost-dev and publicise their library seeking people to publicly endorse it for review. Other forums work too e.g. reddit/r/cpp, the Incubator or anywhere else.”

You probably didn't notice, but I substantially refactored the entire page. The previous page had lost flow and cohesion through many small updates applied haphazardly, and interchanged multiple terms to mean the same thing which might be confusing to the uninitiated. The progression from the beginning of a library to its admission was not clear. I refactored the prose to use consistent terms, with clear numbered steps and a clear progression of submissions workflow from start to finish. I have attempted to merge elements of the second passage into the first. See what you think.

I like the general tone of the latter better. It should also be made clear that a library should be ready for review when it goes on the schedule, even if more updates are planned. If a library needs a couple of more months to be ready for review than it should not go on the schedule for a couple of more months.

I've tried to match the tone, and have strengthened what review readiness means.

It is hard for me to compare the proposed page update to the current without seeing a diff, so I will look forward to seeing the pull request.

All-in-all these are good ideas. Resetting the schedule is a good one-time thing to do, and requiring an endorsement before being added to the review schedule is consistent with Boost practices.

Many thanks for the feedback. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Sun, Mar 19, 2017 at 8:01 PM, Ronald Garcia via Boost < boost@lists.boost.org> wrote:

... All-in-all these are good ideas. Resetting the schedule is a good one-time thing to do, and requiring an endorsement before being added to the review schedule is consistent with Boost practices.

+1 --Beman

On 3/20/17 8:38 AM, Peter Dimov via Boost wrote:

This is off-topic, but I'd really appreciate if the page linked in

"Some best practices ideas with samples of script and code and links into source code in existing Boost libraries can be found on the Boost wiki."

be reworked, made up to date, with the controversial/niche recommendations removed. +1 It'd be nice if it reflected practices that are unequivocally endorsed by Boost. I don't know that that is possible.

Back on topic, I think that the current process of getting a library into the review queue is a bit outdated. I suggest we make use of existing infrastructure and make a Github repository "review" owned by the Review Wizard in which submissions occur by way of the endorsing Boost member creating an issue with the description of the library.

Discussion about the library, as it pertains to the review process, can then happen inside this issue; review managers, when found, and scheduled review dates can also be posted there, so as the progress of a library towards a review can be conveniently tracked by people with an interest in the matter.

The README.md file of this repo can be the current review queue. This would effectively be the Boost Incubator version 2 - and there is nothing wrong with that. I could declare victory and retire the inclubator. Accepting a library would simply be a question of changing it's name or moving from the "Boost Submissions" super project to the "Boost" super project.

The only reservation that I have about this idea is that closely couples Boost to Github. I can see the appeal and merit of this idea though. Maybe we should go the full monty, give up on SourceForgeand ask users to just clone the boost superproject to their own machine and use their own copy of git. Then our "release procedure" would be track the testing of the master branch and assign a tag with a version number when it's "perfect" Robert Ramey

On 20.03.2017 13:05, Robert Ramey via Boost wrote:

The only reservation that I have about this idea is that closely couples Boost to Github.

I can see the appeal and merit of this idea though. Maybe we should go the full monty, give up on SourceForgeand ask users to just clone the boost superproject to their own machine and use their own copy of git.

Why would anyone wanting to contribute a new library to Boost have to clone the Boost super-project ? While the Boost modularization effort unfortunately hasn't come very far, there is no reason for new submissions not to be modular right from the start. New libraries should be buildable with a pre-existing Boost installation, which makes life much simpler for everyone involved. And whether at a later point in time (after acceptance) the build process would have to change so the new library is built as part of the rest of Boost or stand-alone can still be decided later. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 20/03/2017 15:38, Peter Dimov via Boost wrote:

Niall Douglas wrote:

...

try https://boost-website.nedprod.com/development/submissions.html again.

This looks good to me. The new procedure makes sense. I only have one small nit to pick:

"Be prepared to pivot your design"

Can we please not pivot? Pivoting is awful. :-)

I am afraid I do not understand as pivoting is exactly the right term for what was meant. Can you suggest something else?

This is off-topic, but I'd really appreciate if the page linked in

"Some best practices ideas with samples of script and code and links into source code in existing Boost libraries can be found on the Boost wiki."

be reworked, made up to date, with the controversial/niche recommendations removed. It'd be nice if it reflected practices that are unequivocally endorsed by Boost.

Lots of people have said how useful they have found that guide as a source of ideas and considerations. I don't think anybody actually implemented any of those practices using the suggested code or formulation. In that sense the handbook has been highly successful, in that it has failed in a inspirationally positive way. Updating it, without investing very considerable additional effort, might therefore be counterproductive because by removing the controversial stuff, you remove the food for thought (and remember nobody is implementing the controversial stuff anyway, but they are finding it inspirational when deciding to reject it).

Back on topic, I think that the current process of getting a library into the review queue is a bit outdated. I suggest we make use of existing infrastructure and make a Github repository "review" owned by the Review Wizard in which submissions occur by way of the endorsing Boost member creating an issue with the description of the library.

The problem with this is that we don't want one member endorsing a library for review. We want *lots*. Almost without doubt when potential review managers scan the list of review pending libraries, they will prioritise those libraries with the most public endorsements. I think that is one of the most valuable gains in this change, and I would not want to lose it.

Discussion about the library, as it pertains to the review process, can then happen inside this issue; review managers, when found, and scheduled review dates can also be posted there, so as the progress of a library towards a review can be conveniently tracked by people with an interest in the matter.

Github allows people to star projects, but not star issues. Can you reformulate your idea to be something starrable on github? Or perhaps not on github? Remember https://boostafio.uservoice.com/forums/218980-boost-afio-feature-request? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

...

Back on topic, I think that the current process of getting a library into the review queue is a bit outdated. I suggest we make use of > existing infrastructure and make a Github repository "review" owned by the Review Wizard in which submissions occur by way of the endorsing Boost member creating an issue with the description of the library.

The problem with this is that we don't want one member endorsing a library for review. We want *lots*.

Almost without doubt when potential review managers scan the list of review pending libraries, they will prioritise those libraries with the most public endorsements.

How would they know which libraries have the most endorsements?

I had been thinking that an extra column in the table at http://www.boost.org/community/review_schedule.html would be entitled "Seconded by" and in the cell would be the names of all those who endorsed that library for review. In other words, if you Peter ask for endorsements for review here for your new library SharedPtr2 or something, and say Edward, myself, Robert, Beman and Michael all publicly say "this library looks very likely to pass a review", all our names appear in that column. Does this make sense now? I would not recommend a "click to star" type system for endorsing a library for review. Endorsing a library for review publicly with your name is a solemn statement that you have given a cursory check of the library and that you publicly declare you think it has some chance of passing a review. I have no opposition to a *separate* "click to star" upvoting system so people can easily upvote some review as being more urgent than others. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

The new procedure would be, the library author posts to the list, the first Boost member who endorses the library creates an issue for the library, additional endorsements are posted as comments on that issue. The Review Wizard, being the owner of the repo, receives notifications for each and can respond in the issue, if needed.

That is, all the communication that is relevant for a particular submission reaches the Review Wizard without him having to read the Boost list, or relying on people notifying him via private e-mail.

One exception to all the communication taking place in the issue could be when a review manager is suggested, because in case of rejection, people may not appreciate this taking place in public. I don't know how often review managers are rejected though, so I don't know if this is a practical problem.

Re Github stars, if the library is already on Guthub, which it pretty much has to be, the repo stars can be used as a metric of popularity. (The other way to gauge popularity is by the number of comments the library submission issue has attracted.)

I think this is all far too much for people to hold in their heads. If you were to script all this up into some webforms which called the github api for people, I could see it working. But for people to remember to open tickets and +1 them and all that ... I don't think it will fly. Too much to remember. (and Robert basically says the same thing in another reply) Don't get me wrong for a second Peter, I would *just love* to automate the hell out of all this stuff, bring state of the art automation to bear on "the Boost scalability problem". But that stuff doesn't come cheap, neither to implement, debug nor to maintain. Plus, nobody here seems keen on automation, we seem to like static HTML and email, and anything exceeding that is a very tough sell, especially anything regarding changes to process. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

The new procedure would be, the library author posts to the list, the first Boost member who endorses the library creates an issue for the library, additional endorsements are posted as comments on that issue. The Review Wizard, being the owner of the repo, receives notifications for each and can respond in the issue, if needed.

That is, all the communication that is relevant for a particular submission reaches the Review Wizard without him having to read the Boost list, or relying on people notifying him via private e-mail.

It occurs to me that this would also work for the actual reviews of the library. Those could be posted as comments on the issue as well. (Or in a "Review: libname" issue distinct from the "Submission: libname" one, to avoid clutter.) This would be much easier on the review manager who currently needs to scan the high-volume Boost list in order to collect the reviews. With the issue system, all reviews would already have been collected in one convenient place.

Niall Douglas wrote:

Github allows people to star projects, but not star issues.

https://github.com/isaacs/github/issues/9 Sounds like they aren't interested in fixing that. You can +1 the top comment as a workaround.

David Sankel wrote:

Thanks Niall for putting this together! A few comments:

- "Otherwise, you will just end up wasting everyone's time." This sentence is a bit abrasive. I suggest striking it. - "If what you really want is a site that will just post your library without even looking at it, you should go elsewhere." likewise - "and the emotional demands of a formal review" likewise. If you want to give the reader a heads up about the ego-crushing force of critiques by brilliant people, I would probably word it differently. - "Too often" . . . this sounds a bit rantish.

It should be noted that these are not Niall's words. They come from the original version of the page. (It is for this reason that it would have been better to review a diff.)

On Tue, Mar 21, 2017 at 7:06 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

Thanks Niall for putting this together! A few comments:

* "Otherwise, you will just end up wasting everyone's time." This sentence is a bit abrasive. I suggest striking it. * "If what you really want is a site that will just post your library without even looking at it, you should go elsewhere." likewise * "and the emotional demands of a formal review" likewise. If you want to give the reader a heads up about the ego-crushing force of critiques by brilliant people, I would probably word it differently.

These three are from the original page before this round of editing. It's possible I wrote them once, I'd have to check the history as I've changed that page quite a few times. But I also may not have done.

You make a valid point though. One of my aims was to make the page more inclusive and welcoming and encouraging. The above could be better worded.

...

* "Too often" . . . this sounds a bit rantish.

Good catch.

...

Actually, I think I'll stop here for now. I like the idea of this and I think you've got a lot of good ideas in here. The wording needs a little TLC IMHO. Would you be willing to let me take a stab at massaging it a bit?

If you're volunteering, then rock on, I would find that very helpful.

I've pushed the current draft to my fork of boostorg/website and you can find it at https://github.com/ned14/website/commit/50a9b67aa14dba610a81 c1b7542a3bbf8abb97a8. This also provides a diff for those interested in that. I've invited you @camio to collaborate on that repo, it should give you commit and push access.

Once you've made your changes I can pull them onto boost-website.nedprod.com so we can all see them here for review.

Thanks. It looks like you already made some tone adjustments. Much better. I did some more wordsmithing in https://github.com/ned14/website/commit/ 72e3e7ce4351282a2da6d031633e7b0268cb36bc

On Tue, Mar 14, 2017 at 6:12 PM, Raffi Enficiaud wrote:

I suggest another way of rewarding people:

- If the review manager is a library maintainer: by the end of the review, he/she gets the help of the boost community (including the ppl whose code is being reviewed) to get his/her backlog cleared. This includes development, patches, backlog cleanup, as well as management/coordination of those devs.

- if the review manager is the author of a library under review or freshly reviewed for acceptance to boost, but still not part of any release: he/she will get the help of the boost community to make that happen as soon as possible (including open pending issues from previous reviews, documentation, integration, migration to boost.build, etc etc)

Of course, we can iterate further - for each good and sound review, you get one ticket of your backlog closed by next release

These actually sound like excellent ideas to me. Glen

Le 14/03/2017 à 23:41, Steven Watanabe via Boost a écrit :

AMDG

On 03/14/2017 04:26 PM, Glen Fernandes via Boost wrote:

...

On Tue, Mar 14, 2017 at 6:12 PM, Raffi Enficiaud wrote:

...

I suggest another way of rewarding people:

- If the review manager is a library maintainer: by the end of the review, he/she gets the help of the boost community (including the ppl whose code is being reviewed) to get his/her backlog cleared. This includes development, patches, backlog cleanup, as well as management/coordination of those devs.

- if the review manager is the author of a library under review or freshly reviewed for acceptance to boost, but still not part of any release: he/she will get the help of the boost community to make that happen as soon as possible (including open pending issues from previous reviews, documentation, integration, migration to boost.build, etc etc)

Of course, we can iterate further - for each good and sound review, you get one ticket of your backlog closed by next release

These actually sound like excellent ideas to me.

Yes, it sounds great to me too, but... who is volunteering to do this work? "The boost community will do it" is much to nebulous for a practical proposal.

Of course! I was suggesting another reward model, which apparently triggers attention and might benefit to all by offloading work. I do not have very specific solutions for that, but I believe we can converge quickly to something that can be close to consensual. ======================== Just throwing ideas there: A- case "one review -> one ticket closed": 1- best case: some one volunteers, contacts the reviewer and ask how he/she can help, and the reviewer discusses with him/her what can be done next (I've done and also seen that) 2- worst case: no volunteer: falls back to the library author ... or the "boost community maintenance team". Community maintenance team may for instance hire (with the boost real money) freelancers to do the job, but will monitor the quality together with the reviewer. B- case "review manager -> backlog cleared" 1- best case: several ppl volunteer, ask the review manager what are the priorities, and do the work. Integrate that backlog story into the agenda of the release managers for the coming release. Rationale: without putting that on release manager desk, the work may shift too much. If this becomes a general concern for those who have stake on the next release, then it will raise awareness. 2- intermediate case: ask the last 3 library authors whose library has already been integrated to boost for at least 2 releases (rationale: people still around and having their library in a more steady state than right after the first integration to boost). Can be a mix of B.1 and B.2, to the demand of the release managers maybe? 3- worst case: falls back to the library author :-) or the Community maintenance team again (same potential solutions as A.1 above) ... and so on ======================== all in all, I think we can just make democracy speak about what are the preferences and vote for a sound scheme. It is always pleasing when ppl volunteer, but I also understand how limited we are all in our time and energy. So using some money might also be a solution (although can also be controversial or problematic: we would not want to hire ppl participating in boost already for instance). ======================== Some design benefits of this model: - no money involved in the review process: review cleared from any bias or motivation other than making boost better - money might be used only for improving the state of boost (closing tickets via freelancers for instance) - ppl start looking at how to improve other libraries, and get to understand the code, reach and collaborate new ppl ... basically improves the communication over the code, and leverage potential for better collaboration (disclaimer: I am not saying that the collaboration is bad), removes the frontier of the submodules, etc... Best, Raffi

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener via Boost Sent: 14 March 2017 22:36 To: boost@lists.boost.org Cc: Edward Diener Subject: Re: [boost] [review queue] What to do about the library review queue?

...

Dear Boost,

I see that new candidate Boost libraries entering the review queue have exploded in recent years, with no less than *twenty-three* proposed libraries awaiting a review. I am certainly not against paying programmers for valuable work, even if

On 3/14/2017 8:01 AM, Niall Douglas via Boost wrote: that "work" is managing a Boost review. I am afraid, however, that paying a review manager might mean that someone will take on the task who is not qualified for it simply because money is being offered.

+1 I'd offer to manage a review, but I rarely feel qualified (and usually then there are others much better qualified). Money isn't going to help with that :-( Although I'm not against paying on 'moral' grounds if that would really help. We could offer money, but be very careful about who we give it to. I still favor some halfway house, a bit like BLincubator (though I didn't like the way it works much), so stuff can be better tried 'in anger' by far more people or more platforms - and most important refined (especially documentation). FWIW Paul PS I still do not favour gratuitously removing support for older compilers, but strongly support new libraries (or 'Son of ...' v2, v3 updates) that *only* support the newer/newest compilers.

On 15/03/2017 08:22, Andrzej Krzemienski via Boost wrote:

...

I see that new candidate Boost libraries entering the review queue have exploded in recent years, with no less than *twenty-three* proposed libraries awaiting a review.

As the ongoing strength and vitality of Boost is inextricably linked to new growth, I think that waiting around for years for someone to volunteer to manage a review is not healthy. If a library author has invested the very significant effort to develop a Boost-quality library, the least Boost can do is to try harder to provide timely reviews and that means persuading more people to volunteer to manage reviews.

Niall, it is good you are bringing this up. Only sending this message has resulted in one library finding a review manager and the time slot.

In truth I was surprised myself when I went to the review queue to see if Outcome had been added and it was suddenly a lot longer than it used to be. I should stress that *this is a good thing*. Tons of people want into Boost and have invested very significant effort to get libraries ready for review. It was so very different only recently.

But let me share a number of observations. Even if all the ideas for motivating review managers work, and you have more people willing to manage the review than the candidate libraries, there will still be one bottleneck: only one library can be reviewed at a time. I personally find it a good thing and would like to keep it this way.

Now, maybe this is just a coincidence, but we are just after the review of safe_numerics, in two days the review of Stacktrace starts; the week after it finishes, we have CallableTraits scheduled. There is also a good library waiting for review: PolyCollection. It already has a review manager. It looks like, at least for now, the schedule is full.

A very valid point, but I had already a solution in my proposal. As I had mentioned, I reckon about a quarter of the queue could obviously never pass a review due to at least one glaring deficiency e.g. totally inappropriate naming conventions. If we could improve on the filtering before libraries enter the review queue, we could cut down its size considerably. In a lot of cases, the authors of those libraries don't realise their glaring mistake, and waiting around years - or forever - to realise their mistake isn't welcoming.

Your library, Outcome, I suppose it will shortly find a review manager, as it looks useful and needed.

I hope so. But equally the majority feedback on Reddit when Outcome was announced as finished was "I don't see a point in this library nor any reason it should enter Boost". Most of said commentators hadn't passed the landing page, and just to tickle you a bit Andrzej, they found issue with that little code example on the landing page. "What's the difference over std::optional<T> they cried?"

On the other hand, I find it surprising that a library like Tick is not in the review queue. I would expect that it would be very welcome by many.

I would assume he's working on it since the Fit review, and I vaguely remember him saying that somebody else's work greatly changed his and he was going to rebase it to use theirs or something.

Maybe, we should be doing some informal pre-reviews. Take one library from the queue. Contact the author; check if he/she is still alive, and discuss with him why they want the library into boost and why we don't (or do) like it, and what we would rather expect.

Maybe this alone would make the process go more smoothly.

I've done this in the past, but only when I know the library author. That also comes with moral hazard and problems. It's basically a self selecting elite helping each other out only. The problem, as it has been in Boost for a long time now, is lack of recognised authority. Who am I to tell a library author anything? Who are you? Only the Steering Committee members have any recognised authority, and they intentionally don't use it. You may remember my attempt to create a living document of best practices, and that ended up going nowhere. There are, and remain, long standing problems with political leadership of any kind. I have proposed elections of a political leadership to set any direction for Boost with ring fenced budget and turning the Steering Committee into a pure Board of Directors with budget approval only, but the Steering Committee rejected it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

Em 15 mar 2017, às 21:05, Ion Gaztañaga via Boost escreveu:

...

On 15/03/2017 9:22, Andrzej Krzemienski via Boost wrote: 2017-03-14 13:01 GMT+01:00 Niall Douglas via Boost :

Actually, I have a question to Joaquín Mª López Muñoz and Ion Gaztañaga. What does it mean that the library in the queue has a review manager, but does not have any time slot scheduled?

Just that Joaquín and I didn't agree on a date. But it could start before May.

Basically any slot in April works fine for me. Joaquín M López Muñoz

Hi Ion, Does May 1 - 10 work for you? Best, Ron

On Mar 24, 2017, at 2:41 PM, Ion Gaztañaga wrote:

On 16/03/2017 19:49, Joaquín M López Muñoz via Boost wrote:

...

...

Em 15 mar 2017, às 21:05, Ion Gaztañaga via Boost escreveu:

...

On 15/03/2017 9:22, Andrzej Krzemienski via Boost wrote: 2017-03-14 13:01 GMT+01:00 Niall Douglas via Boost :

Actually, I have a question to Joaquín Mª López Muñoz and Ion Gaztañaga. What does it mean that the library in the queue has a review manager, but does not have any time slot scheduled?

Just that Joaquín and I didn't agree on a date. But it could start before May.

Basically any slot in April works fine for me.

It seems that April is full in the review schedule. Ronald & John, can we schedule PolyCollection just after SIMD?

Best,

Ion

Thanks for letting me know. I have scheduled the review. Best, Ron

On Mar 28, 2017, at 5:21 AM, Ion Gaztañaga wrote:

On 28/03/2017 5:28, Ronald Garcia via Boost wrote:

...

Hi Ion,

Does May 1 - 10 work for you?

Best, Ron

Due to local holidays, May 3-12 would be better for Joaquín and me.

Best,

Ion

On 3/15/17 1:22 AM, Andrzej Krzemienski via Boost wrote:

Another thought. When I look at the review queue, and also at the libraries listed in BLIncubator, my personal feeling is that some libraries do not fit into Boost. This is just my impression, but it rises a question.

There is no bar for libraries to be requested for a formal review, without a review manager. Also, authors for some libraries maybe just want to get some useful feedback, and not necessarily get their library into Boost. Maybe we need some additional stage. BLIncubator was designed to fill this gap. Maybe it can still be made to work. Maybe people who feel something need to be done in the review queue, should go through the list of libraries in BLIncubator, and give their authors feedback.

Maybe, we should be doing some informal pre-reviews. Take one library from the queue. Contact the author; check if he/she is still alive, and discuss with him why they want the library into boost and why we don't (or do) like it, and what we would rather expect.

Right. It would be very easy to make a rule that no library can go into the review queue until it has two reviews in the incubator. I think this would address ALL the problems mentioned in this thread with zero additional overhead, rules or bureaucracy. It would be easy to modify or retract as well. In fact I think the review wizard could easily say (if he wanted to). Due to the high demand and limited resources for quality boost reviews, "I'm announcing that I won't be adding any reviews to the queue that don't have at least two reviews already and someone willing to act as review manager." What would be the matter with this? Robert Ramey