Fix broken links.
Signed-off-by: Wayne Beaton <wayne.beaton@eclipse-foundation.org>
diff --git a/source/chapters/ip.adoc b/source/chapters/ip.adoc
index 20be954..3ded375 100644
--- a/source/chapters/ip.adoc
+++ b/source/chapters/ip.adoc
@@ -85,7 +85,7 @@
{clearlyDefinedUrl}[ClearlyDefined] is an OSI project that combines automated harvesting of software repositories and curation by trusted members of the community to produce a massive database of license (and other) information about content. The Eclipse Foundation's IP Team works closely with the ClearlyDefined team, providing input into their processes and helping to curate their data.
-In rough terms, if the license information for third-party content can be validated by the Eclipse Foundation's <<ip-prereq-due-diligence, due diligence process>> using ClearlyDefined data, then no further action is required (i.e., no <<ip-cq,CQ>> is required).
+In rough terms, if the license information for third-party content can be validated by the Eclipse Foundation's <<ip-prereq-diligence, due diligence process>> using ClearlyDefined data, then no further action is required (i.e., no <<ip-cq,CQ>> is required).
[[ip-clearlydefined-identifiers]]
==== ClearlyDefined Identifiers
@@ -223,7 +223,7 @@
* Contains no cryptography; and
* Is it less than 1,000 lines of code, configuration files, and other forms of source code.
-If all of these conditions have **not** been met, then a project committer must <<ip-project-code-cq, open a CQ>> to request review by the IP Team before the contribution is pushed/merged.
+If all of these conditions have **not** been met, then a project committer must <<ip-project-content-cq, open a CQ>> to request review by the IP Team before the contribution is pushed/merged.
[TIP]
====
diff --git a/source/chapters/specifications.adoc b/source/chapters/specifications.adoc
index 6283683..d021c07 100644
--- a/source/chapters/specifications.adoc
+++ b/source/chapters/specifications.adoc
@@ -116,7 +116,7 @@
[NOTE]
====
-If you are already a committer, your committer agreement includes an ECA; so you’re already covered. If your employer is a member of the Eclipse Foundation and your employer has signed the <<contributing-mcca,Member Committer and Contributor Agreement>> (MCCA), then you’re already covered. You can check your status on the <<contributing-account, Eclipse Foundation account>> page (your ECA status is in the top-right corner). If you’re not sure contact mailto:{emoRecordsEmail}[EMO Records] for assistance.
+If you are already a committer, your committer agreement includes an ECA; so you’re already covered. If your employer is a member of the Eclipse Foundation and your employer has signed the <<paperwork-mcca,Member Committer and Contributor Agreement>> (MCCA), then you’re already covered. You can check your status on the <<contributing-account, Eclipse Foundation account>> page (your ECA status is in the top-right corner). If you’re not sure contact mailto:{emoRecordsEmail}[EMO Records] for assistance.
====
Regular contributors of high quality content shoul be invited to join the specification project team as a committer (via <<elections-committer, committer election>>).
@@ -262,7 +262,7 @@
A milestone build must never be used to claim compatibility with a specification. An implementation of a specification may only be considered _compatible_ when it is based on a <<specifications-final,_final specification_>>.
====
-A development cycle begins when a either a creation review or a <<specifications-plan,plan review>> is declared successful. A specification project team must engage in a <<specifications-progress,_progress review_>> when a development cycle exceeds one year in duration.
+A development cycle begins when a either a creation review or a <<specifications-plan-review,plan review>> is declared successful. A specification project team must engage in a <<specifications-progress-review,_progress review_>> when a development cycle exceeds one year in duration.
[[specifications-progress-review]]
=== Progress Review
@@ -283,7 +283,7 @@
[TIP]
====
-To engage in a release review, create a <<pmi-release, release record>> (if one has not already been created as part of the planning process) and contact the mailto:{emoEmail}[EMO] to schedule the review. Your PMC and specification committee may provide additional requirements and documentation that must be met to get their approval of the review.
+To engage in a release review, create a <<pmi-releases, release record>> (if one has not already been created as part of the planning process) and contact the mailto:{emoEmail}[EMO] to schedule the review. Your PMC and specification committee may provide additional requirements and documentation that must be met to get their approval of the review.
====
[[specifications-plan-review]]
@@ -295,7 +295,7 @@
[TIP]
====
-To engage in a plan review, create a <<pmi-release, release record>> and contact the mailto:{emoEmail}[EMO] to schedule a review.
+To engage in a plan review, create a <<pmi-releases, release record>> and contact the mailto:{emoEmail}[EMO] to schedule a review.
====
After the Plan is approved, the Project Team engages in Development as before.
@@ -303,7 +303,7 @@
[[specifications-final]]
=== Final Specification
-Following a successful release review, the final release version of the specification artifacts are considered _ratified_ and transmogrifies into what the EFSP refers to as a _final specification_. It is the final specification that must be used to build <<specifications-implementation,compatible implementations>>.
+Following a successful release review, the final release version of the specification artifacts are considered _ratified_ and transmogrifies into what the EFSP refers to as a _final specification_. It is the final specification that must be used to build <<specifications-implementations,compatible implementations>>.
All versions of specifications that are referenced by a ratified final specification must themselves be ratified. The <<specifications-release-review,release review>> for related specification versions may be run concurrently.
diff --git a/source/chapters/trademarks.adoc b/source/chapters/trademarks.adoc
index 95d23a2..ddd9365 100644
--- a/source/chapters/trademarks.adoc
+++ b/source/chapters/trademarks.adoc
@@ -29,7 +29,7 @@
The brand that is associated with a particular project is used on the corresponding <<pmi-project-page, project page>>.
====
-The <<trademarks-formal-name,formal name>> of all {forgeName} open source projects starts with a brand. The brand should not generally be concatenated with any other words (there are some historical exceptions).
+The <<trademarks-project-formal,formal name>> of all {forgeName} open source projects starts with a brand. The brand should not generally be concatenated with any other words (there are some historical exceptions).
[[trademarks-background]]
=== Naming and Trademarks
@@ -53,6 +53,7 @@
All project and product names must be vetted and approved by the EMO.
+[[trademarks-registered]]
==== Registered Trademarks
Project teams may request legal trademark registration for their project or product name. Since trademark registration requires a significant investment in time money and ongoing maintenance project teams must work with the EMO to determine whether trademark registration is necessary, determine in which jurisdictions the trademark must be registered, and how that registration will impact the project (e.g. adding registration marks on the website and in products).
@@ -201,7 +202,7 @@
[[trademarks-website-name]]
==== Name References
-The first reference to a project or product on every web page--especially in page titles or headers--must use the <<trademarks-formal-name,formal name>> and must include the relevant trademark (™) or registered trademark (®) symbol (e.g. _{forgeName} Woolsey Intellectual Property Tools™_). When a webpage features an otherwise prominent reference to the project or product (e.g. in a callout), that reference should also use the formal name. Other references may use the nickname or acronym (e.g. _{forgeName} Woolsey_ or _Woolsey_) as appropriate.
+The first reference to a project or product on every web page--especially in page titles or headers--must use the <<trademarks-project-formal,formal name>> and must include the relevant trademark (™) or registered trademark (®) symbol (e.g. _{forgeName} Woolsey Intellectual Property Tools™_). When a webpage features an otherwise prominent reference to the project or product (e.g. in a callout), that reference should also use the formal name. Other references may use the nickname or acronym (e.g. _{forgeName} Woolsey_ or _Woolsey_) as appropriate.
[[trademarks-website-footer]]
==== Footers
