Re: [HACKERS] Feature enhancement request : use of libgda

Wow!  100% agree.  I have felt this way for a long time, that IRC and
AIM are valuable technologies for helping new developers along.  I am
currently working with someone in India who wants to work on the buffer
manager.  I worked with him via AIM on the TODO list items, and he will
look over the code and make a posting to hackers soon to describe the
item he wants to tackle.  (In fact, I am chatting to him right now and
he has already posted to hackers list.)

The ability to ask a few questions in real-time is invaluable for
improving the output of contributors.  Getting people past those few
stumbling blocks makes a huge difference.

I am bmomjian on the #postgresql channel of EfNet, and bmomjian on AOL
chat (AIM).  I look forward to helping anyone who needs it.  I used to
have long phone conversations over code issues, and I can do that too.

---------------------------------------------------------------------------

Greg Copeland wrote:
> 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 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?
>
> 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
> >
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026