There's actually a lot of useful things in this email for someone to learn if they're seeking to become a more regular contributor.
On Thu, Apr 30, 2009 at 10:29 PM, Mohamed Mansour <[email protected]>wrote: > I usually browse the issue tracker for HelpWanted tags, and try to solve > those bugs. It would be great if more HelpWanted tags would be tagged, so we > can have more variety of bugs to fix. > You've been contributing for a while. Have you fixed enough bugs that you can start tackling more significant issues more aggressively? HelpWanted is generally used as a "starter bug" tag, so the hope is that people begin really learning an area deeply enough to take important things. > It would be nice if anyone in the team could go through them and decide > whether that bug is _really_ needed. Some of them which I implemented took > hours to figure out, and turned out to be as a "not needed" patch. > The lesson is, don't implement things without coordinating ahead of time with the right people. Presence in the bug tracker has little correlation with desirability, since anyone can file anything. It would, indeed, be nice if things in the bug tracker were only things we were sure we wanted, and had good descriptions, and lots of other stuff. We are highly resource constrained, so triaging all 10000+ bugs (plus the couple thousand left over in our internal database) is just not feasible. If you want to work on something with a high chance of not being rejected, try to pick bugs marked P1 (or P0...). We definitely have looked at and care about those. A couple of us have vowed to be more aggressive about closing bugs we don't want instead of ignoring them, if we see them. And some of them, the reviewer doesn't have time to review the code because > he/she are busy, and then forget to actually review it. I don't believe it > is professional for myself to keep spamming the review for an update :) > That's what the rest of us do. Don't feel bad. A lot of time spent for just a small request. > I sympathize to some degree, but the best way to overcome this is to be so useful that we desire you to become a contributor with commit access. Some people will always review you quickly; some people always slowly; and some will stick you in their queue based on how worthwhile they think it's likely to be. Can't do much about the first two groups, but becoming a committer says a lot to the third. I am just wondering if it is worth contributing patches anymore. We all have > day jobs, and external contributors are usually students or people who come > home after work and code some more (like me). I would like it if there was a > mentor for dedicated newcomers, think of it as a free developer for the > chromium engineer. That way, when we do patches (iterations) we don't feel > left out. > It's really a cost-benefit thing. We have a couple external people who have rapidly become contributors due to very high-quality work, a lot of initiative, and good judgment. We have other people who are not moving along that path as rapidly. Are there people in the second group that (a) are good enough that it would be valuable to have them as committers, but we'll lose them if we don't do something, and (b) are _more_ valuable as committers than the mentor was doing whatever job he was doing before he started doing more "mentoring" work? The answer to this is not clear to me. Our take so far seems to have been "we have our heads down, and we'll try to be helpful to a point, but you need to be self-starting to really thrive here." PK --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
