> I never thought I'd do this but here goes.
> 
> I need to let everyone know that, in spite of the problems that may crop
> up from time to time, Charles has been (for me) very responsive in the
> code segments that I have sent him.

I'd second this.  This applies to other core members as well.  At various times
I've had exchanges with just about everyone on the team, and I've always 
been pretty happy with the response I've gotten.  Some people are more direct
or harder to convince or more skeptical than others, but I haven't found anyone
to be unrealistic, significantly inconsiderate, or terribly defensive.

I know the amount of time
it takes to answer mail and I can say that if the core team gets more than
even a 1/2 dozen messages a day that they wouldn't get anything done if
they even just tried to read and acknowledge them.  And *that* would assume
it was their full time job.  Most of us know full well the amount of time
software development takes...and most of us would be unwilling or unable to
expend the amount of time that many of the major contributers do.
I know I can't get away with too much time on things, my wife would kill me,
so I get to things when I can, and don't when I cant.  You can't expect 
anything
more of anyone else.

>From time to time things I've sent in burble to the top of peoples queue's
and then I get very thoughtful and well reasoned responses, some terse, some
not.

Also, sometimes it's taken a few tries to explain things, but its always
worth the patience.

Remember that NetBSD is a *lot* of code, so whatever you think is obvious,
may not be...I've never found anyone complain about getting too much 
information.  If you send things in remember...

Give all relevant information even if it seems obvious.  Exact version,
	exact circumstances, etc.

If referencing code, include as complete a reference as code...no one can
remember everything.  Patches obviously should be complete...if making 
general comments about code, things like "why is the 2nd test for DEFINE_X
done in foo() in xyx.c when it's already been checked before the call in
boo() in yxy.c" save a lot of time and are more likely to get a response
then "why is DEFINE_X tested twice?".

If it matters, use send-pr.  Feel free to ask current-users if you want to
be sure your not alone or suffering pilot error, but if it's truely a bug or
you truely want it not to be forgotten, use send-pr.  That way it gets 
recorded for posterity and wont be forgotten (by core people or you).
If you have a patch, include it in the send-pr.  Then if someone gets to it
3 weeks later, they are much more likely to give it a try if they don't have
to play email tag to get more input from you.

If you think a change should be made, say why.  Also, that why will get a lot
closer listen if you explain why and where it actually solves or avoids a
real problem rather than any subjective (I like it this way in SunOS 3.5) or
quasi-subjective (POSIX.37-1964 says it should be so). reason.  If you sight
standards compliance, sight a real reference, either the standard itself,
certain "bibles" like the POSIX.1 book, Harbison and Steel, etc.

> What I think needs to happen next is that the circle of core members
> needs to step out one pace.  I'm sure that there are many people that
> have the time and the training to be considered for inclusion in this
> effort.  A few names immediately pop to mind (not my name, but you know
> who I mean).  By adding to the size of the core team, it will reduce
> some of the burden on those of you in the inner circle now.  

It would probably help if there could be one or two people who weren't
going any code development to just handle incoming mail, route requests,
and follow up on things, but it's pretty amazing that things go so well, it
just shows how hard people have worked on and care about the NetBSD project.
--
Mark