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
Re: [GENERAL] Feature enhancement request : use of libgda in Re: [GENERAL] Feature enhancement request : use of libgda in Re: [GENERAL] Feature enhancement request : use of libgda |
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: