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

[2002-02-12 09:54] Greg Copeland said:

Please understand that I am a wannabe-developer at the bottom of
a big learning curve when reading my comments.

| 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.  

I think the problem is the perception of "lesser" features.  What
an outsider may see as a little problem, may infact be a large 
problem that cannot be suitably solved at the present time, or 
require other seemingly-unrelated infrastructure to accomplish.
_Much_ of what some core developers work on is totally orthogonal
to anything I'd be able to work on right now.

| 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 can assure you that if you show that you are putting forth effort,
there will be a developer who can and will help you when you need it.
This means you _will_ spend 10 times as long on a problem than the
developer who's helping.  This is the way it should be.  The biggest
hurdle to postgres development is the size/complexity of the code,
and there is only one way to overcome that; dedication, time and
expertise -- things that all of the core developers have invested
and earned.

| 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 agree that it seems like it would be nice to get a quick answer 
for a 'simple' problem, but you miss out on all the non-answers,
which increase familiarity with the codebase.  I do appreciate
being pointed in the right direction when I'm wandering around
the wrong area, and I think that is about all that should be done.

| I find that this helps well beyond 
| that of a mailing list as people tend to be more timid in a public 
| forum.

All I can suggest is to suck up the timidity.  I know I've made a
monkey of myself on a few occasions, and I'm sure I will again until
I learn what I need.  This is part of the learning process.  Also, 
hiding valuable communication on private channels does nothing to 
inform new would-be-developers of past questions/problems; not using
the email archives when in 'idea' mode is a sure sign that the
would-be-developer needs to learn to use those archives -- a sin
I've been guilty of :-(

| 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.

I agree that a public, archived, irc might be useful, but you have 
to take into consideration the fact that, at least for me, this
project requires prolonged code gazing sessions, which would only
be interrupted by "instant" communication.  I, and maybe the real
developers, like the fact that email can be consumed /after/ a problem
is investigated/solved.

| 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.

This already happens.  There is little hand-holding, but if you 
show that you are standing, someone will likely help you walk.
I have never seen a more helpful, dedicated, intelligent developer
group than this one -- and I have seen a few.  For this reason alone,
the postgresql project will flourish when others wither.

|  Wouldn't it be more helpful to point would-be developers at 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?

I agree, a quick-start guide might be helpful, but given the complexity
of this project, a quick-start guide might be more maintenance than
it is worth.  In all honesty, it took me about a month of weekends
to get my head enough into the code that I could find my way around.
If a potential contributor is not willing to show that amount of
initiative, why should the core group think they'll have sufficient
interest to maintain/support any code of theirs that gets into the
codebase?

| 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?

An hour of core-developer time might allow you to _not_ learn important
other things that you'll need later.

my $.02 brent

-- 
"Develop your talent, man, and leave the world something. Records are 
really gifts from people. To think that an artist would love you enough
to share his music with anyone is a beautiful thing."  -- Duane Allman