This document is an overview of how developers can modify the Markup Validator, and how to contribute to the development of the project. It is intended for system administrators and developers. This is not end user documentation. See the User Manual for usage instructions.
The Markup Validator is managed as an open source project by a team of volunteer developers and people from the W3C Team.
Help on this project is always welcome, usually as feedback, but developers may also be interested in working directly on the code, which is certainly encouraged.
This document tries to give a general overview of the development framework for the Markup Validator, and should help developers get a good idea of how the project is managed.
The next steps would certainly be to read about source availability and then try a local installation of the validator, if not done yet. We also (obviously) recommend to get in touch with other developers, either through regular means, or on the IRC channel #validator on irc.freenode.net where many developers and contributors often are.
Bug and Issue Tracking for the Validator happens in the W3C Public Bugzilla instance. Developers should feel free to set up an account and report bugs, enhancement requests, patches, etc. directly there (end users should continue to send reports and ideas to the mailing list).
Any changes to the service will attempt to maintain compatibility with a list of test cases.
The validator has an automated test suite which is used frequently to check that no change has broken any feature or resurfaced a bug. Whenever possible, join a test case with your patches.
example: for a patch for the detection of document encoding in the <head>, join as a test case a simple HTML document with encoding information in the <head>, and another document without.
The TODO list for the Validator is online at <http://validator.w3.org/todo.html>. This is probably the best place to start.
However this list is by no means comprehensive. Feel free to suggest other features that should be on this list or send patches for your favourite feature.
Keep in mind that features should be of general utility and that the point if the validator is that it does an objective validation instead of just what some random developer happens to think is a Good Idea®. While extra features are nice, they shouldn't dilute the value of the validator as an objective check.