This article lists common questions for WordPress core developers, as well as developers of WordPress plugins and themes, and refers you to articles that contain the answers. There is also a list of resources at Developer Documentation, which might be of help.
Check out Contributing to WordPress to find out what you can do and how to get involved.
See Reporting Bugs.
See How does code make it into WordPress.
Yes. WordPress Coding Standards has a list of coding standards used by WordPress core developers, plugin developers, and theme authors.
Definitely! See WordPress in Your Language for information on existing translations, and Translating WordPress to find out how you can help if your language's translation is missing or needs improvement.
Subversion is the online program used to track changes and upgrades to WordPress for developers. See Using Subversion for more information. There is also an online browser for the WordPress Subversion repository.
Problems with plugins are best reported to the plugin author (visit the plugin's home page to find out how to contact the author). For plugins that are included in the wp-plugins.org Plugin Repository, you can also report bugs in the wp-plugins.org TrackTickets site.
Yes, there are several. Plugins has the most comprehensive list of plugin repositories.
Absolutely! You can browse the vast collection in the WordPress Theme Repository.
Basic instructions on how to write a plugin for WordPress can be found in Writing a Plugin. The API of "Hooks" for plugins is described in Plugin API. There is also a comprehensive list of other plugin resources in Plugin Resources.
See Theme Development for an introduction, and Templates for a list of resources.
Yes. See WordPress Cookies.
Most plugin and theme authors choose to license their plugins and themes under the GPL. Also, keep in mind that if your theme or plugin incorporates code from another theme or plugin that uses the GPL, you will probably need to license your theme or plugin with the GPL as well. If your theme or plugin is completely independent of other WordPress code, themes, and plugins, then you can probably license it however you would like.
See Database Description.
While in theory supporting more databases is better than supporting one, in practice focusing on MySQL/MariaDB has a number of benefits.
First, introducing support for databases other than MySQL/MariaDB would increase the testing load for all development quite a bit, as already the combinations of PHP versions, web servers like Apache, Lighttpd, and IIS, and Windows vs Linux cause a number of issues, multiplying that by an arbitrary number of database platforms is daunting.
Early on in WordPress' history when DB abstraction was seriously considered we noticed packages like AdoDB were bigger than WordPress itself, which seemed like a lot of weight for little gain.
DB independence also requires far more than just dropping in a DB abstraction class, as basic assumptions WP makes about things like primary keys, indices, auto incrementing fields, LIMITs, and more vary more from DB to DB than a class could support without serious code changes.
Finally, MySQL/MariaDB is ubiquitous and has shown to be fast enough and scalable enough for the highest traffic loads, so supporting other DBs would not improve the WordPress experience or our popularity much. As a feature request it comes up fairly infrequently.
All that said, every query in WordPress goes through a class called wpdb and that class can be replaced with your own by putting a db.php file in wp-content. So far this has been used for mysqli support and an advanced enterprise DB class called HyperDB, but in theory you could use that, and some wicked regular expressions, to add support for a MySQL-like database without any core code modifications.
Functions are listed in Function Reference and Category:Functions.
Hooks are provided at http://wphooks.flatearth.org
A complete overview of all documented code can be found at PHPXref.com