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
