Jeff King wrote: > On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote: > >> I'll be frank here. I think the main reason for a student to stick >> around is to see more of his code hit `master`. I think it is >> absolutely essential to get students constantly post iteration after >> iteration on the list. It would be nice to get them connected with 2~3 >> people in the community who will follow their progress and pitch in >> everytime they post an iteration. It might also make sense to stage >> their work in the main tree (a gsoc/ namespace?), so we can just >> checkout to their branch to demo what they've done. > > I agree. One of the main problems with GSoC projects is that the student > goes away and works for a while, and then at the end does not > necessarily have something mergeable. That is not how regular > contributors work. They post works in progress, get feedback, and > iterate on ideas. They break work into easily digestable and reviewable > chunks. > So maybe the mentors should be focusing more on that than on > actual code problems. Take what I'm about to say with a pinch of salt, because I've never mentored. Mentors often don't provide much technical assistance: students should just post to the list with queries, or ask on #git-devel. Mentors serve a different purpose; their primary responsibility, in my opinion, is to teach the student a sustainable productive workflow. This means: profiling them to figure out where they're losing out. Do they have the habit of: - posting to the list regularly? - CC'ing the right people? - iterating quickly after reviews? - using gdb efficiently to quickly understand parts? - using git efficiently for the rebase/ patch workflow? >> Also, we need more projects that will scratch everyday itches. A >> collection of related tiny features might not be a bad idea. Often, >> we risk erring on the side of too-big-for-one-summer when it comes to >> specifying projects. What's the harm of including something estimated >> to take 80% of a summer? > > I very much agree with you here. One problem is that those smaller > projects often do not sound as grand or as interesting, and so students > do not propose them. We have to work with the applicants we get. We have to post well-crafted proposals like this to pique their interest. >> On a related note, I don't like our Wiki. It's down half the time, >> and it's very badly maintained. I want to write content for our Wiki >> from the comfort of my editor, with version control aiding me. And I >> can't stand archaic WikiText. > > Agreed on all of those points. Putting the Wiki on GitHub fixes that. > But it means contributors need to have a GitHub account. On the other > hand, I think kernel.org wiki contributors need an account these days? > And GitHub is putting some active effort into finding and killing spammy > accounts, which might keep wiki spam down (I do not pay too much > attention to those efforts, but on kernel.org, it is mostly up to the > Git community to do it ourselves). No, I'm against using the GitHub Wiki for neutrality reasons. There is one easy way to fight spam: don't expose a web-based editing interface at all. It's mainly going to be maintained by the community, and we're all much more comfortable in our editors and git. We can give the regulars direct commit access and ask the rest to submit pull requests. Make it cost pennies, so any of us can easily afford it: just a cheap domain, DNS, and static HTML hosting. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html