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.
> 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.
> 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).
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