Hi Werner,

I'm just jumping in on this thread in hopes to help you and other
contributors out.  Let me say that you have been a great sport and I can see
your intentions are pure.  But let me also give you an idea on what it's
like to be on the other side of the table.

You may feel justified in making demands on their time for features and bug
fixes as these things are obviously in the projects best interests.  This
point of view isn't wrong, just impractical.  If you take the same thought
just a bit further, you can assert that obviously they know these things are
in the project's best interest and would fix/do them if they had time, but
they don't--giving your time is really the only way you can help.  What is
in drastic short supply isn't ideas, it's manpower.

So, now, how can you contribute concretely? Always remember this:

     Ideas are good, but you do have all the source
     so you could actually implement your solution
     and then just try and get them to check it in.
     This is the best use of everyone's time,
     including your own.

     If it does work, great.  There is nothing
     subjective about java code, so they will know
     exactly how it may impact the software by
     looking at the code.  It may take forever to
     explain it first.

     If you find it doesn't work, this is also good.
     Then you didn't waste the time of the rest of
     your team by obligating them to explain why it
     is not a good solution.  This would be
     especially tragic they had to neglect other
     important needs in order to find the time to
     understand your explanation of the idea in the
     first place.

Let me take another moment to apply this perspective on the goals you have.

W> a) help you fixing this one particular problem.
Great, this is a positive goal.  But instead of "helping", why not just do
it.  They don't have time to take an active role in helping you fix the
problem, but they will certainly check your fix in if it works and is
tested.

W> b) help you identifying the problem (but it seems like
W> Thomas exactly knows what the problem is anyway)
Again, a very positive goal, your heart is in the right place.  As you
noticed, Thomas knows what the problem is.  The fact that it isn't fixed
just illustrates how little time he has.  Go ahead and fix it, Thomas has
already identified the problem, so he should be able to give you feedback on
the fix fairly quickly.  This is a great place to cut your "contributor's
teeth".

W> c) get an idea what the problem really is (whether it's
W> just a problem with the OQL Query builder)
The best way to learn something of this nature is just to dig right into the
code, not just looking but changing it, adding debug statements, compiling
it, trying it out, etc.  This is a quick path to gaining the knowledge
necessary for being one of the core contributors.     This is also what
Thomas or other members would usually have to do to find the answer anyway.
Why not take advantage of what is really a golden opportunity for learning.

W> d) etc.
Just remember, you don't need commit privileges to be a contributor.  The
more actively you contribute, the more others become dependent on you,
making you an increasingly important part of the team.

I truly hope you find positive motivation in this, Castor needs the
resources.

Best regards,
David Blevins
OpenEJB


> -----Original Message-----
> From: Werner Guttmann [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 15, 2002 1:01 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [castor-dev] What is the process of contributing to Castor;
>
>
> Thanks, Bruce. It does, at least for now. You might have seen the
> "Plea for info ..."
> thread on castor-dev, where me and two colleagues of mine are
> trying to establish whether
> major bugs (or "change requests", as Thomas calls them) will get
> resolved in the near
> future (based on messages found in the archives about 8 months ago).
>
> I guess we are just afraid that we will have to abandon Castor as
> one of our tools to use
> as our expectations towards bug resolution(s) have not been met.
> Now I know that Castor
> is open-source, but Thomas has made it very clear that he doesn't
> appreciate more
> developers due to ongoing refactoring.
>
> It's just a bit of a dilemma we are facing here, and we are
> trying to find a way to
>
> a) help you fixing this one particular problem.
> b) help you identifying the problem (but it seems like Thomas
> exactly knows what the
> problem is anyway)
> c) get an idea what the problem really is (whether it's just a
> problem with the OQL Query
> builder)
> d) etc.
>
> Thanks
> Werner
>
> Bruce Snyder wrote:
>
> > Werner Guttmann wrote:
> > >
> > > excuse my curiosity, but what's the last time this
> contributor list has been
> > > updated? In other words, how many people are really
> contributing towards JDO ? If I
> > > remember some past thread on castor-dev correctly, Assaf, for
> example, has left the
> > > project.
> >
> > Werner,
> >
> > Yes, you're correct. Although Assaf is the original architect of Castor,
> > he is no longer involved on a day-to-day level.
> >
> > Keith Visco, Arnaud Blandin, Sebastien Gignoux and Andrew Fawcett
> > actively work on the Castor XML side. Thomas Yip, Oleg Nitz, myself and
> > one or two others actively work on the Castor JDO side.
> >
> > Others listed on the contributors page have made contributions over
> > time, but are not actively involved.
> >
> > Does this help, Werner?
> >
> > Bruce
> >
> > -----------------------------------------------------------
> > If you wish to unsubscribe from this mailing, send mail to
> > [EMAIL PROTECTED] with a subject of:
> >         unsubscribe castor-dev
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
>       unsubscribe castor-dev
>

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to