Dave Held wrote:
>>-----Original Message-----
>>From: Andrew Dunstan [mailto:andrew@dunslane.net]
>>Sent: Monday, May 02, 2005 7:05 PM
>>To: xzilla@users.sourceforge.net
>>Cc: Dave Held; pgsql-advocacy@postgresql.org;
>>pgsql-hackers@postgresql.org
>>Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
>>Increased
>>company involvement
>>
>>[...]
>>I nat happy avout that last point - personally, I value most
>>highly the views of those who contribute code or similar and
>>least highly the views of those whose principal contribution
>>is opinions.
>>
>>
>
>Maybe so, but if you were a new contributor, why would you write
>a bunch of code with no assurance that it would go anywhere?
>
>
People write code for lots of reasons, only some of which have directly
to do with geting that code into the distributed product.
But I digress :-)
>It seems wiser to invest your time familiarizing yourself with
>the ins and outs of the codebase and the coding style of patches
>by looking at other people's work. It also seems smarter to
>lurk and see what kinds of changes are likely to be considered.
>I doubt you would think highly of a newcomer that contributed
>code that was not in the style of the codebase and was for a
>feature not on the TODO list and that didn't get community buy-in
>first.
>
I never suggested otherwise.
>But then, how do you get community buy-in if you don't
>contribute code, according to you?
>
>
>
>
The surest path is to do things incrementally. And ask *lots* of
questions. The bigger the development, and the more inexperienced you
are, the more questions you should ask. Just getting the answers to
yuour questions gets you some buyin (unless the consensus answer is
"don't do it"). But the best bet is to build up credibility by doing
small projects to start with.
The postgres processes are nebulous, ill-defined, even. I don't see that
as necessarily a bad thing.
cheers
andrew