Dave Held wrote:
-----Original Message-----
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Monday, May 02, 2005 7:05 PM
To: [EMAIL PROTECTED]
Cc: Dave Held; [EMAIL PROTECTED];
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
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
