Re: Learning curves and such (was Re: pgFoundry)

>
> I think it might also be valuable to have a list of things that are good
> 'starter projects'. Maybe some indication of TODO items that are
> simpler. Possibly a list of bugs, too.
>
As someone who has looked at hacking the pg code, I agree it is difficult to
know what to look at to get started. I love fixing bugs, but I'm used to the
bug tracker type situation and being able to find something that looks relatively
easy. That is how I've started on a number of other projects. With no formal
bug tracker, I'm not sure what bugs I could look at. I have talked to some people
on IRC about tackling the infinite date issue, but was warned off that, as the date/time
code is a scary place.

Then I looked into the possibility of working on the autovacuum stuff, and again got myself
in a little too deep. Not low enough fruit for me.

The curve to get the meaning of some things is sometimes hard PG_TRY and things
like that just need reading code lots.

Not meaning to attack Tom, but for new people proposing new patches he can seem
intimidating. I have been around for a little while now and am adjusting to the reality.
Maybe people shouldn't be hacking the code before being here a year.

> It would probably also be useful to point out ways people can help that
> don't involve hacking C code (or at least not much). Things like docs,
> the website, advocacy, performance testing, etc.

It would be useful to outline positions that are actually available for people to take.
It's easy to give a general list. I've asked and seen may like it. For me, what does
helping with advocacy mean? What should be performance tested (I assume new code,
like the bitmap scan). But at the same time, how do I not get into something that is
being duplicated by somebody else?

I'm just trying to give a bit of a perspective on the way I see things as some who has been
around pg for about 12 months and attempted to hack the code a couple of times.

Regards

Russell Smith