OpenSource Bugfix Bananza(plus.google.com)
plus.google.com
OpenSource Bugfix Bananza
https://plus.google.com/113450464468623482873/posts/gTmYwMfJFV5
4 comments
Good idea. I particularly like the idea of sharing your list publicly.
Though it might be better if it was fixing multiple bugs in few projects as opposed to one bug in so many projects.
Also, for those of us that have used every language under the soon, maybe the focus should be on a language not used in the last year.
Though it might be better if it was fixing multiple bugs in few projects as opposed to one bug in so many projects.
Also, for those of us that have used every language under the soon, maybe the focus should be on a language not used in the last year.
The reason we picked lots of projects is to narrow it down to 5 we might be willing to actually spend our free time working on, thus actually fixing lots of bugs in our favorite 5. I expect the top 5 will not fluctuate much over the rounds, as our first 20 are seeded with projects we already know / work on.
Good point about languages. Since my brother and I have used very few languages we focused on the desire to expand on that. But for those that have used every language under the sun feel free to pick a languages you have not used in a while :).
Good point about languages. Since my brother and I have used very few languages we focused on the desire to expand on that. But for those that have used every language under the sun feel free to pick a languages you have not used in a while :).
In my experience, the overhead in figuring out a codebase is usually large. So taking 5+ new projects each time would mean that you would be spending a lot of time on just reading code.
Now improving code reading/understanding skills is not a bad idea, it is just that it does not seem to be your goal. I would suggest just taking 1 new project each round.
I guess this also matters if you are working on this full-time or not.
Would love to read your experience report as you progress through the rounds.
Now improving code reading/understanding skills is not a bad idea, it is just that it does not seem to be your goal. I would suggest just taking 1 new project each round.
I guess this also matters if you are working on this full-time or not.
Would love to read your experience report as you progress through the rounds.
Part of it is to get experience in understanding diverse code bases quickly, but also to see lots of diverse code bases and styles to see what we like and dis-like about each.
We are not working on this full time, so I expect round one will take two to three months, round two will take about the same. Round 3+ will likely take one to two months.
We are not working on this full time, so I expect round one will take two to three months, round two will take about the same. Round 3+ will likely take one to two months.
Great. Let us know how it goes. It has definitely inspired me to atleast run a variant of this.
So, I noticed that something like half or so of the projects here are C++.
Depending on the codebase (and what bits of the language it uses), you may be in for a real treat. Especially given the fact that this is your first exposure to the language, I would be unsurprised if you end up introducing new, fun bugs into the codebase. Godspeed!
(and don't worry about said bugs--this is a chance to learn, so make the most of it! Somebody else will more than likely be able to clean up any missteps. :) )
Depending on the codebase (and what bits of the language it uses), you may be in for a real treat. Especially given the fact that this is your first exposure to the language, I would be unsurprised if you end up introducing new, fun bugs into the codebase. Godspeed!
(and don't worry about said bugs--this is a chance to learn, so make the most of it! Somebody else will more than likely be able to clean up any missteps. :) )
Is that a deliberate misspelling?
If you just want to "learn" about open source, read their mailing lists and forums, though you might learn a few things you don't want to know.