What kind of documentation or feedback would you like for this? From my perspective, FBOA was not a waste of time by any stretch, but also not a clearcut win. For the project I mentored with Andrew Green, the investment of mentorship time was high relative to the results; I think this was mainly because of the limited time the students could devote to the project while also taking a full schedule of other classes.

It was great for Flow, we got Thank functionality in Flow and some other bits from two talented student volunteers who were familiar with MediaWiki and our tools and didn't need hand-holding.

Flow's problems are finding a right-sized task for mentoring, and identifying more tasks in case the students ace it and want more to do; and engineers having time for gerrit review.

For OpenBadges, I think overall things went well, but the effectiveness of the project was hampered by the fact that Mozilla abandoned official Persona support halfway through the semester.

However, the students did a lot of work, some more than others, and some of them were even asking me after everything was over if they could still work on the extension. (Obviously I told them to go ahead.)

The Parsoid / Cassandra round-trip test server project turned out to be much more work than I anticipated, as there were 12 students to mentor, and no meaningful support from their respective universities. Most students basically dropped out, some struggled, and about two knew enough to get stuff done by themselves. Partly because of time zone differences I also ended up doing almost all the mentoring work, which didn't help either. I would definitely caution anybody from taking on more than 1-2 students in this program.

If I had to choose between GSoC and this, I'd definitely pick GSoC.

@coren, could you summarize your experience with this program, please?

The program was interesting and rewarding, but the idea of going with a fresh new project rather than an existing one with an active community turns out, in retrospect, to have been a mistake.

My group was well-motivated and talented (most were in postgrad), and their report of the experience was overall positive but the final result was disapointing - not, I think, because of flaws in the program but because the lack of interaction with an existing developer group detracted from the opportunity.

The limited time the students were allowed to this project (as they all had a full load of coursework), and relatively limited availability from their faculty did hamper productive results; but from an "introduce college students to collaborative development and the Open Source philosophy" it's a clear win IMO.

I guess the value of the program depends greatly on what the objective is. I should think that it's a poor investment of the mentor's time if it's intended to produce code - limited availability, limited scope and poor support from the university means that not much /actual/ work can get done IMO. On the other hand, there is undeniable value in introducing or motivating college students to join in open source development and I am quite certain that many of the participants will go on to participate past their stint with the academy.

Thank you very much for your evaluations.

About myself as org admin... I didn't have the time to follow this program properly, after an initial handshake and an occasional question, mentors were basically on their own. The situation might not be exceptional as long as the same org admin has to also be in charge of organizing two OPW rounds and one GSoC during the same period -- apart from all the regular work.

On the other hand, this type of game is very different. An OPW round might have 7 interns working full time during 3-4 months, while GSoC might be the same with up to 17-19 students. Here, only @GWicke had 12 students (but then @Spage only two), making each project complex in different ways, and being really difficult to recycle our well oiled processes for OPW/GSoC.

Some thoughts, starting to think in a potential second participation:

• I wonder whether this type of project is better suited for small ongoing projects run by one or just a few committed maintainers, very interested in reaching out to potential new contributors, and willing to have an external incentive to get that feature in the backlog done. @Parent5446 is a good example of what I mean.
• We need to be able to control the size of the team we are getting, or at least set a limit. @Spage was happy with 2, @GWicke had a hard time coordinating 12. There must be a sweet point that we should aim for.
• Even if the dynamics here are very different than in GSoC/OPW, I think we still can aim to apply the same criteria (see T1253). This would also set common and share expectations among students and mentors, a useful element when the sizes of the team, the availability/motivation of the students and even the dates of each project might differ so much between projects.
• The requirement of two mentors per project sounds like a good idea here as well.
• This is a good opportunity for an org admin other than me, and also other than a WMF employee. @Rfarrand and me would be happy to support someone known in the community that we can trust. The dedication is not as demanding as GSoC or even OPW, because the amount of projects is low, and the number of students involved is so high that following all of them one by one cannot be a requirement. Incentive for org admins: paid trip to SF Bay Area to enjoy a weekend in Facebook's headquarters (it is less glamorous than it sounds, but still).

I guess they will contact us soon. Or maybe not, because we skipped the 2ns semester round (we had just too much on our plate). We'll see.