No subject

and nobody gives me a response, either they don't know the answer, or
are currently doing something else that is a higher priority to them
than answering that question (particularly if I haven't provided enough
information for them to be able to answer it decisively). Then I have
the choice of either moving on to worry about something else, or diving
into the problem and learning enough to resolve the problem for myself
(and often posting the results on the wiki or on the mailing list or
answering myself on IRC).

Many of us in the developer community know just enough about the
underlying dependencies like PostgreSQL or the underlying operating
systems to keep our own Evergreen installations running on the beaten
path. If we don't know the answer to a question that seems to be off the
beaten path, or which is quite complex (say, a major upgrade of
PostgreSQL versions), do you expect us to go and research all of the
pieces of the puzzle when you are the person that has all of the
information at hand (such as your PostgreSQL version, ability to
determine which contrib modules have been installed, PostgreSQL logs,
etc)? Wouldn't it be far more efficient for you to take that information
to the community that actually has deep expertise in that particular
piece of the problem, find the answer, and bring that answer back to the
Evergreen community?

> These are the kinds of things a "Developers & Contributors Support Committee" could help solve.  
> Perhaps it is a sub-committee of communications and without the power to lock-up the repository.  

You could set this up without the Evergreen Software Foundation.

> Perhaps one of it's functions is to act as an administrative assisting body to developers and contributors 
> so that the programmers on the ground have a place to shunt the n00bs without losing their development stride?
> It should be important to us not to "shut down" the potential new contributor.

I would argue that that's an existing principle that we already follow.
But perhaps our bar for what a new contributor can be is too high, if we
expect them to understand how open source projects work.

> Another function might be to help non-hacker managers understand why they should support the efforts of 
> their hard core programmers in contributing to the community even if the institution's revenue model isn't clear.

Sure. But again, I don't think that this requires the Evergreen Software
Foundation. You can write that document in the wiki today.

> Another function might be to help individuals and institutions assess their talent against community needs and "hook-up" 
> technicians with projects at appropriate skill levels.  Now if you are a C++, PERL, Python or Java strong programmer, you have to 
> blunder your way around until you find the section of Evergreen that you can understand without learning a new language
> and begin to poke.  Again this is unless you are actively involved in a deployment, you have a very understanding boss, or no life.

Again... the Foundation is not required to set something like this up.

>  Contributors sometimes dabble and then give up in any community but without organized support we'll shed 
> talent we can't afford to lose.  There is a need for this kind of support to be organized in the community in the 
> interests of fostering a stronger contributor base that doesn't die out when their grants do.

Efforts can and should be organized without being written into the
bylaws of a Foundation. If the effort can't stand on its own, then
adding administrative overhead to it certainly isn't going to help. Just
go forth and start organizing. The Documentation Interest Group is
making progress without the auspices of the Foundation, because there is
a group of people interested in addressing the problem with a set of
leaders (Karen Collier and Robert Souilliere) who are keeping the effort
rolling along.