...

I recall that last year, Boost didn't start thinking about possible projects to suggest to potential GsoCoders until rather late.

Perhaps we should *start* thinking reasonably soon?

What about starting by the addition of an empty wiki page and let people push his proposals https://svn.boost.org/trac/boost/wiki/SoC2010

It's probably time to start thinking in this direction again, It feels like SoC 2010 just ended :) Since the topic came up, I guess I'll give a little info-dump on what I'd like for GSoC this year. After talking to a number of people at the GSoC Mentor Summit, I don't think that writing up a project list the same way that we have been doing is a good approach for Boost. There are two reasons for this. First, we've done that the last two years and the overwhelming majority of applications have been of the form, "I will do xxx". Even when we do pick students who can do xxx, they're here for the summer and then gone, and nothing happens with their work. It's really not that surprising given the amount of effort required to master the various programming styles and techniques found in Boost much less get a project accepted as part of the distribution. Single-summer projects are either too big or too small. Historically, we haven't been to good about finding "just right". Second, the process of picking student projects has less to do with students proposing good projects, but rather finding mentors that are interested in getting projects done. We gave up 3 funding lines last year because there weren't enough mentors willing to work with the kinds of projects that had been suggested off our "menu". There are a number of reasons we ran into this problem. We all tend to fixate on our own little domains and needs and so there aren't many general purpose mentors. Disagreement (on the mailing list) about the design of a particular proposal can discourage students and mentors. I'm looking at you XML library :) Also, there seems to be a reluctance to mentor for sandbox projects because they aren't "part of Boost" and there's no guarantees on when or even if they will become part of the main distribution. Basically, the formulaic project list does not encourage proposals for the kinds of work that a) has broad appeal, b) does not benefit our (broader) community, and c) may not provide the visibility that students are looking for (i.e., projects lacking "sex appeal"). I'd like to run things differently this year. Specifically, I want to: 0. Encourage much higher quality proposals 1. Accept proposals for experimental (sandbox) libraries 2. Accept multiple, competing proposals for the same library 3. Encourage longer-term relationships by considering multi-year commitments Proposals in the 1 and 2 category should be of great interest to the broader community since they give us an opportunity to evaluate experimental and competing designs for new data structures, algorithms, libraries, etc. Also, if we don't get projects in the #2 category, then we end up spending a lot of time discussing tradeoffs and details on the mailing list (see the current string discussions). Accepting proposals of this form can give us great data points for building new Boost libraries and features, which is even more important when those may wind up as ISO C++ proposals (TR2, etc.). Plus, this gives us an opportunity to get more students involved. Proposals in the 3rd category are also particularly interesting, since they provide a method of funding a student with a particularly interesting long-term project over a number of years. My goal would be to encourage seemingly good and particularly ambitious students to revise a 1-year proposal to span multiple summers. A student that successfully completes the first summers goal, would automatically receive a funding line for the following year unless a) they forfeit their funding over the Fall or Spring, b) fail to submit a proposal the following year, or c) we don't get any funding. Obviously, the number of multi-year lines would need to be capped. It would be even better if we could fund students part time over the Fall and Spring, but that's a whole other can of worms :) So... with regards to a project page: I would suggest the following: project ideas should give some very general concepts with some short explanation, and a list of mentors. For example: Project: Strings and Encodings Strings are sequences of n-byte characters, whose values may be interpreted by different Encodings (e.g., UTF-8, Base64, Quoted-Printable, etc.). Mentors: Bob Smith, Fred Jones Instructions on the page direct students to a) search the Boost mailing list archives for previous discussion on the topic and b) contact the mentors (preferably on list) to discuss the basic expectations for the project. Note: *expectations* not *requirements*. It should be up to the student to generate a proposal that identifies the requirements of the project. Thoughts? Andrew Sutton ansutton.n.stutton@gmail.com

I agree with you, it is better if the the proposals are limited to the *expectations*. Up to the student to make its own proposal. In this way we would be able to evaluate the motivation and capabilities of the student better.

Yes... reviewing dozens of "I will do xxx" proposals is a particularly frustrating process :) Andrew

Could the following example be enough?

Boost.Thread compliance with C++0x standard ================================= Adapt the current Boost.Thread interface to the C++0x standard proposal, for C++98 and C++0x compilers.

I think that this is too specific. If we post this as an example, we'll get "I am going to port Boost.Thread to C++0x" proposals. I think the trick here is to write a general C++0x project category and then list a number of libraries that could be ported to, adapted to, or even rewritten for C++0x. The latter is especially important. C++0x is quite a different language than C++, and some of the design decisions made for previous libraries may not be good choices using 0x. In fact, I'd be tempted to forgo straightforward ports and focus on entire rewrites. I doubt that it's feasible for any substantial libraries, but it does start developing some experience at designing for the newer language. I think that we should be intentionally vague when publishing these kinds of projects. Something like == C++0x Boost.Thread == Mentors: xxx, yyy gives a lot of room for interpretation :) Andrew PS I'm not against straightforward projects (i.e., port Boost.Thread to 0x), but I am against writing requirements as part of the project proposal.

5. Encourage toolkit-like additions to existing libraries, rather than writing a full-blown library. These have historically been more successful.

true. i have been doing a gsoc project last year, implementing heap data structures. in the end i had the feeling that i have implemented quite a lot of code, but that it is too early for review, but that it needs to be used by people in order to mature. otoh, there are already heap data structures in boost as part of bgl, although they have a very specific interface, which is optimized for bgl. in the end, i doubt that anyone ever used the code: i never got any question about it, nor did i use it myself ... implementation of c++0x features/compatibilty into existing libraries, tr1/2 libraries or extending existing libraries (with the library maintainer as mentor) would reduce the burden of implementing a library and doing a full review (mini-reviews may be sufficient). cheers, tim -- tim@klingt.org http://tim.klingt.org Lesser artists borrow, great artists steal. Igor Stravinsky

That's a bit disappointing - to Boost, as well as you.

Truly. I was watching Tim's project over the summer, but the project didn't evolve in the direction I was hoping. The lack of attention may also be attributable to the fact that the code isn't hosted in Boost's SVN.

* Make sure that little time is wasted getting over the Boost_way_of_doing_things (high) hurdle. A project template would help here, and especially a template for documentation using the Quickbook, Doxygen chain. Without these we will end up with something that can't be reviewed or maintained.

I thought we had a template in the sandbox. Andrew

Did you feel that you spent too much time cutting code?

And/or too little producing documentation, examples and other things that would 'sell' the project and get enough users with experience enough to get to a review?

I suspect that any projects have far, far to big ambitions, when what we probably most want out of a project is a *finished* job.

well, a boost libray is not `finished' when coding/documentation is done, but when the actual code becomes part of boost. so even if a student has the ambition of finishing coding/documentation/examples/benchmarks, the work is easily lost. but maybe it would be a good project to finish a library from earlier years, including the review at the end of the gsoc period (maybe with the mentor as review manager). tim

Add to this:

4. All students should submit a miniature, self-done aptitude test as part of their proposal. The Boost build / test / doc chain can be a big motivation-killer for students who just want to get on with coding. Getting that step done before the SoC starts would help mentors decide on the best candidates and give the students a bit of a head start.

+1 There are a number of other GSoC projects that mandate aptitude tests as part of the application project. Beyond getting the toolchain up and running, are there any kind of projects that we should have potential students focus on? Maybe require some programming involving basic STL concepts (e.g., Containers, Algorithms, and Iterators).

5. Encourage toolkit-like additions to existing libraries, rather than writing a full-blown library. These have historically been more successful.

+1 Also a good set of projects. Andrew

Project: Boost.Python improvements for NumPy bindings Boost.Python currently does have some support for NumPy arrays. However, that is very limited, and doesn't expose any real C(++) API with access to raw memory. A variety of improvements (and even specific implementations) have been discussed over recent months (search the relevant boost mailing lists !), which any successful applicant should draw inspiration from.

Mentors: Stefan Seefeld, ???

How does this sound ? (And, I believe that such a project is small and focused enough to give good chances to succeed, including proper testing and documentation.)

That sounds like a great project. I would write it a little more vaguely, however. == Boost.Python and NumPy == Boost.Python currently has limited support for NumPy arrays. The instructions on the project page will (eventually) require people to find more specific requirements on the mailing list and (hopefully) engage the community to further refine the project goals. Andrew

On 24 January 2011 12:34, vicente.botet <vicente.botet@wanadoo.fr> wrote:

What about starting by the addition of an empty wiki page and let people push his proposals https://svn.boost.org/trac/boost/wiki/SoC2010

If you didn't know, there's a long neglected and almost empty page on the main site: http://www.boost.org/community/gsoc.html Is anyone willing to take charge of it? Or perhaps creating a wiki page that it could redirect to (which should be a general page, not one specific to this year). Daniel