On Wed, Jan 27, 2016 at 4:40 PM, Moritz Neeb <lists@xxxxxxxxxxxxx> wrote: > Hi git developers, > > the next Google Summer of Code is not too far away. I expect git to > apply for it and hopefully have some student spots which in turn I plan > to apply. It was recommended elsewhere and on this list as well, that it > is beneficial to engage with the community early, that's why I am > writing to you already now, before all this formal stuff has begun. > > Before I may introduce myself: I'm a Computer Science student in > Germany, coming towards the end of my Masters. I am an enthusiastic git > user that's why I'd like to give something back. Giving back is a noble thing. To have most fun at it, you need to ask yourself: What is the most obnoxious part of Git that you personally use? What was the latest problem you had, which you'd want to fix? If you identified that, is that the right size to fix it? (Usually it is way bigger than thought, but you can ask around if there are approaches for solving that problem ;) > This would be my first > time to actually contribute to a FOSS project and I am quite excited > (also a bit frightened ;)). Each FLOSS project is run differently. So in case your fright was the right instinct, go for some other project, it will be totally different. > > As the list of available microprojects 2016 is still to be created, I > might need your help in finding a project to work on. I started to dig > through the archives along items of the list of 2015 [0] and so far > found out the following: Some smaller starter projects may be found at http://git-blame.blogspot.com/p/leftover-bits.html The size and difficulty of these projects may vary a bit more than the micro projects for GSoC though. > > The first task, to make "git -C '' cmd" not to barf seems to be solved. > I tried it with "git -C '' status" at least. I could not find the > related patch, maybe it did use other keywords. I would be interested. > > The second task, to allow "-" as a short-hand for "@{-1}" in more places > seems to be still open for reset, although someone almost finished it > (cf. $gmane/265417). I suppose just fixing/revising this would be kind > of a too low hanging fruit? More interesting (also because I am a bit > earlier) might be to unify everything, as suggested by Junio in > $gmane/265260. Or implementing it for another branch command, e.g. rebase. > > The other tasks I did not yet dig into. > > If all of that is considered as not relevant, I might just go for a > newer idea, like converting strbuf_getline_lf() callers to > strbuf_getline(), as suggested in $gmane/284104. > > Any thoughts? > > A question regarding the process of "taking a task (or bug)" in general: > Is it solely organized through the mailing list? Yes, I'd say 95% of the discussion is done on the mailing list. (The remaining 5% is done on conferences, or privately for security related stuff I'd assume) > Suppose I start to work > on something, should I announce it to not risk work duplication? [In the context of fighting procrastination,] I recently read that announcing that you are going to work on $FOO is not necessarily helpful for actually doing it. Chances are lower that you actually finish a thing which you announced. However feel free to announce what you work on. Usually people don't. > Does it > happen often that more people accidentally work on the same task? It happens rarely for larger goals. For the GSoc micro projects however some students did the same thing with slight differences. (2015 we only had 2 spots to fill but a few more applicants (3-5?), but seeing how students approached the same problem helped on deciding whom to mentor. (Given different problems it would have been harder.) > > Best, > Moritz > > [0] http://git.github.io/SoC-2015-Microprojects.html I just realized there are some micro projects on the 2014 page as well which haven't been solved yet. (maybe, they are not striked through) Thanks, Stefan -- 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