+Welcome to the OpenOCD Reference Manual -- the developer's resource for
+learning about the internal architecture of the OpenOCD project. @par
+
+In addition, this document contains the tactical and strategic plans
+and processes that have been developed by and for the OpenOCD community.
+
+Developers that want to contribute to OpenOCD should read the following
+sections before starting work:
+
+- The List of @subpage thelist enumerates opportunities for improving or
+extending the OpenOCD platform. If your ideas are on The List, you might
+check the mailing list archives to find the status of your feature (or bug).
+- The @subpage styleguide provides rules that developers should
+ follow when writing new code for OpenOCD.
+- The @subpage patchguide provides policies that developers should
+ follow when submitting patches to the project.
+- The @subpage bugs page contains the content of the BUGS file, which
+ provides instructions for submitting bug reports to the maintainers.
+- The @subpage releases page describes the project's release process.
+
+@ref primer provide introductory materials for new developers on various
+specific topics.
+
+Finally, the @ref oocd pages explain how the code has been organized
+into layers of APIs, providing an overview of how they fit together.
+These pages attempt to give developers a high-level perspective of the
+various code modules provided by OpenOCD.
+
+ */
+
+/** @page primer OpenOCD Technical Primers
+
+This pages lists Technical Primers available for OpenOCD Developers.
+They seek to provide information to pull novices up the learning curves
+associated with the fundamental technologies used by OpenOCD.
+
+- @subpage primerpatches
+- @subpage primerdocs
+- @subpage primerautotools
+- @subpage primertcl
+- @subpage primerjtag
+
+These documents should bridge any "ancillary" gaps in contributor
+knowledge, without having to learn the complete languages or technology.
+They should provide enough information for experienced developers to
+learn how to make "correct" changes when creating patches.
+
+In all cases, these Primers should use idiomatic conventions that the
+community has agreed are the "right way of doing things". In this
+respect, these documents typically assume some familiarity with the
+information contained in one or more @ref styleguide, or they will
+directly refer to specific style guides as supplemental reading.
+
+Contributions or suggestions for new Technical Primers are welcome.