...

It looks like there will be no summer of Code for Boost this year. For whatever reason, Google has decided not to accept Boost as a mentoring organization.

That's a shame. Didn't they provide a reason?

No. There's going to be an IRC meeting for rejected orgs.

Whoa, that is very strange.  Do you have any insight into or even guesses at the reasons?

Agreed. I was very surprised. Maybe we didn't have a big enough list of proposals, considering the size and scope of the community. Maybe the fact that I was listed as a mentor on 3 projects last year was seen as a problem, but I shouldn't think so. Penalizing an organization because somebody has the time and motivation to work with 3 students (2 and review, really) seems capricious. We did submit a midterm grade a week late because of a communications breakdown, and that may have played a factor in this year's decision. Who knows, Maybe Google is just trying to shake things up. The announcement said they had more orgs than ever applying. Last year they tried to give more funding to smaller organizations. There were a couple of big orgs that didn't get funded last year, which I thought was surprising. Maybe its our turn. I really won't know more until the IRC meeting, which hasn't been announced yet.

The feedback session for rejected organizations is this Friday (see https://groups.google.com/forum/?fromgroups#!topic/google-summer-of-code-dis... ).

Yes, I know.

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrew Sutton Sent: Friday, March 23, 2012 6:39 PM To: boost@lists.boost.org Subject: Re: [boost] [gsoc]

...

Whoa, that is very strange.  Do you have any insight into or even guesses at the reasons?

So... there were really 2 reason why Boost wasn't accepted as a mentoring org this year.

First, GSoC was trying to bring in more new orgs, so there was more competition. So, if you didn't have a stellar set up, you weren't as likely to be accepted.

Second, our proposed projects list was disappointing. There were really only two specific project ideas: one for Process and one for Polygon. Obviously, that's not making the cut. I think if Boost community wants to continue participating in GSoC, then we have to be more pro-active about documenting

project

ideas.

If I had to judge, based on the amount of feedback I got this year after soliciting proposals, I'd have to say that the community isn't very interested in participating.

Well I think we should be. There have been some interesting projects done by GSoC programmers. It's a resource that we should be using. I think one area where we are failing is to get them really finished - and reviewed. This is partly because it is difficult (nay impossible) to stop people biting off more than they can chew in the really very limited time available. It might be better to use GSoC to finished existing projects, especially those that have been reviewed and accepted but need final polishing, testing and documenting? (The latter might well be done by someone who didn't write the original stuff - and thus 'knows too much'). This obviously needs the active support of the original author, but if he doesn't have time, then this should be welcome. We also failed to get thinking seriously about projects soon enough. We need to start planning *now* for next year. My tuppence-worth. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul A. Bristow

I think one area where we are failing is to get them really finished - and reviewed. This is partly because it is difficult (nay impossible) to stop people biting off more than they can chew in the really very limited time available. It might be better to use GSoC to finished existing projects, especially those that have been reviewed and accepted but need final polishing, testing and documenting? (The latter might well be done by someone who didn't write the original stuff - and thus 'knows too much'). This obviously needs the active support of the original author, but if he doesn't have time, then this should be welcome.

You have valid points, but these are separate, I think, from what Google is looking for. These relate to what we want to get out of GSOC. Having mentored one successful GSOC project and one failure I have to disagree with you. From my perspective we shouldn't focus on code, we should focus on people. Rather than completed libraries we should be focused on getting active community members out of the GSOC program. From that perspective, biting off more than they can chew during the summer is actually a good thing. If a GSOC student stops at the end of the summer and we never hear from them again it hardly matters whether they finished the project or not, because they aren't going to be maintaining the code. To a certain extent, I think that our odds of turning a GSOC student into an active boost community member are higher the more ambitious the scope of the proposal. The students who are motivated to work on the project for its own sake are the ones who will remain active after the end of the summer. Regards, Luke

Paul A. Bristow wrote:

I think one area where we are failing is to get them really finished - and reviewed. This is partly because it is difficult (nay impossible) to stop people biting off more than they can chew in the really very limited time available.

Indeed this is a "problem". Chalk it up to youthful exuberance.

It might be better to use GSoC to finished existing projects, especially those that have been reviewed and accepted but need final polishing, testing and documenting? (The latter might well be done by someone who didn't write the original stuff - and thus 'knows too much'). This obviously needs the active support of the original author, but if he doesn't have time, then this should be welcome.

This would be useful, but it's not going to happen. warning: tl;dr Any software projects goes through phases: I. an idea - very fun and exciting and anyone can (and does) come up with ideas. 99% are not good ideas for one reason or another. It's fun to promote your idea though and suck other's into the discussion. II. a prototype/proof of concept. This often is done fairly rapidly - it's still fun. Usually it doesn't include more than one test/use case, no documentation. Essentially a toy. This is where most academic projects end. III. A first edition - ready for boost review. This is more than II above. Getting to this point requires a lot of work. And it's not really "fun" anymore. One can still be motivated by the accomplishment of getting something accepted by a well respected peer group. Still has a lot of loose ends, documentation isn't all there, etc. etc. IV. Working boost version. A HUGE amount of work to do to fill in all the detail missing in stage III. This includes extensive tests and documentation and making the damn thing work on all the test platforms. At this stage it's discovered that the library raises a bunch of new questions as to implementation, concept, etc, etc. The hurdle is only overcome by those who are almost pathologically stubborn probably due to some other underlying psycological issues. This is not fun at all - it's like being on a treadmill for 6 months. And it's lonely too. It's not really "fun". V. Maintainence. If the library is successful - that is people actually start to use it widely, bug/enhancement reports will filter in. For the library to be truely successful these things have to be addressed. Each one means either fixing the library (fairly easy), ehancing the library (maybe easy, maybe hard) and adding a test, or ehancing the documentation. These are all tedious tasks - but mercifully, they are not too large. Still, they are annoying and not really fun at all. Only those who are anal retentive in their quest for perfection (of course impossible to achive, but still we have to try) can really find the time to do. So it's not really realistic to try to give the latter phases to SOC or other students. It doesn't match their own goals and they don't have the time to do anything but phases I & II. Most people are too well adjusted pscologically to undertake subsequent phases on a volunteer bases. Based on this I really have reservations that GSOC is really useful to boost. Also, given Google's coding guidlines, which explicitly proscribe most of boost and most of C++11, I don't see how Google would find boost a match for them. To me, a larger and more interesting is how does boost have to change to maintain relevant 10 years from now. C++ needs the libraries, but I don't see them coming from anywhere. And boost seems to be getting "bogged down". Like many holy quests, it's seems in danger of becoming a victim of it's own successes. Robert Ramey

Nathan Ridge wrote:

[ASIDE]

...

Based on this I really have reservations that GSOC is really useful to boost. Also, given Google's coding guidlines, which explicitly proscribe most of boost and most of C++11, I don't see how Google would find boost a match for them.

That's interesting. I can understand C++11, being as it is relatively new, but do you know why Google's coding guidelines proscribe most of boost?

Look it up - they've explained their rationale on a point by point basis

Regards, Nate

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

From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey

Based on this I really have reservations that GSOC is really useful to boost.

Having gone through stages I through V that Robert describes myself, his description rings true. I'll even admit to having some pathological stubbornness. ;) I believe that GSOC is useful to boost. There are people who want to go through all five stages, and many of them start that journey while they are students. I think GSOC might help us find perhaps one or two such students per year in addition to the people who would join the community otherwise. I write the rest of the GSOC projects that fail off as the price we pay to find those few. Every engineering endeavor is in a state of failure until it succeeds. Perseverance is how the people who mentor GSOC students got to that position and it is what we are looking for in the students. I don't see us giving up on the quest, it's not in our character. Regards, Luke

I think one area where we are failing is to get them really finished - and reviewed. This is partly

because it is difficult (nay impossible) to stop people biting off more than they can chew in the really very limited time available. It might be better to use GSoC to finished existing projects, especially those that have been reviewed and accepted but need final polishing, testing and documenting? (The latter might well be done by someone who didn't write the original stuff - and thus 'knows too much'). This obviously needs the active support of the original author, but if he doesn't have time, then this should be welcome.

From an outside point of view, i do agree. I don't see a lot of Boost GSOC

projects completed. And that's really disapointing. In my fileds of interests, i would love to see some libraries integrated that deals with : - large integer / large fixed point computation - json parser/ writer - xml parser/ writer like pugiwml - crossplatform async file io for boost asio (not only for windows) - xmpp/sip stack