On Mon, Dec 07, 2009 at 09:53:32AM +0100, Albe Laurenz wrote: > abindra wrote: > > Next quarter I am planning to do an Independent Study course > > where the main objective would be to allow me to get familiar > > with the internals of Postgres by working on a project(s). I > > would like to work on something that could possibly be > > accepted as a patch. > > > > This is (I think) somewhat similar to what students do during > > google summer and I was hoping to get some help here in terms of: > > 1. A good project to work on for a newbie. > > 2. Would someone be willing to be a mentor? It would be nice > > to be able to get some guidance on a one-to-one basis. > > I would start with the TODO list: http://wiki.postgresql.org/wiki/Todo > These are things for which there is a consensus that it would be > a good idea to implement them. Pick things that look interesting to > you, and try to read the discussions in the archives that lead > to the TODO items.
I agree the TODO list is a good place to start. Other good sources include the -hackers list and comments in the code. I was surprised when I began taking an interest in PostgreSQL how rarely interesting projects mentioned on -hackers made it into the TODO list; I've come to realize that the TODO contains, in general, very non-controversial items everyone is pretty sure we could use, whereas -hackers ranges freely over other topics which are still very interesting but often more controversial or less obviously necessary. Committed patches both large and small address TODO list items fairly rarely, so don't get too hung up on finding something from the TODO list alone. > Bring the topic up in the hackers list, say that you would like > to work on this or that TODO item, present your ideas of how you > want to do it. Ask about things where you feel insecure. > If you get some support, proceed to write a patch. Ask for > directions, post half-baked patches and ask for comments. > > That is because you will probably receive a good amount of > critizism and maybe rejection, and if you invest a couple of > months into working on something that nobody knows about *and* > your work gets rejected, that is much worse than drawing fire > right away. +1. Especially when developing a complex patch, and especially when you're new to the community, you need to avoid working in a vacuum, for social as well as technical reasons. The more complex a patch, the more consensus you'll eventually need to achieve before getting it committed, in general, and it helps to gain that consensus early on, rather than after you've written a lot of code. The keyword "proposal" might be a useful search term when digging in the -hackers archives for historical examples. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
signature.asc
Description: Digital signature
