On Wed, Feb 26, 2014 at 11:41:21AM +0100, Michael Haggerty wrote: > > Yes, though I think it makes sense to put them on a separate page. We > > should probably write up some notes for students, too: how to get in > > touch with us, what do we expect of them in the pre-proposal period, > > what would we expect in terms of communication and day-to-day workflow > > during the summer, etc. > > Since time is short, I already started on this. I wrote a first draft > of an introduction for the students. I also started looking for > microprojects. I started going through our source files alphabetically, > and have already found six suggestions by "bundle.c", so I don't think > there will be a problem finding enough tiny things to do.
Thanks, the intro text looks great. We probably need some intro text to go on the ideas page (that is what Google links to for prospective students) that points them to the microproject page. > See my branch on GitHub [1] or read the appended text below. I've merged and pushed out your branch (I'll work on getting push access for people, as there's no real reason for me to be an integration bottleneck with this stuff). > I've been looking for *really* tiny projects. Feedback is welcome about > whether they are too trivial to be meaningful in distinguishing > promising students from no-hopers. My feeling is that there is so much > process involved in submitting a patch that it will take even a > well-prepared student quite a while to make a change, no matter how trivial. I really like the level of the projects below. It should be more about the process than the code, and I think you nailed that. I especially like the ones that require some digging in history. The bug list I mentioned before is probably too heavyweight in that sense (they're more like 4-6 hour projects for somebody who isn't familiar with the code, plus submission headaches on top of that). > Also, how many suggested microprojects do you think we need (i.e., when > can I stop :-) )? I think it depends on how quickly people do them. We can always add more if they run low (though 6 does not provide a huge buffer, so we may want a few more). > 6. Change `bundle.c:add_to_ref_list()` to use `ALLOC_GROW()`. This is the only one that seemed like it might be _too_ trivial to me. The memcpy/hashcpy one is similarly trivial, but I like the add-on of "look for other places". I guess we could do that here, too. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
