[dev] steps for committing new functionality

[amith at xalan.com]

I've been sending some patches in and they have been committed, but the more I
follow the lists, I've been thinking that I (and others) can do more to help
the project by also sending in other things like documentation, etc.

For example, I sent in a patch that blocked images in HTML messages, and Michael
was good enough to fix it up and I think Eric contributed some docs.  But I
think I could have at least done the docs for what I submitted.

Can the core developers recommend a list of things that should be submitted with
every patch?   I think maybe there should be a more formal set of criteria
before a patch is accepted.  Maybe if we made a minimum set of criteria and
then a desired set, people will know what is definitely needed and this will
reduce the load from the core developers (helping them implement new cool stuff
that people with limited time aren't able to get to)

For example:

Minimum Set of Requirements
1) Patch of all files changed using the command "cvs diff -u <files changed>"
2) Patches to help files (be more specific here about which files and where they
are located) if patch effects UI or needs any additional configuration on the
backend
3) Changes to docs/CHANGES
4) Anything else?

Desired Set of Requirements
1) All of the Minimum Set
2) Patch for RELENG version (if applicable)
3) Anything else?

I hope this makes sense.  I guess what I'm advocating here is a more formal
process for people to submit patches.  I think sometimes the core developers
get bogged down with things that some of us can do.  If having a minimum set
isn't really possible, I think we should have some type of task list accessible
to the public where we can see things that should be done.  What does everyone
think?

Amith