To maximize the probability that your ideas will grab the attention of one of the Xerces developers who knows about the area of the parser you're concerned with, you should follow these steps:

1. Check out and build the most recent Xerces code. For instructions on how to do this, see Apache XML Project CVS Information. If you do this, you can confirm that your bug still exists and has not been fixed since the last release.
2. Write up your bug report. Include a description of your system (JDK level and vendor, platform and classpath contents) as well as sufficient code to reproduce the problem. This code might involve XML documents, accompanying grammars, and the code you are using to invoke the parser or use its APIs.
3. Describe why your solution works.
4. Prepare a patch to fix Xerces code. To do this, when you have applied your changes to a local copy of the most recent xerces source code, do cvs diff -u file for each file you've changed.
5. Zip (or tar) up your patches. If you send them in the body of a message or bug report they are very difficult to apply.
6. Submit a bug report on JIRA (remembering to attach your patches and test code) or, if you think your patch might need some discussion, post it to the j-dev@xerces.apache.org list.

You're in luck--it isn't at all difficult. Just follow these steps and you'll be done in no time:

1. Ensure that the API code has been properly refreshed. That is, make sure that tools/xml-apis.jar and tools/xml-apis--src.zip reflect the state of the branch of xml-commons that contains the API set to which the parser must conform. At the time of writing (March 20, 2003) this was the branch tck-jaxp-1_2_0.
2. Change the following files:
   build.xml (that is, change the parser.Version, parser.version, and parser_version properties as appropriate for the release).
   docs/releases.xml (contributors should have updated this file as significant changes/patches were applied, but the release manager should verify that nothing has slipped through. Also, the release manager should attempt to ensure that appropriate credit has been given for contributions).
3. Tag the release in CVS (tags for releases usually have the form Xerces-J_x_y_z where x.y.z is the Xerces-J release number) You should also tag the current branch of xml-commons containing the APIs that the parser needs to conform to; see step 1 above.
4. Do a test build and regression test run; i.e., build test at a bare minimum. In general, apply as many test suites (Oasis XML tests, W3C DOM and Schema tests etc.) as are available, particularly with a view to preventing regressions since the previous release.
5. Do the final build based on that tag:
   windows build to produce .zip packages
   unix build (on a unix machine to make sure no 0x0d's appear in documentation of .tar.gz packages. Beware to do the build from within X-windows to avoid problems with StyleBook on the command-line!
6. zip and tar the tools directory
7. Generate PGP/GNUPG signatures for dist binaries:
   That is, add public key to the CVS KEYS file if necessary and make sure public key is on a key server or two.
8. Upload the binaries and signatures to the dist section of the website
9. Update /www/xml.apache.org/dist/xerces-j/.htaccess, which directs the user to the most recent release. Take care to move old packages to the old_xerces directory so that the package listing is manageable.
10. Prepare release e-mail -- be sure to give contributors credit for their work
11. Send the release e-mail to the xerces-j lists, general@xml and, if it's a big enough release, announcements@xml.apache.org and announcements@apache.org
12. Bugzilla :
    Firstly, create new release. Then, remove oldest release (if we are up-to 6 releases).
13. Website:
    Upload generated docs directory to daedalus (until this process matures and becomes CVS-based). Commit /www/xml.apache.org/xerces2-j to CVS; i.e., update the xml-site module.