Re: [GENERAL] Feature enhancement request : use of libgda in - Mailing list pgsql-hackers

From Greg Copeland
Subject Re: [GENERAL] Feature enhancement request : use of libgda in
Date
Msg-id 3C693A9C.2070005@copelandconsulting.net
Whole thread Raw
In response to Re: [GENERAL] Feature enhancement request : use of libgda in  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Responses Re: [GENERAL] Feature enhancement request : use of libgda in  (Brent Verner <brent@rcfile.org>)
Re: [GENERAL] Feature enhancement request : use of libgda in  ("Ross J. Reedstrom" <reedstrm@rice.edu>)
Re: [GENERAL] Feature enhancement request : use of libgda in  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [GENERAL] Feature enhancement request : use of libgda  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
I'm new to the list but I'm going to speak up anyways.  Being a core 
developer on several other projects, I feel that it's important to point 
out that both comments are valid here.  As a core developer, I certainly 
don't want to implement seemingly lessor features when more pressing 
issues are at hand.  At the same time, I would like to see user demand 
met and have some of the other developers lend a hand while polishing 
their knowledge on the project in general.  What I've found especially 
useful has been to tutor and guide (okay, hand-hold) newer/younger 
developers to my projects so that their abilities are quickly 
complimented.  I find that using IRC or even other IM technology can go 
a long way toward providing support for would-be developers.  Especially 
for projects of this complexity.  I find that this helps well beyond 
that of a mailing list as people tend to be more timid in a public 
forum.  After all, it's well understood that a degree of p2p interaction 
is often very helpful and tends to be even more so as the complexity of 
the topic grows.

Tutoring can not only allow developers that are less intimate with the 
code become more useful but help ensure the effort they put forward is 
not only accepted but implemented in an ideal manner.  This is a win for 
the developers and the project as a whole.  I find it also helps build a 
level of trust with future submissions from the developer in question. 
Of course, it also helps build retention with newer developers as it 
more quickly allows them to feel like they are making a difference.  A 
key ingredient for any developer that is to stay with any project for 
the long haul.

In fact, I'm happy this came up as I recently emailed a core developer 
asking for places to start as well as any preferred documentation to 
start with.  Basically I was told read the code and go read the docs. 
Which is exactly where I was before I emailed him.  This is not to say 
that I wasn't happy to have him reply but his response pretty much 
provided no value and added nothing beyond what common sense tells you.  Wouldn't it be more helpful to point would-be
developersat a specific 
 
section of code telling them why they'd want to start there and where 
any specific documentation is that may be of value?

Now, I'm not saying we should move away from the mailing list, rather, 
I'm saying that the core developers way want to reconsider how some 
requests for help are answered and maybe even consider other forms of 
complimentary communication.  Doesn't a hour of a core developers time 
in trade for multiple increase in productivity of another developer seem 
like a good trade?

Just some food for thought.

Greg



Tom Lane wrote:
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> 
>>To a certain extent I agree.  I have definitely seen times where I have
>>spent hours and hours and hours of coding doing something that a core
>>developer can do in no time, but just isn't inclined to do.
>>
> 
> Well, you know, there is some method in our madness.  We'd like to see
> more people develop the skills to work on Postgres, and the above is how
> you do it.  (How do you think the core developers learned?)  If we did
> all the "easy" stuff because it was easy, there'd be no appropriate
> projects for new developers to tackle.
> 
> Which is not to say that DROP COLUMN is easy; it's not.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: alter table drop column status
Next
From: Stephan Szabo
Date:
Subject: Re: again on index usage (7.1.3)