Consistency pass. Update to newer Asciidoc constructs.

2 files changed, 208 insertions, 554 deletions

diff --git a/source/chapters/ip.adoc b/source/chapters/ip.adoc
index 987142c..d57eda2 100644
--- a/source/chapters/ip.adoc
+++ b/source/chapters/ip.adoc
@@ -1,102 +1,67 @@
 [[ip]]
 == Intellectual Property
 
-{forgeName} projects are expected to take necessary precautions to mitigate
-intellectual property (IP) risk to adopters. A company that integrates the code 
-from your project, for example, does so with confidence that the code in the 
-project can legally be distributed under the agreed-to terms. The 
-{ipDueDiligenceUrl}[IP Due Diligence Process], managed by the Eclipse IP Team 
-(commonly referred to as the 'IP Team'), is in place to support this. 
+{forgeName} projects are expected to take necessary precautions to mitigate intellectual property (IP) risk to adopters. A company that integrates the code from your project, for example, does so with confidence that the code in the project can legally be distributed under the agreed-to terms. The {ipDueDiligenceUrl}[IP Due Diligence Process], managed by the Eclipse IP Team (commonly referred to as the _IP Team_), is in place to support this. 
 
-All {forgeName} committers must be familiar with the {ipPolicyUrl}[Eclipse IP 
-Policy].
+All {forgeName} committers must be familiar with the {ipPolicyUrl}[Eclipse IP Policy].
 
 [[ip-initial-contribution]]
 === Initial Contribution
-Code provenance tracking is critical (we need to know the source of all code
-that ends up in our repositories). To that end, all new projects are required to 
-make an 'initial contribution' before *any* code is committed to a project's 
-source code repository.
-
-The IP Team will review your initial contribution to ensure that the code can 
-distributed through {aForgeName} property. The IP Team will review the code to 
-make sure that it hasn't been copied inappropriately, that licenses are being 
-used correctly, and so forth. As part of this process, the IP Team  will 
-research the source of all code; depending on the size of the contribution, this 
-can be a time-consuming process.
-
-NOTE: A project cannot make a <<release, release>> until the due diligence on 
-the IP contained in that release--including project code contributions and 
-third-party libraries--is complete. 
-
-Create a <<ip-cq,contribution questionnaire>> to submit the initial contribution 
-for review by the IP Team.
-
-The IP Team is not able to review the history of project code being moved to 
-{aForgeName} project. The IP Team will review a snapshot of the project code and 
-that snapshot, the 'initial contribution', must be the first commit in the 
-{forgeName} repository. If your project uses an existing GitHub repository, the
-Webmaster team will help you obscure the the history into a hidden branch. 
+Code provenance tracking is critical (we need to know the source of all code that ends up in our repositories). To that end, all new projects are required to make an _initial contribution_ before *any* code is committed to a project's source code repository.
+
+The IP Team will review your initial contribution to ensure that the code can distributed through {aForgeName} property. The IP Team will review the code to make sure that it hasn't been copied inappropriately, that licenses are being used correctly, and so forth. As part of this process, the IP Team  will research the source of all code; depending on the size of the contribution, this can be a time-consuming process.
+
+[NOTE]
+====
+A project cannot make a <<release, release>> until the due diligence on the IP contained in that release--including project code contributions and third-party libraries--is complete. 
+====
+
+Create a <<ip-cq,contribution questionnaire>> to submit the initial contribution for review by the IP Team.
+
+The IP Team is not able to review the history of project code being moved to {aForgeName} project. The IP Team will review a snapshot of the project code and that snapshot, the initial contribution, must be the first commit in the {forgeName} repository. If your project uses an existing GitHub repository, the Webmaster team will help you obscure the the history into a hidden branch. 
 
 [[ip-project-code]]
 === Project Code Contributions
 
-Some contributions of code to maintained by the project (i.e. committed to a
-project source code repository and maintained by the project team) must be
-reviewed by the IP Team. The {ipDueDiligenceUrl}[IP Due Diligence Process]
-provides help to determine whether or not the contribution needs to be reviewed
-by the IP Team. If you're not sure, ask your project mentors or your PMC for
-assistance.
+Some contributions of code to maintained by the project (i.e. committed to a project source code repository and maintained by the project team) must be reviewed by the IP Team. The {ipDueDiligenceUrl}[IP Due Diligence Process] provides help to determine whether or not the contribution needs to be reviewed by the IP Team. If you're not sure, ask your project mentors or your PMC for assistance.
 
-All contributions of project code must be tracked in the project's 
-<<ip-iplog,IP Log>>.
+All contributions of project code must be tracked in the project's <<ip-iplog,IP Log>>.
 
-Create a <<ip-cq,contribution questionnaire>> to submit a project code 
-contribution for review by the IP Team.
+Create a <<ip-cq,contribution questionnaire>> to submit a project code contribution for review by the IP Team.
 
 [[ip-third-party]]
 === Third-Party Libraries
 
-All third-party libraries required by project code will have to be checked 
-and approved by the IP Team. 
+All third-party libraries required by project code will have to be checked and approved by the IP Team. 
 
 The IP Team must review a third-party library if:
 
-* the Java/OSGi manifest for one of the project bundles makes a 
-direct reference to a third-party library (either the library bundle 
-or a package from the library);
-* project code includes an import statement for a package from a 
-third-party library;
-* project code uses reflection or other means to reference a 
-library's APIs and implementation;
-* project code uses OSGi Services to make a reference to a 
-specific implementation of a service; or
+* the Java/OSGi manifest for one of the project bundles makes a direct reference to a third-party library (either the library bundle or a package from the library);
+* project code includes an import statement for a package from a third-party library;
+* project code uses reflection or other means to reference a library's APIs and implementation;
+* project code uses OSGi Services to make a reference to a specific implementation of a service; or
 * project code invokes a "command line" tool.
 
 This list is not intended to be exhaustive. 
 
-The {ipThirdParty}[Guidelines for the Review of Third Party Dependencies] can help
-you determine how to classify your third-party libraries.
+The {ipThirdParty}[Guidelines for the Review of Third Party Dependencies] can help you determine how to classify your third-party libraries.
 
-NOTE: A project cannot make a <<release, release>> until the due diligence on 
-the IP contained in that release--including project code contributions and 
-third-party libraries--is complete. 
+[NOTE]
+====
+A project cannot make a <<release, release>> until the due diligence on the IP contained in that release--including project code contributions and third-party libraries--is complete. 
+====
 
-Create a <<ip-cq,contribution questionnaire>> to submit a third-party
-library for review by the IP Team.
+Create a <<ip-cq,contribution questionnaire>> to submit a third-party library for review by the IP Team.
 
 [[ip-ownership]]
 === Ownership
 
-The author of a contribution (or their employer) retains ownership of the
-intellectual property contained in the contribution. As part of the contribution
-process, the contributor licenses their contribution under the project license.
+The author of a contribution (or their employer) retains ownership of the intellectual property contained in the contribution. As part of the contribution process, the contributor licenses their contribution under the project license.
 
 [[ip-copyright-headers]]
 === Copyright and License Headers
 
-All source files must include a file header that describes the copyright and
-license terms of the software.
+All source files must include a file header that describes the copyright and license terms of the software.
 
 .Example Copyright and License Header
 -----------------------------------------------------------------
@@ -116,148 +81,88 @@ If other organizations have contributed, include "and others".
 <2> List project licenses.
 <3> Optionally list the names of the contributors and the nature of their contribution.
 
-Your project is not a legal entity and so it is inappropriate to list it as
-the copyright owner.
+Your project is not a legal entity and so it is inappropriate to list it as the copyright owner.
 
-WARNING: The copyright owner is either an individual or their employer. Most
-employment contracts stipulate that the intellectual property creations of an
-employee are the property of the employer and so the employer should generally
-be listed as the copyright owner.
+[WARNING]
+====
+The copyright owner is either an individual or their employer. Most employment contracts stipulate that the intellectual property creations of an employee are the property of the employer and so the employer should generally be listed as the copyright owner.
+====
 
 For more information please see the {copyrightUrl}[Default Eclipse Foundation Copyright and License Notice].
 
 [[ip-licensing]] 
 === Licensing
 
-{forgeName} top level projects define the standard licensing for their
-projectsd. If your project has non standard licensing requirements,
-you may need to make a presentation to the Eclipse board of directors 
-to request their approval. The presentation need only briefly describe 
-the project and why special licensing considerations are necessary.
+{forgeName} top level projects define the standard licensing for their projects. If your project has non standard licensing requirements, you may need to make a presentation to the Eclipse board of directors to request their approval. The presentation need only briefly describe the project and why special licensing considerations are necessary.
 
 [[ip-ipzilla]]
 === IPZilla
 
-{ipzillaUrl}[IPZilla] is a modified instance of Bugzilla that tracks the progress 
-of the intellectual property due diligence review and approval process. 
-It is the main interaction point between committers and the
-Eclipse Foundation's Intellectual Property (IP) Team. You can review 
-both completed and ongoing reviews via IPZilla. 
+{ipzillaUrl}[IPZilla] is a modified instance of Bugzilla that tracks the progress of the intellectual property due diligence review and approval process. It is the main interaction point between committers and the Eclipse Foundation's Intellectual Property (IP) Team. You can review both completed and ongoing reviews via IPZilla. 
 
-NOTE: IPZilla is accessible only by committers, Eclipse Foundation 
-member company representatives, and other specifically-designated individuals.
+[NOTE]
+====
+IPZilla is accessible only by committers, Eclipse Foundation member company representatives, and other specifically-designated individuals.
+====
 
 [[ip-cq]]
 ==== Contribution Questionnaires
 
-A Contribution Questionnaires (CQ) is the main interface 
-between {forgeName} committers and the IP Team.
+A Contribution Questionnaires (CQ) is the main interface between {forgeName} committers and the IP Team.
 
-A CQ is started when a committer completes a 'questionnaire' regarding
-a contribution or third-party library. In literal terms, a CQ is a 
-record in 'IPZilla', that tracks the progress of the approval process. 
-The CQ record is the primary communication channel between the submitting 
-committer and the IP Team. CQ records persist indefinitely.
+A CQ is started when a committer completes a _questionnaire_ regarding a contribution or third-party library. In literal terms, a CQ is a  record in _IPZilla+, that tracks the progress of the approval process. The CQ record is the primary communication channel between the submitting committer and the IP Team. CQ records persist indefinitely.
 
-All significant contributions of code to be maintained by {aForgeName} project, as 
-defined by the Eclipse IP Due Diligence Process require a CQ.
+All significant contributions of code to be maintained by {aForgeName} project, as defined by the Eclipse IP Due Diligence Process require a CQ.
 
-Projects require a CQ for every third-party library that project 
-code makes direct use of (regardless of whether or not the library 
-is directly distributed by the project. If your code makes indirect 
-use of a third party library through another {forgeName}
-project's code, you do not require a CQ for that library.
+Projects require a CQ for every third-party library that project code makes direct use of (regardless of whether or not the library is directly distributed by the project. If your code makes indirect use of a third party library through another {forgeName} project's code, you do not require a CQ for that library.
 
-NOTE: CQs for third-party libraries are 'version-specific'. That is, 
-a separate CQ is required for different versions of the same library.
+[NOTE]
+====
+CQs for third-party libraries are _version-specific_. That is, a separate CQ is required for different versions of the same library.
+====
 
-CQs are not generally required for ongoing work done by project
-committers. Consult the IP Due Diligence Process document for 
-more information.
+CQs are not generally required for ongoing work done by project committers. Consult the IP Due Diligence Process document for more information.
 
 [[ip-parallel-ip]]
 ==== Parallel IP
 
-The 'Parallel IP Process' allows {forgeName} projects to make use of
-project code contributions and third-party libraries before they
-are fully approved by the IP Team. In practical terms, the Parallel
-IP Process permits--with preliminary approval from the IP Team--a 
-project to check-in code contributions into their source code
-repository and run builds against third-party libraries 
-without having to wait for the full IP Due Diligence Process to
-compete.
-
-NOTE: There is some risk associated with the Parallel IP Process.
-The IP Team will grant preliminary approval based on a cursory
-review of the contribution; but during their full review, they may
-uncover issues that require mitigation. This may require, for
-example, that some parts of a contribution be removed completely
-(history and all) from a source code repository.
-
-Parallel IP manifests in two different ways: projects in the 
-'incubation phase' may leverage the Parallel IP process for 
-project code and third-party libraries. 'Mature phase' projects 
-may leverage parallel IP for new versions of third-party libraries 
-for which previous versions have already been approved.
-
-To leverage the Parallel IP Process, projects still submit CQ. 
-The difference is that once a CQ has been reviewed for 
-license compatibility, the project will be authorized via IPzilla 
-to check-in the code start working on it.
+The _Parallel IP Process_ allows {forgeName} projects to make use of project code contributions and third-party libraries before they are fully approved by the IP Team. In practical terms, the Parallel IP Process permits--with preliminary approval from the IP Team--a project to check-in code contributions into their source code repository and run builds against third-party libraries without having to wait for the full IP Due Diligence Process to compete.
+
+[NOTE]
+====
+There is some risk associated with the Parallel IP Process. The IP Team will grant preliminary approval based on a cursory review of the contribution; but during their full review, they may uncover issues that require mitigation. This may require, for example, that some parts of a contribution be removed completely (history and all) from a source code repository.
+====
+
+Parallel IP manifests in two different ways: projects in the _incubation phase_ may leverage the Parallel IP process for project code and third-party libraries. _Mature phase_ projects may leverage parallel IP for new versions of third-party libraries for which previous versions have already been approved.
+
+To leverage the Parallel IP Process, projects still submit CQ. The difference is that once a CQ has been reviewed for license compatibility, the project will be authorized via IPzilla to check-in the code start working on it.
 
 All IP must be fully approved before it is included in a release.
 
 [[ip-piggyback]]
 ==== Piggyback CQs
 
-Many third party libraries have already been approved for use in {forgeName} projects. 
-Many of those are immediately available via the http://www.eclipse.org/orbit[Orbit Project]. 
-While these libraries have already been cleared for use by all projects, 
-their use must be tracked. Usage is tracked so that--in the event that a issue is uncovered 
-following the due diligence process--we can mitigate the impact of that issue.
+Many third party libraries have already been approved for use in {forgeName} projects. Many of those are immediately available via the http://www.eclipse.org/orbit[Orbit Project]. While these libraries have already been cleared for use by all projects, their use must be tracked. Usage is tracked so that--in the event that a issue is uncovered following the due diligence process--we can mitigate the impact of that issue.
 
-In this case, a 'piggyback CQ' can be created on top of an existing CQ. Piggyback CQs 
-are generally approved very quickly as the due diligence work has already been completed.
+In this case, a _piggyback CQ_ can be created on top of an existing CQ. Piggyback CQs are generally approved very quickly as the due diligence work has already been completed.
 
 [[ip-cq-workflow]]
 ==== CQ Workflow
 
-The workflow for creating a CQ for a third-party library starts with a search of existing 
-CQs. If an existing CQ can be found that is concerned with the same library and version, 
-then a piggyback CQ is created. Piggyback CQs must be approved by the project's Project 
-Management Committee (PMC) before they are processed by the EMO IP Team.
+The workflow for creating a CQ for a third-party library starts with a search of existing CQs. If an existing CQ can be found that is concerned with the same library and version, then a piggyback CQ is created. Piggyback CQs must be approved by the project's Project Management Committee (PMC) before they are processed by the EMO IP Team.
 
-If an existing CQ cannot be found, a new one must be created. Once created, the source 
-code for the third-party library must be attached to the record. The PMC must then approve 
-the record. If the project is eligible to leverage the Parallel IP Process, the IP 
-Team performs a cursory review of the record and--if the CQ meets with the 
-requirements--tentatively approves the use of the library while the full review is 
-undertaken in parallel.
+If an existing CQ cannot be found, a new one must be created. Once created, the source code for the third-party library must be attached to the record. The PMC must then approve the record. If the project is eligible to leverage the Parallel IP Process, the IP Team performs a cursory review of the record and--if the CQ meets with the requirements--tentatively approves the use of the library while the full review is undertaken in parallel.
 
-The IP team may require your assistance as it performs a deep analysis of the library. 
-Once that analysis is complete and the IP team has made a decision, they will outline 
-the next steps. These next steps may--in the event that the library is rejected--that 
-the library be removed from the project VCS, or that some part be removed. Most often, 
-the library is approved and the CQ is marked as such.
+The IP team may require your assistance as it performs a deep analysis of the library. Once that analysis is complete and the IP team has made a decision, they will outline the next steps. These next steps may--in the event that the library is rejected--that the library be removed from the project VCS, or that some part be removed. Most often, the library is approved and the CQ is marked as such.
 
-Be advised that this process may take a while. The actual amount of time that it takes 
-to process a CQ depends on numerous factors including the size of the queue, and the 
-nature and size of the contribution.
+Be advised that this process may take a while. The actual amount of time that it takes to process a CQ depends on numerous factors including the size of the queue, and the nature and size of the contribution.
 
 [[ip-iplog]]
 === IP Logs
 
-An IP Log is a record of the intellectual property contributions to a project. 
-This includes such as a list of all committers, past and present, that have 
-worked on the code and (especially) those who have made contributions to 
-the current code base.
+An IP Log is a record of the intellectual property contributions to a project. This includes such as a list of all committers, past and present, that have worked on the code and (especially) those who have made contributions to the current code base.
 
-The IP Log is a big part of the official <<release, release cycle>>. You are required to 
-submit your project's IP Log prior to scheduling a release, or restructuring 
-review. We encourage you to keep your IP log current rather than rushing at the 
-end. The IP Log includes important information about your project that lets 
-adopters know where all the code comes from, who owns the copyrights, and so 
-forth. 
+The IP Log is a big part of the official <<release, release cycle>>. You are required to submit your project's IP Log prior to scheduling a release, or restructuring review. We encourage you to keep your IP log current rather than rushing at the end. The IP Log includes important information about your project that lets adopters know where all the code comes from, who owns the copyrights, and so forth. 
 
 Specifically, the log tracks:
 
@@ -269,10 +174,7 @@ Specifically, the log tracks:
 [[ip-iplog-generator]]
 ==== IP Log Generator
 
-The Automated IP Log Tool automatically generates an IP Log using information 
-that is available to the Eclipse Foundation. The list of committers, for 
-example is generated using information provided by the Dash project which itself 
-pulls information out of source code repositories.
+The Automated IP Log Tool automatically generates an IP Log using information that is available to the Eclipse Foundation. The list of committers, for example is generated using information provided by the Dash project which itself pulls information out of source code repositories.
 
 The IP Log generator pulls information from multiple location to assemble the log:
 
@@ -312,10 +214,8 @@ digraph {
 * Third-party libraries used by the project come from _IPZilla_;
 * The _Dash_ process scans the project source code repositories to assess committer activity;
 * _Dash_ also scans Git repositories for contributions;
-** If you follow the guidelines for handling Git contributions, contributions received via 
-Git in any branch will automatically appear in the log
-* Contributions received as patches in _Bugzilla_ that are marked +pass:[iplog+]+ 
-will automatically appear in the log; and
+** If you follow the guidelines for handling Git contributions, contributions received via Git in any branch will automatically appear in the log
+* Contributions received as patches in _Bugzilla_ that are marked +pass:[iplog+]+ will automatically appear in the log; and
 * License information is obtained from the _Foundation_ database
 
 To fully leverage the value of the Automated IP Log Tool, you need to:
@@ -325,79 +225,43 @@ To fully leverage the value of the Automated IP Log Tool, you need to:
 * Mark IP Contributions in Bugzilla; and
 * Create <<ip-cq,contribution questionnaires>> (CQs) where appropriate
 
-WARNING: Contributions should be recorded in _one of_ Git or Bugzilla, not both.
-Setting the _Author_ credentials on Git commits is the preferred mechanism. 
-The IP Log generator is not smart enough to detect duplicate entries.
-
-Your project's metadata is used to determine the identities of the source code 
-repositories that Dash needs to scan to find out committer information. Specifically, 
-you need to specify, in the _Source Repositories_ section, a list of paths to source code 
-repository locations. 
-
-The Automated IP Log tool populates the _Contributors_ section with information gathered 
-from Git and Bugzilla. This section lists contributions from non-committers (this is 
-time-sensitive, so contributions made by current committers before they became 
-committers will also be included). Only non-committer contributions are recorded in 
-the generated log. 
-
-<<resources-commit,Git commits>> contributed by non-committers are identified by
-the author credentials on the commit record; the _Author_ field must be set to the identity 
-of the actual author of the commit.
-
-Alternatively, Bugzilla attachments can be marked with the +pass:[iplog+]+ flag. 
-This flag setting indicates that the person who attached  the bug is the contributor. 
-To comply with the website terms of use, the person who attaches 
-the contribution *must* be the person who has permission to make it available. 
-You should ensure that this is the case before including the code in your project's 
-repository and flagging the entry.
-
-You can also flag an entire Bugzilla entry with +pass:[iplog+]+. Doing so, 
-however, indicates to the Automated IP Log tool that every single comment made by a non-committer 
-in the bug report represents a potential contribution. For your own sanity, it's a good practice 
-to ask contributors to provide and attach patches that can be individually marked. Marking an 
-entire bug represents an ongoing maintenance issue as new comments added to the bug from 
-non-committers will show up in the generated log.
-
-That contributions flagged in Bugzilla will only appear in the IP Log if the bug is marked 
-+FIXED+ or +CLOSED+.
-
-The Third-Party Software section of the log is populated from IPZilla. The IP Team 
-will mark your contributions in such a way that they will appear in 
-the log. If third party software is not appearing properly, contact the 
-mailto:{ipTeamEmail}[EMO IP Team] to make corrections.
+[WARNING]
+====
+Contributions should be recorded in _one of_ Git or Bugzilla, not both. Setting the _Author_ credentials on Git commits is the preferred mechanism. The IP Log generator is not smart enough to detect duplicate entries.
+====
+
+Your project's metadata is used to determine the identities of the source code repositories that Dash needs to scan to find out committer information. Specifically, you need to specify, in the _Source Repositories_ section, a list of paths to source code repository locations. 
+
+The Automated IP Log tool populates the _Contributors_ section with information gathered from Git and Bugzilla. This section lists contributions from non-committers (this is time-sensitive, so contributions made by current committers before they became committers will also be included). Only non-committer contributions are recorded in the generated log. 
+
+<<resources-commit,Git commits>> contributed by non-committers are identified by the author credentials on the commit record; the _Author_ field must be set to the identity of the actual author of the commit.
+
+Alternatively, Bugzilla attachments can be marked with the +pass:[iplog+]+ flag. This flag setting indicates that the person who attached  the bug is the contributor. To comply with the website terms of use, the person who attaches the contribution *must* be the person who has permission to make it available. You should ensure that this is the case before including the code in your project's repository and flagging the entry.
+
+You can also flag an entire Bugzilla entry with +pass:[iplog+]+. Doing so, however, indicates to the Automated IP Log tool that every single comment made by a non-committer in the bug report represents a potential contribution. For your own sanity, it's a good practice to ask contributors to provide and attach patches that can be individually marked. Marking an entire bug represents an ongoing maintenance issue as new comments added to the bug from non-committers will show up in the generated log.
+
+That contributions flagged in Bugzilla will only appear in the IP Log if the bug is marked +FIXED+ or +CLOSED+.
+
+The Third-Party Software section of the log is populated from IPZilla. The IP Team will mark your contributions in such a way that they will appear in the log. If third party software is not appearing properly, contact the mailto:{ipTeamEmail}[EMO IP Team] to make corrections.
 
 [[ip-faq]]
 === Frequently Asked Questions
 
 [qanda]
 Do we really need to do this? ::
-	Yes.
+Yes.
 	
 What do you do with the IP Log? ::
-	IP Log reviews occur in two stages. In the first stage, the EMO performs
-	a technical assessment to make sure that the artifacts produced by the
-	project are properly accounted for in the IP log. You may be asked to
-	assist with the resolution of any discrepancies found during this assessment.
-	In the second stage, the IP Team reviews the log to ensure that 
-	it matches their records. The IP log review concludes with approval by the IP Team.
+IP Log reviews occur in two stages. In the first stage, the EMO performs a technical assessment to make sure that the artifacts produced by the project are properly accounted for in the IP log. You may be asked to assist with the resolution of any discrepancies found during this assessment. In the second stage, the IP Team reviews the log to ensure that it matches their records. The IP log review concludes with approval by the IP Team.
 
 When should I submit the IP Log for review? ::
-	The IP Log should be submitted for review by the IP Team two weeks before the planned
-	end date for a release review or (if code moves are involved) a restructuring review. 
-	Note that the date of your review may be different from the date of the actual release.
+The IP Log should be submitted for review by the IP Team two weeks before the planned end date for a release review or (if code moves are involved) a restructuring review. Note that the date of your review may be different from the date of the actual release.
 	
 We submitted an IP Log for our release, but we've made some changes since then that will end up in the release, should we resubmit the IP Log? ::
-
 The purpose of the IP Log review is to checkpoint the IP Due Diligence Process and ensure that nothing is slipping through the cracks; an IP Log is not intended to be an accurate reflection of exactly what is in any particular release.
 
 Are there other reasons to submit the IP Log for review? ::
-	Generally no. If the IP Team requires an IP Log review outside of the context of
-	a release or restructuring review, they'll ask for it. It is not generally necessary
-	to submit an IP Log for review outside of the context of a review. 
-	It is, however, good practice to do your own review of the generated 
-	IP Log periodically to make	sure that it accurately reflects the state of the project.
+Generally no. If the IP Team requires an IP Log review outside of the context of a release or restructuring review, they'll ask for it. It is not generally necessary to submit an IP Log for review outside of the context of a review. It is, however, good practice to do your own review of the generated IP Log periodically to make	sure that it accurately reflects the state of the project.
 	
 How do I fix problems with the generated IP Log? ::
-	The IP Log is generated based on data from Eclipse Foundation servers. If the log
-	is being generated incorrectly, then the underlying data needs to be fixed. If
-	you spot a problem, send a note to {emoEmail}.
\ No newline at end of file
+The IP Log is generated based on data from Eclipse Foundation servers. If the log is being generated incorrectly, then the underlying data needs to be fixed. If you spot a problem, send a note to {emoEmail}.
\ No newline at end of file
diff --git a/source/chapters/trademarks.adoc b/source/chapters/trademarks.adoc
index ee13691..4ce5bbf 100644
--- a/source/chapters/trademarks.adoc
+++ b/source/chapters/trademarks.adoc
@@ -1,51 +1,20 @@
 [[trademarks]]
 == Branding
 
-This section defines how {forgeName} Projects
-must use and display all Eclipse Foundation trademarks as well as how
-they showcase their project's website within the community and
-ecosystem. The requirements described here are a complement to the
-{trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks], 
-targeting {forgeName} open source project
-leads and committers specifically.
-
-These requirements are meant to promote and improve the image of all
-projects that are part of the {forgeName} community, as well as to show that
-all {forgeName} Projects are part of our community of developers, adopters
-and users that we believe is an important factor in our mutual success.
-While every project manages their own development within the broader
-{edpUrl}[Eclipse
-Development Process], a consistent public branding and web presence that
-ties all of our projects together benefits all of us.
-
-All projects must conform to these branding requirements before engaging
-in any Release or Graduation Review.
+This section defines how {forgeName} Projects must use and display all Eclipse Foundation trademarks as well as how they showcase their project's website within the community and ecosystem. The requirements described here are a complement to the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks], targeting {forgeName} open source project leads and committers specifically.
+
+These requirements are meant to promote and improve the image of all projects that are part of the {forgeName} community, as well as to show that all {forgeName} Projects are part of our community of developers, adopters and users that we believe is an important factor in our mutual success. While every project manages their own development within the broader {edpUrl}[Eclipse Development Process], a consistent public branding and web presence that ties all of our projects together benefits all of us.
+
+All projects must conform to these branding requirements before engaging in any Release or Graduation Review.
 
 [[trademarks-background]]
 === Naming, Branding, and Trademarks
 
-Naming and branding are important issues for project teams to consider:
-both for the project's future success as well as to help support and
-share the good values from the {forgeName} brand itself. Not only can a
-memorable name help new users and contributors find a project, having a
-distinctive name makes the trademark much stronger, and ensures that
-third parties will respect it.
-
-To ensure that future trademarks conflicts don't arise, it is necessary
-to show other parties that Eclipse Foundation trademarks were chosen in
-good faith and with appropriate research. The Eclipse Foundation has
-no business infringing on
-pre-existing trademarks for the software products or services from other
-organizations, whether they are Member organizations or not.
-
-All {forgeName} projects and corresponding software products are trademarks
-of the Eclipse Foundation. As a legal entity, the Eclipse Foundation
-owns all {forgeName} project and corresponding product trademarks on behalf
-of the the {forgeName} community. The EMO will
-initiate a trademark review as part of the project creation or renaming
-process. Existing project name trademarks must be transferred to the
-Eclipse Foundation (please see the
-{trademarkTransferUrl}[Trademark Transfer Agreement]).
+Naming and branding are important issues for project teams to consider: both for the project's future success as well as to help support and share the good values from the {forgeName} brand itself. Not only can a memorable name help new users and contributors find a project, having a distinctive name makes the trademark much stronger, and ensures that third parties will respect it.
+
+To ensure that future trademarks conflicts don't arise, it is necessary to show other parties that Eclipse Foundation trademarks were chosen in good faith and with appropriate research. The Eclipse Foundation has no business infringing on pre-existing trademarks for the software products or services from other organizations, whether they are Member organizations or not.
+
+All {forgeName} projects and corresponding software products are trademarks of the Eclipse Foundation. As a legal entity, the Eclipse Foundation owns all {forgeName} project and corresponding product trademarks on behalf of the the {forgeName} community. The EMO will initiate a trademark review as part of the project creation or renaming process. Existing project name trademarks must be transferred to the Eclipse Foundation (please see the {trademarkTransferUrl}[Trademark Transfer Agreement]).
 
 Who needs these requirements?
 
@@ -57,34 +26,19 @@ All project and product names must be vetted and approved by the EMO.
 
 ==== Registered Trademarks
 
-Project teams may request legal trademark registration for their project
-or product name. Since trademark registration requires a non-trivial
-investment in time and money, project teams must work with their PMC and
-the EMO to determine whether not trademark registration is necessary,
-determine in which countries the trademark must be registered, and how
-that registration will impact the project (e.g. adding registration
-marks on the website and in products).
+Project teams may request legal trademark registration for their project or product name. Since trademark registration requires a non-trivial investment in time and money, project teams must work with their PMC and the EMO to determine whether not trademark registration is necessary, determine in which countries the trademark must be registered, and how that registration will impact the project (e.g. adding registration marks on the website and in products).
 
 [[trademarks-background-orgs]]
 ==== Other Organization’s Trademarks
 
-Project teams must ensure that products names that include other
-organizations’ trademarks in names must be conform to those
-organizations’ trademark usage guidelines. For example, "{forgeName} Foo
-Perl" is not appropriate, since it improperly uses the trademark "Perl"
-(which is a trademark of The Perl Foundation); a better project name
-would be "{forgeName} Foo for Perl".
+Project teams must ensure that products names that include other organizations’ trademarks in names must be conform to those organizations’ trademark usage guidelines. For example, "{forgeName} Foo Perl" is not appropriate, since it improperly uses the trademark "Perl" (which is a trademark of The Perl Foundation); a better project name would be "{forgeName} Foo for Perl".
 
 [[trademarks-background-name]]
 ==== Choosing a Name
 
-Naming and branding are challenging issues that generally require some
-real investment in time and energy. The best project names are
-distinctive and memorable.
+Naming and branding are challenging issues that generally require some real investment in time and energy. The best project names are distinctive and memorable.
 
-Project teams should start the process of securing the trademark for a
-name as early as is practical. This is required to ensure the EMO has 
-sufficient time to review and approve the name.
+Project teams should start the process of securing the trademark for a name as early as is practical. This is required to ensure the EMO has  sufficient time to review and approve the name.
 
 A project team should start this process:
 
@@ -92,235 +46,130 @@ A project team should start this process:
 * As soon as their project wants to name a new software product; or
 * Before initiating a Restructuring Review to change a project name
 
-NOTE: Renaming projects (i.e. after a project has been created
-and provisioned) requires significant work on the part of the
-infrastructure team, and can be disruptive and confusing for consumers.
-Project teams should start the process as early as possible once they
-have a candidate name.
+[NOTE]
+====
+Renaming projects (i.e. after a project has been created and provisioned) requires significant work on the part of the infrastructure team, and can be disruptive and confusing for consumers. Project teams should start the process as early as possible once they have a candidate name.
+====
 
 [[trademarks-project]]
 === Project Names
 
-A project, as defined by the Eclipse Development Process, is the main
-operational unit; all open source software development at {forgeName}
-occurs within the context of a project. The
-Eclipse Foundation holds the trademark for all {forgeName} Projects.
+A project, as defined by the Eclipse Development Process, is the main operational unit; all open source software development at {forgeName} occurs within the context of a project. The Eclipse Foundation holds the trademark for all {forgeName} Projects.
 
-All project names must be approved by the Eclipse Management
-Organization (EMO) either before a project is created or before an
-existing project is renamed.
+All project names must be approved by the Eclipse Management Organization (EMO) either before a project is created or before an existing project is renamed.
 
 [[trademarks-project-formal]]
 ==== Formal Name
 
-The primary branding for any project name is fully-qualified formal name
-which includes the "{forgeName}" prefix (e.g. "{forgeName} Woolsey Intellectual
-Property Tools" or "{forgeName} Woolsey Framework"). This ensures that
-the project is associated with the Eclipse Foundation in the community,
-ecosystem, and the minds of users and adopters. However, {forgeName}
-Projects are oftentimes known by many names: it is common for a project
-to have both a formal and a nickname or commonly-used acronym.
+The primary branding for any project name is fully-qualified formal name which includes the "{forgeName}" prefix (e.g. "{forgeName} Woolsey Intellectual Property Tools" or "{forgeName} Woolsey Framework"). This ensures that the project is associated with the Eclipse Foundation in the community, ecosystem, and the minds of users and adopters. However, {forgeName} Projects are oftentimes known by many names: it is common for a project to have both a formal and a nickname or commonly-used acronym.
 
 The formal name may include a brand name and/or a descriptive name.
 
 [[trademarks-project-brand]]
 ==== Brand Names
 
-Project teams should strongly consider choosing a brand name. "Woolsey",
-"Apogy", and "Whiskers" are examples of brand names that are distinctive
-and memorable; they make the project easier to talk and write about than
-a wordier descriptive name. These names are not descriptive and so don’t
-stand well on their own; combining a brand name with a descriptive name
-(e.g. "{forgeName} Woolsey Intellectual Property Tools") can help in this
-regard.
+Project teams should strongly consider choosing a brand name. "Woolsey", "Apogy", and "Whiskers" are examples of brand names that are distinctive and memorable; they make the project easier to talk and write about than a wordier descriptive name. These names are not descriptive and so don’t stand well on their own; combining a brand name with a descriptive name (e.g. "{forgeName} Woolsey Intellectual Property Tools") can help in this regard.
 
 [[trademarks-project-descriptive]]
 ==== Descriptive Names
 
-Projects are encouraged to use a descriptive name. Descriptive names
-provide context that can help a casual viewer appreciate the purpose of
-the project in way that is difficult or impossible to convey with a
-brand name "Graphical Modeling Framework", "Trust Framework" or "Component 
-Assembly Tools" are examples of descriptive names..
-
-The best names do not include the word "Project", and are—in formal
-contexts—prepended by "{forgeName}". The project name should still work with
-or without the prefix. For example, "Graphical Modeling Framework" and
-"{forgeName} Graphical Modeling Framework" are equally understandable.
-
-Descriptive names may optionally include the words "Framework",
-"Platform", or "Tools" if the project has a specific emphasis on
-extensible frameworks, a platform, or obvious development tooling
-technology. {forgeName} projects always provide both but may be tailored
-more toward one or the other. When choosing to use these words, the team
-should consider that "Framework", "Platform", and "Tools" mean different
-things to different people and may be becoming overused.
+Projects are encouraged to use a descriptive name. Descriptive names provide context that can help a casual viewer appreciate the purpose of the project in way that is difficult or impossible to convey with a brand name "Graphical Modeling Framework", "Trust Framework" or "Component Assembly Tools" are examples of descriptive names..
+
+The best names do not include the word "Project", and are—in formal contexts—prepended by "{forgeName}". The project name should still work with or without the prefix. For example, "Graphical Modeling Framework" and "{forgeName} Graphical Modeling Framework" are equally understandable.
+
+Descriptive names may optionally include the words "Framework", "Platform", or "Tools" if the project has a specific emphasis on extensible frameworks, a platform, or obvious development tooling technology. {forgeName} projects always provide both but may be tailored more toward one or the other. When choosing to use these words, the team should consider that "Framework", "Platform", and "Tools" mean different things to different people and may be becoming overused.
 
 [[trademarks-project-nick]]
 ==== Nicknames
 
-A project may have a nickname or common name that is a shorter form of
-the formal name (and will likely be the same as the brand name). The
-"{forgeName} Woolsey Intellectual Property Tools" project may be referred to
-as "{forgeName} Woosley" or simply "Woolsey". An acronym may be used as a
-nickname (e.g. "ECF" and "GMF").
+A project may have a nickname or common name that is a shorter form of the formal name (and will likely be the same as the brand name). The "{forgeName} Woolsey Intellectual Property Tools" project may be referred to as "{forgeName} Woosley" or simply "Woolsey". An acronym may be used as a nickname (e.g. "ECF" and "GMF").
 
 [[trademarks-project-acronym]]
 ==== Acronyms For Long Names
 
-Most descriptive names are sufficiently long that it can be convenient
-to abbreviate them in some way. 
+Most descriptive names are sufficiently long that it can be convenient to abbreviate them in some way. 
 
-NOTE: Acronyms often become brand names.
+[NOTE]
+====
+Acronyms often become brand names.
+====
 
 [[trademarks-project-existing]]
 ==== Existing Software Product Names
 
-To avoid confusion between {forgeName} Projects and commercial products,
-{forgeName} projects may not be named after commercial products and vice
-versa. To ensure that users understand the source of software
-products—i.e. from {aForgeName} project, or from a third party
-vendor—the brand for {aForgeName} project must not include or be directly
-reminiscent of a commercial product.
+To avoid confusion between {forgeName} Projects and commercial products, {forgeName} projects may not be named after commercial products and vice versa. To ensure that users understand the source of software products—i.e. from {aForgeName} project, or from a third party vendor—the brand for {aForgeName} project must not include or be directly reminiscent of a commercial product.
 
 [[trademarks-project-short]]
 ==== Short Names and Ids
 
-Projects require a short name; this name is used to as an ID for the
-project in various parts of Eclipse Foundation infrastructure and should
-be as reflective of the formal name as possible.  It may, for example,
-be a lowercase rendering of the brand name, or an acronym of a
-descriptive name.
-
-The short name may contain lowercase alphanumeric characters, dashes,
-and underlines. The short name may not contain periods (.). Short names
-are used in some project URLs, download directories, <<ip-ipzilla,IPZilla>>,
-and in other parts of the supported infrastructure.
-
-The short name is joined with the short name of the parent project(s) to
-form a qualified identifier for the project that is used as a key on
-many of the webpages and services generated and/or maintained for the
-project by the Eclipse Foundation. e.g. the "{forgeName} Woolsey" project
-has a short name of "woolsey"; its qualified name is
-"technology.dash.woolsey", indicating that it is a subproject of the
-{aForgeName} _Dash_ Project which is itself a subproject of the {forgeName}
-_Technology_ Top Level Project.
-
-Project names should always be referred to in a consistent casing, and
-used as an adjective (never as a noun or verb) like any trademark should
-be used (e.g. "Download {forgeName} Woolsey software here", using the
-Woolsey name as an adjective for software).
+Projects require a short name; this name is used to as an ID for the project in various parts of Eclipse Foundation infrastructure and should be as reflective of the formal name as possible.  It may, for example, be a lowercase rendering of the brand name, or an acronym of a descriptive name.
+
+The short name may contain lowercase alphanumeric characters, dashes, and underlines. The short name may not contain periods (.). Short names are used in some project URLs, download directories, <<ip-ipzilla,IPZilla>>, and in other parts of the supported infrastructure.
+
+The short name is joined with the short name of the parent project(s) to form a qualified identifier for the project that is used as a key on many of the webpages and services generated and/or maintained for the project by the Eclipse Foundation. e.g. the "{forgeName} Woolsey" project has a short name of "woolsey"; its qualified name is "technology.dash.woolsey", indicating that it is a subproject of the {aForgeName} _Dash_ Project which is itself a subproject of the {forgeName} _Technology_ Top Level Project.
+
+Project names should always be referred to in a consistent casing, and used as an adjective (never as a noun or verb) like any trademark should be used (e.g. "Download {forgeName} Woolsey software here", using the Woolsey name as an adjective for software).
 
 [[trademarks-project-product]]
 ==== Product Names
 
-A product is a specific, downloadable software product that users or
-consumers might want to use in some way. Most projects release a product
-with the same name (e.g. the {forgeName} Woolsey project releases a software
-product called "{forgeName} Woolsey") or some variation of the project name
-(e.g. "{forgeName} Woolsey SDK").
+A product is a specific, downloadable software product that users or consumers might want to use in some way. Most projects release a product with the same name (e.g. the {forgeName} Woolsey project releases a software product called "{forgeName} Woolsey") or some variation of the project name (e.g. "{forgeName} Woolsey SDK").
 
-NOTE: Most open source projects produce products that share the project name.
-There are, however, numerous examples of projects that produce
-additional products. The Eclipse CDO project, for example, has a product
-named "Dawn"; and the Eclipse Graphical Editing Framework project has a
-product named "Zest".
+[NOTE]
+====
+Most open source projects produce products that share the project name. There are, however, numerous examples of projects that produce additional products. The Eclipse CDO project, for example, has a product named "Dawn"; and the Eclipse Graphical Editing Framework project has a product named "Zest".
+====
 
-Product names should also be prefixed with "{forgeName}" when used in any
-formal context (e.g. _{forgeName} Widgets_).
+Product names should also be prefixed with "{forgeName}" when used in any formal context (e.g. _{forgeName} Widgets_).
 
-Project teams should work with their PMC to determine whether or not to
-pursue assertion of ownership of the trademark for product names.
-Project teams should work with the Eclipse Management Organization (EMO)
-to assert ownership of product trademarks.
+Project teams should work with their PMC to determine whether or not to pursue assertion of ownership of the trademark for product names. Project teams should work with the Eclipse Management Organization (EMO) to assert ownership of product trademarks.
 
 [[trademarks-project-description]]
 ==== Project Descriptions
 
-All {forgeName} projects require a description. The project description must
-include a brief sentence or short paragraph (no bullets) that explains
-the primary function of the software deliverables provided. For example:
+All {forgeName} projects require a description. The project description must include a brief sentence or short paragraph (no bullets) that explains the primary function of the software deliverables provided. For example:
 
 ____
-The Eclipse pass:[C/C++] Development Tooling(TM)
-(CDT) project provides a fully functional C and pass:[C++] Integrated 
-Development Environment based on the Eclipse Platform.
+The Eclipse pass:[C/C++] Development Tooling(TM) (CDT) project provides a fully functional C and pass:[C++] Integrated Development Environment based on the Eclipse Platform.
 ____
 
-The complete description can certainly include much more information,
-but starting with a short paragraph is a great service for new readers
-to the project’s website, and is important for the Eclipse Foundation to
-maintain an overall list of project trademarks for software products.
-While this trademark description style may sometimes seem clumsy in
-technical documentation, it is a critical way that the Eclipse
-Foundation enforces trademarks.
+The complete description can certainly include much more information, but starting with a short paragraph is a great service for new readers to the project’s website, and is important for the Eclipse Foundation to maintain an overall list of project trademarks for software products. While this trademark description style may sometimes seem clumsy in technical documentation, it is a critical way that the Eclipse Foundation enforces trademarks.
 
-Project teams may seek guidance from the PMC and EMO to ensure that the
-text is a proper trademark goods description; i.e. one that describes
-the specific functionality of the software available for download and
-use.
+Project teams may seek guidance from the PMC and EMO to ensure that the text is a proper trademark goods description; i.e. one that describes the specific functionality of the software available for download and use.
 
 [[trademarks-project-logo]]
 ==== Logos And Graphics
 
 All {forgeName} projects are encouraged to create a unique logo to identify their project. Projects teams can engage a graphic design crowdsouring site or similar service to create a logo. The project leader and committers are responsible for setting up the design process and providing the feedback to the graphic designers. Based on past experience, faster and more detailed feedback to the designers yields better results.
 
-Logos are important to recognize as trademarks as well. For a project's
-official logo (if it has one, and especially if it uses the Eclipse
-Logo in any way), the designer must ensure that it includes a small
-trademark (™)  or registered trademark (®) symbol (as appropriate) in
-the graphic or immediately adjacent to it.
+Logos are important to recognize as trademarks as well. For a project's official logo (if it has one, and especially if it uses the Eclipse Logo in any way), the designer must ensure that it includes a small trademark (™)  or registered trademark (®) symbol (as appropriate) in the graphic or immediately adjacent to it.
 
-Projects may request to use the Eclipse Logo within their project
-logo, or otherwise create a derivative of the Eclipse Logo. However,
-they must contact the EMO (via a {emoApprovalsUrl}[Bugzilla record]) to request the Board's permission to do so.
+Projects may request to use the Eclipse Logo within their project logo, or otherwise create a derivative of the Eclipse Logo. However, they must contact the EMO (via a {emoApprovalsUrl}[Bugzilla record]) to request the Board's permission to do so.
 
 The Eclipse Foundation will help fund the creation of project logos. A project leader or committer will have to pay for the logo design in advance. Once the logo is created, the project can then send the invoice to the Eclipse Foundation {marketingEmail}[marketing team]. The Foundation will reimburse up to USD$600 for the logo design. Please also feel free to contact the Foundation marketing team with any questions about the logo design.
 
 [[trademarks-website]]
 === Project Websites
 
-The official project website is the primary means of learning about the
-project and getting involved: people who are interested in contributing
-to the project come here to learn about technical details, and to
-observe the project's development process.
+The official project website is the primary means of learning about the project and getting involved: people who are interested in contributing to the project come here to learn about technical details, and to observe the project's development process.
 
-{forgeName} projects must host all project content on an Eclipse Foundation
-provided domain,especially the official/primary website for project-related information,
-communications, access to source code, and downloads. This ensures both
-that the Eclipse Foundation's Webmaster team can maintain the services, and informs
-consumers that the content comes from {aForgeName} Project, and not a
-third party. This further ensures that the project remains independent
-of any specific vendor or single individual.
+{forgeName} projects must host all project content on an Eclipse Foundation provided domain,especially the official/primary website for project-related information, communications, access to source code, and downloads. This ensures both that the Eclipse Foundation's Webmaster team can maintain the services, and informs consumers that the content comes from {aForgeName} Project, and not a third party. This further ensures that the project remains independent of any specific vendor or single individual.
 
-All primary links to the project (including, for example, the project’s
-contribution guide) must point directly to the official website, and not
-to external sites or domains.
+All primary links to the project (including, for example, the project’s contribution guide) must point directly to the official website, and not to external sites or domains.
 
 [[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 formal
-name and must include the relevant trademark (™) or registered trademark
-(®) symbol (e.g. "{forgeName} Woolsey Intellectual Property Tools™"). If the
-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 formal name and must include the relevant trademark (™) or registered trademark (®) symbol (e.g. "{forgeName} Woolsey Intellectual Property Tools™"). If the 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
 
-All project web pages must include a footer that prominently displays an
-approved Eclipse Logo, important links back to key pages, and a
-copyright notice.
+All project web pages must include a footer that prominently displays an approved Eclipse Logo, important links back to key pages, and a copyright notice.
 
-Approved Eclipse logos are available on the
-https://www.eclipse.org/artwork[Eclipse Logos and Artwork] page.
+Approved Eclipse logos are available on the https://www.eclipse.org/artwork[Eclipse Logos and Artwork] page.
 
-The following minimal set of links must be included on the footer of all
-pages in the official project website:
+The following minimal set of links must be included on the footer of all pages in the official project website:
 
 * Main Eclipse Foundation website (http://www.eclipse.org);
 * Privacy policy (http://www.eclipse.org/legal/privacy.php);
@@ -328,169 +177,111 @@ pages in the official project website:
 * Copyright agent (http://www.eclipse.org/legal/copyright.php); and
 * Legal (http://www.eclipse.org/legal).
 
-NOTE: An appropriate footer is included automatically by the default website
-infrastructure and the PMI.
+[NOTE]
+====
+An appropriate footer is included automatically by the default website infrastructure and the PMI.
+====
 
 [[trademarks-metadata]]
 === Project Metadata
 
-All Projects must keep their metadata updated regularly in the central
-<<pmi, Project Management Infrastructure>> (PMI). Projects must ensure that all
-metadata is kept up-to-date in the PMI tool to ensure that
-other infrastructure tools and processes can make connections to and
-disseminate information for  the project.
+All Projects must keep their metadata updated regularly in the central <<pmi, Project Management Infrastructure>> (PMI). Projects must ensure that all metadata is kept up-to-date in the PMI tool to ensure that other infrastructure tools and processes can make connections to and disseminate information for  the project.
 
-The project description, scope, and other free-form text fields in the
-PMI must conform to the project naming guidelines. 
+The project description, scope, and other free-form text fields in the PMI must conform to the project naming guidelines. 
 
-NOTE: The PMI supports teasers or summaries for many fields; ensure that 
-these teasers also conform to the guidelines.
+[NOTE]
+====
+The PMI supports teasers or summaries for many fields; ensure that these teasers also conform to the guidelines.
+====
 
 [[trademarks-code]]
 === Code Namespaces
 
-Where applicable and supported by the programming languages and style
-used by the project, code namespaces must include the project’s short
-name.
+Where applicable and supported by the programming languages and style used by the project, code namespaces must include the project’s short name.
 
-In Java, for example, package names must start with `{namespace}` and use
-their short name in the third-segment  (i.e. follow the pattern
-`{namespace}.<short-name>.<component>`), e.g. `{namespace}.foo.core`,
-`{namespace}.foo.ui`, and `{namespace}.foo.connector`. Component
-names are left to the discretion of the project team.
+In Java, for example, package names must start with `{namespace}` and use their short name in the third-segment  (i.e. follow the pattern `{namespace}.<short-name>.<component>`), e.g. `{namespace}.foo.core`, `{namespace}.foo.ui`, and `{namespace}.foo.connector`. Component names are left to the discretion of the project team.
 
-The project team must petition the Planning Council via their PMC to
-request exceptions.
+The project team must petition the Planning Council via their PMC to request exceptions.
 
 [[trademarks-external]]
 === Third-Party Use of Trademarks
 
-The use of Eclipse Foundation trademarks outside of the immediate scope of the
-open source project, including the use of project names, is subject to the terms
-of the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks].
-This includes third-party websites, books, publications, conferences, events, and
-more.
+The use of Eclipse Foundation trademarks outside of the immediate scope of the open source project, including the use of project names, is subject to the terms of the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks]. This includes third-party websites, books, publications, conferences, events, and more.
 
 [[trademarks-external-events]]
 ==== Conferences and Events
 
-Use of the terms "Eclipse", "EclipseCon", and "Eclipse Day"
-are reserved for exclusive use by events authorized by the Eclipse Foundation. 
+Use of the terms "Eclipse", "EclipseCon", and "Eclipse Day" are reserved for exclusive use by events authorized by the Eclipse Foundation. 
 
-Other Eclipse Foundation trademarks (e.g. project names) may be used in events, 
-but must be approved by the EMO subject to the following considerations:
+Other Eclipse Foundation trademarks (e.g. project names) may be used in events, but must be approved by the EMO subject to the following considerations:
 
-* The name of the event must conform to the terms laid out in the Guidelines for 
-Eclipse Logos & Trademarks;
-* The event must include sessions that focus on content provided by the 
-corresponding open source projects;
-* Representatives from corresponding {forgeName} open source projects (e.g.
-committers, project leads, PMC members) must be directly involved in the event; and
-* Websites, printed materials, and other content associated with the event
-must provide pointers/links to the project website and trademark attribution.
+* The name of the event must conform to the terms laid out in the Guidelines for Eclipse Logos & Trademarks;
+* The event must include sessions that focus on content provided by the corresponding open source projects;
+* Representatives from corresponding {forgeName} open source projects (e.g. committers, project leads, PMC members) must be directly involved in the event; and
+* Websites, printed materials, and other content associated with the event must provide pointers/links to the project website and trademark attribution.
 
-The trademark should not generally be concatenated with any other words. 
-Exceptions for established conventions (e.g. *WoolseyCon*) may be granted
-on a case-by-case basis.
+The trademark should not generally be concatenated with any other words. Exceptions for established conventions (e.g. *WoolseyCon*) may be granted on a case-by-case basis.
 
-Trademark attribution must indicate that the trademarks are used with the permission
-of the Eclipse Foundation (e.g. "Woolsey is a trademark of the Eclipse Foundation, 
-Inc. and is used with permission.").
+Trademark attribution must indicate that the trademarks are used with the permission of the Eclipse Foundation (e.g. "Woolsey is a trademark of the Eclipse Foundation, Inc. and is used with permission.").
 
-NOTE: Permission is *not required* to present a talk on {aForgeName} project.
+[NOTE]
+====
+Permission is *not required* to present a talk on {aForgeName} project.
+====
 
 [[trademark-external-community]]
 ==== Community Portals
 
-Community portals are generally operated at "arms length" from the
-{forgeName} open source project. The community portal may help users 
-find information about what the project software does and how to get it,
-or provide a means for the community to contribute to related side projects
-that are not part of the {forgeName} open source project.
+Community portals are generally operated at "arms length" from the {forgeName} open source project. The community portal may help users  find information about what the project software does and how to get it, or provide a means for the community to contribute to related side projects that are not part of the {forgeName} open source project.
 
-The community portal is not a replacement for a developer portal which takes
-form in the official project website as described by this document.
+The community portal is not a replacement for a developer portal which takes form in the official project website as described by this document.
 
 A community portal is operated with these considerations:
 
-* The name of the community portal must conform to the terms laid out in 
-the Guidelines for Eclipse Logos & Trademarks;
-* The first and most prominent reference to the {forgeName} open source
-project or corresponding product name on every web page must use the formal name
-and must include the relevant trademark or registered trademark symbol
-(subsequent references may use  the nickname or acronym as appropriate);
-* All references to {forgeName} open source project names must be prefixed with
-"{forgeName}";
-* The website must include trademark attributions for all Eclipse
-Foundation trademarks used on the site; and
-* Contributors must be directed to the official project website for information
-regarding contribution or related development activities.
-
-Community portals must include a prominent text paragraph or sidebar
-that points to the official project website, so that users interested in
-contributing or otherwise participating in the open source project know
-where to go.
-
-NOTE: Naming exceptions may be granted for names that follow established
-conventions (e.g. *Woolsey(TM) Labs*). Contact the EMO to request an
-exception.
+* The name of the community portal must conform to the terms laid out in the Guidelines for Eclipse Logos & Trademarks;
+* The first and most prominent reference to the {forgeName} open source project or corresponding product name on every web page must use the formal name and must include the relevant trademark or registered trademark symbol (subsequent references may use  the nickname or acronym as appropriate);
+* All references to {forgeName} open source project names must be prefixed with "{forgeName}";
+* The website must include trademark attributions for all Eclipse Foundation trademarks used on the site; and
+* Contributors must be directed to the official project website for information regarding contribution or related development activities.
+
+Community portals must include a prominent text paragraph or sidebar that points to the official project website, so that users interested in contributing or otherwise participating in the open source project know where to go.
+
+[NOTE]
+====
+Naming exceptions may be granted for names that follow established conventions (e.g. *Woolsey(TM) Labs*). Contact the EMO to request an exception.
+====
 
 [[trademarks-domains]]
 ==== Domains
 
-Websites on external domains that use a project name trademark (e.g. 
-`www.mosquitto.com`) that point to servers that are not hosted by 
-the Eclipse Foundation, may be employed as community portals.
-External domains may be appropriate for some forms of documentation,
-community-generated content, and pointers to community forums. 
+Websites on external domains that use a project name trademark (e.g. `www.mosquitto.com`) that point to servers that are not hosted by the Eclipse Foundation, may be employed as community portals. External domains may be appropriate for some forms of documentation, community-generated content, and pointers to community forums. 
 
-Only existing, well-known domains that are already heavily linked and
-known by the community are permitted as external domains. For other
-historical domains that are not an important part of the project's
-brand, permanent (301) redirects should point to the official project
-website hosted on Eclipse Foundation infrastructure.
+Only existing, well-known domains that are already heavily linked and known by the community are permitted as external domains. For other historical domains that are not an important part of the project's brand, permanent (301) redirects should point to the official project website hosted on Eclipse Foundation infrastructure.
 
-Projects with widely-used historical domain names may continue using the
-domain with these considerations:
+Projects with widely-used historical domain names may continue using the domain with these considerations:
 
-* Ownership of the domain name must be transferred to the Eclipse
-Foundation; and
-* The domain must be regarded and used exclusively as a community portal
-(and not as an official project website).
+* Ownership of the domain name must be transferred to the Eclipse Foundation; and
+* The domain must be regarded and used exclusively as a community portal (and not as an official project website).
 
 [[trademarks-external-attribution]]
 ==== Trademark Attributions
 
-The external uses of Eclipse Foundation trademarks must include a prominent
-trademark attribution of all applicable Eclipse Foundation marks.
+The external uses of Eclipse Foundation trademarks must include a prominent trademark attribution of all applicable Eclipse Foundation marks.
 
 For example:
 
-Eclipse Woolsey Intellectual Property Tools, Eclipse Woolsey, Woolsey,
-Eclipse, the Eclipse logo, and the Eclipse Woolsey project logo are
-either registered trademarks or trademarks of The Eclipse Foundation in
-the United States and/or other countries.
+____
+Eclipse Woolsey Intellectual Property Tools, Eclipse Woolsey, Woolsey, Eclipse, the Eclipse logo, and the Eclipse Woolsey project logo are either registered trademarks or trademarks of The Eclipse Foundation in the United States and/or other countries.
+____
 
 [[trademarks-notes]]
 === Important Notes
 
-Nothing in this Eclipse Foundation document shall be interpreted
-to allow any third party to claim any association with the Eclipse
-Foundation or any of its projects or to imply any approval or support by
-the Eclipse Foundation for any third party products, services, or
-events, unless specifically covered by an Eclipse Membership agreement.
+Nothing in this Eclipse Foundation document shall be interpreted to allow any third party to claim any association with the Eclipse Foundation or any of its projects or to imply any approval or support by the Eclipse Foundation for any third party products, services, or events, unless specifically covered by an Eclipse Membership agreement.
 
-Questions? Project participants who have questions about Eclipse
-Foundation trademarks either used here or at third party sites should
-contact the EMO. Other organizations looking for information
-on how to use or refer to any Eclipse Foundation project trademarks or
-logos should see the
-{trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks].
+Questions? Project participants who have questions about Eclipse Foundation trademarks either used here or at third party sites should contact the EMO. Other organizations looking for information on how to use or refer to any Eclipse Foundation project trademarks or logos should see the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks].
 
-Thanks and credit to the Apache Software Foundation's
-http://www.apache.org/foundation/marks/pmcs[Project
-Branding Requirements] (licensed under the Apache License, v2.0)
-for parts of this trademark section.
+Thanks and credit to the Apache Software Foundation's http://www.apache.org/foundation/marks/pmcs[Project Branding Requirements] (licensed under the Apache License, v2.0) for parts of this trademark section.
 
 [[trademarks-faq]]
 Frequently Asked Questions
@@ -498,5 +289,4 @@ Frequently Asked Questions
 
 [qanda]
 Can my company use the project name as part of their product name?::
-	It depends on how the name will be used. Please see the
-	{trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks].
\ No newline at end of file
+	It depends on how the name will be used. Please see the {trademarkGuidelinesUrl}[Guidelines for Eclipse Logos & Trademarks].
\ No newline at end of file