DNN Platform Documentation Fixes (#4115)

* Updated Third-Party license notices

* Updated Approver Listing

* Updated to document Draft & On-Hold PR's

* Changed future stage elements to remove duplication

* Updated Release Schedule

* Updated Versioning Policy

* Update .github/VERSIONING_POLICY.md

Co-authored-by: Daniel Valadas <[email protected]>

Co-authored-by: Peter Donker <[email protected]>
Co-authored-by: Daniel Valadas <[email protected]>

.github/PULL_REQUEST_PROCESS.md

@@ -25,18 +25,11 @@ Community review of submitted pull requests is encouraged, and all pull requests
 At the current time the following community members are designated approvers.
 
 * Mitchel Sellers ([mitchelsellers](https://github.com/mitchelsellers)) - Community Technology Advisory Group Lead
-* Oliver Hine ([ohine](https://github.com/ohine))
 * Brian Dukes ([bdukes](https://github.com/bdukes))
 * Peter Donker ([donker](https://github.com/donker)) - Community Developer Advisory Group Lead
 * Daniel Valadas ([valadas](https://github.com/valadas))
 * Matt Rutledge ([mtrutledge](https://github.com/mtrutledge))
-* Vicenç Masanas ([vmasanas](https://github.com/vmasanas))
-* Erik van Ballegoij ([erikvb](https://github.com/erikvb))
-
-Additionally, the following individuals from ESW/DNN Corp are approved reviewers.
-
-* Daniel Aguilera ([daguiler](https://github.com/daguiler)) - CTO
-* Ash Prasad ([ashishpd](https://github.com/ashishpd)) - VP of Engineering
+* David Poindexter ([david-poindexter](https://github.com/david-poindexter)) - Community Strategy Advisory Group Lead
 
 ### Review Minimums
 An individual performing the code review should validate at a minimum the following.
@@ -50,6 +43,14 @@ If a reviewer has suggestions for improvement, those should be noted in the pull
 
 *If you have questions about a pull request or an idea for a pull request, please reach out to one of the approvers before submitting to ensure a streamlined process.*
 
+### Draft PR's
+For proper management of pull requests the team will utilize the "Draft" option within a pull request to identify something that is being submitted for consideration and in need of review/comment or other special review from the team.  Individuals should coordinate with the Approvers group prior to submitting any Draft pull requests as they are special cases.
+
+### On-Hold Tag
+The Approvers group will add the "On-Hold" tag to any pull request that is targeting a major or minor release until it is ready for merging.  This is done as an administrative process to prevent accidental merging and is not a reflection of rejection of the submitted code. The associated milestone will be updated when the "On-Hold" tag has been added for clear communication regarding expectations.
+
+Examples of requests of this nature include technology or dependency changes that could introduce major/minor breaking changes.
+
 ## Merging & Closing of Requests
 Once a pull request has been reviewed by two designated approvers it may be merged and the pull request closed.
 
@@ -67,11 +68,4 @@ We follow the process outlined in the [Versioning Policy](VERSIONING_POLICY.md)
 
 The review team will work to respond to all pull requests in a timely fashion.  If changes or additional information is requested a pull request will remain open allowing the submitter to update their contribution accordingly.  If a request for additional information or changes is not completed with 90 days of request the Pull Request will be closed to keep the pipeline clear.  Once the needed information has been gathered the information can be re-submitted via a new Pull Request.  
 
-For expedited processing you may reference the prior Pull Request.
-
-### Items for Future Releases
-If an item was submitted that will be integrated into a future release that is not currently in the development pipeline it is possible that the Pull Request will remain open. 
-
-In this situation the reviewing team will approve the request, tag the request with a specific version milestone and add a comment noting when and why it will be included in the particularly identified release.
-
-This most often will apply to technology or dependency changes that require alignment with Major, Minor, Revision build inclusion.  
+For expedited processing you may reference the prior Pull Request.

.github/RELEASE_SCHEDULE.md

@@ -2,14 +2,14 @@
 To ensure adequate time for release planning by the community, partners, and vendors a specific release process will be followed for all releases.  
 
 ## Release Candidates
-For a period of one week (Revision), two weeks (Minor) or four-weeks (Major) before any release, a Release Candidate (RC) version will be made available to the public.  At present these release candidates will be for testing only. After version 10.x efforts will be made to support upgrading from RC to Production releases.
+For a period of one week (Revision), two weeks (Minor) or three-weeks (Major) before any release, a Release Candidate (RC) version will be made available to the public.  At present these release candidates will be for testing only. After version 10.x efforts will be made to support upgrading from RC to Production releases.
 
-The goal of these release candidates is to give the community time to adjust their existing environments for any breaking changes, as well as to identify any issues with the changes.  If necessary, changes will be incorporated an additional RC release could be made if significant problems are identified.  If a revised Release Candidate is necessary the Production Release schedule will be impacted.  The exact impact will vary on a case-by-case basis depending on the nature of the issue(s) identified during RC review, however, will be clearly communicated during the release.
+The goal of these release candidates is to give the community time to adjust their existing environments for any breaking changes, as well as to identify any issues with the changes.  If necessary, changes will be incorporated an additional RC release could be made if significant problems are identified.  If a revised Release Candidate is necessary the Production Release schedule may be impacted.  The exact impact will vary on a case-by-case basis depending on the nature of the issue(s) identified during RC review, however, will be clearly communicated as part off the updated RC release notes.
 
 ## Production Releases
 Production releases will only be completed after a successful RC phase, except in the case of a significant security release that was included as part of a revision release.
 
-The release date will be communicated to the community at the time of the RC.  And each release will take the following considerations into mind for all releases.
+The anticipated release date will be communicated to the community at the time of the RC.  And each release will take the following considerations into mind for all releases.
 
 * Releases must allow for at least two additional business days after the release for regular Monday - Friday office situations (Releases only on Monday, Tuesday or Wednesday)
 * Releases will not be completed during weeks of major US holidays, specifically New Years, Memorial Day, Independence Day, Labor Day, Thanksgiving Day, or Christmas.

.github/VERSIONING_POLICY.md

@@ -1,29 +1,33 @@
 # DNN Platform Versioning and Deprecation Policies
 The DNN Platform follows a semantic versioning process for releases, in a manner to better communicate expectations of releases and their potential impacts to users of the platform.
 
-##Semantic Versioning
+## Semantic Versioning
 The DNN Community adopted the current semantic version policy in July of 2018.  Releases before this date may follow different standards.
 
 ### Major Releases (Ex 10.0.0)
 A major release is as the name implies, a release with major changes.  These changes might include new features, breaking changes, or other larger changes.  Each major release will come with release notes that outline the nature of any known breaking changes.
 
-Major releases are also the time that platform requirements might be changed, such as requiring a new edition of SQL Server or otherwise.
+Major releases are also the time that platform requirements might be changed, such as requiring a new edition of SQL Server, .NET Framework, or otherwise.
 
 ### Minor Releases (Ex 10.1, 10.2, 10.x)
-A minor might contain smaller new features and enhancements, but will not introduce any breaking API changes, nor will it change the requirements of the hosting environment or platform to run the application.  
+A minor release might contain smaller new features and enhancements, but will not introduce any known breaking API changes, nor will it change the requirements of the hosting environment or platform to run the application.  
+
+It is possible that minor breaking changes and Javascript library updates are included in minor releases.
 
 ### Revision Releases (Ex 10.1.1, 10.1.2, 10.1.x)
-These releases are created primarily to contain hot-fix style improvements from prior releases.  Any bugs or security issues identified, or missing UI/UX features from a Minor/Major release might be added to a revision release.  Similar to a Minor release a Revision release will not contain any known breaking changes.
+These releases are created primarily to contain hot-fix style improvements from prior releases.  Any bugs or security issues identified, or missing UI/UX features from a Minor/Major release might be added to a revision release.  Similar to a Minor release a Revision release will not contain any known breaking changes API.
+
+## API Deprecation Policy (Updated September 2020)
+The DNN Platform project is in a state of transition, continuing to modernize the API and remove existing technology debt.  To this point, it will be necessary for the project to remove/restructuree many public API's.  This will be done methodically, allowing developers to transition away from the older code with time to properly respond to change.
 
-## API Deprecation Policy
-The DNN Platform project is in a state of transition, continuing to modernize the API and work towards a transition to .NET Core.  To this point, it will be necessary for the project to remove public API's.  This will be done methodically, allowing developers to transition away from the older code with time to properly respond to change.
-Any API method to be removed will be flagged as deprecated in a release, major, minor or revision, and will be identified to be removed by a specific version.  This will be done using a C# annotation with a comment similar to the following "Deprecated in x.x.x.  Scheduled for removal in vy.0.0, use ____ instead".  The version number of "y" in this example must be 2 major versions ahead.  
-Therefore, an API marked as Deprecated in 9.2.1 can only be removed in version 11.0.  Additionally, methods marked for removal in a version will GUARANTEED be removed in that revision.
+Any API method to be removed will be flagged as deprecated in a release, major, minor or revision, and will be identified to be removed by a specific version.  This will be done using a C# `[Obsolete]` attribute with a comment similar to the following "Deprecated in x.x.x.  Scheduled for removal in vy.0.0, use ____ instead".  The version number of "y" in this example must be 1 major versions ahead of the version in which the notice was added.
+
+Therefore, an API marked as Deprecated in 9.2.1 can only be removed in version 10.0.  Additionally, methods marked for removal in a version will GUARANTEED be removed in that revision.
 > Example: [Obsolete("Deprecated in DotNetNuke 7.0. This function has been replaced by AddUserRole with additional params. Scheduled removal in v10.0.0.")]
 
+### Testing Recommendations
+It is suggested that all extension developers recompile their projects on the latest API versions on a regular basis to identify removed elements as the compiler warnings will be the primary communication method for these changes.
+
 ### Special DNN 10.x Cleanup
 A number of legacy APIs have been marked as deprecated for more than 7 years and not yet removed.  To continue to clean the API structure a final cleanup is being completed as part of the 10.x release.  All of these API's are more than 2 major revisions older, however, have non-standard indicators for the Obsolete attribute.  These will be removed in 10.x along with other expected removals.
 Lastly, each Major release will contain release notes outlining every API method removed.  More information can be found [in this blog post](https://www.dnnsoftware.com/community-blog/cid/156712/moving-forward-dnn-platform-100-growing-pains-lead-to-improvement)
-
-
-

NOTICE.md

@@ -1,10 +1,10 @@
 ## DNN Platform
 DNN Platform utilizes components that were developed by third-party entities. Some of these are used directly from source code while others are referenced as libraries.
 
-## Third Parry Source Code
+## Third Party Source Code
 DNN Platform is using a few third-party libraries as source code with some modification to run natively under the platform. These are:
-- [Client Dependency](https://github.com/Shazwazza/ClientDependency) – used as *ClientDependency.Core* project.
-- [Log4Net](http://logging.apache.org/log4net/download_log4net.cgi) – used as *DotNetNuke.Log4Net* project.
+- [Client Dependency](https://github.com/Shazwazza/ClientDependency) – used as *ClientDependency.Core* project, stored in a forked repository here: https://github.com/dnnsoftware/ClientDependency
+- [Log4Net](http://logging.apache.org/log4net/download_log4net.cgi) – used as *DotNetNuke.Log4Net* project, stored within this repository
 
-## Third Parry Libraries
+## Third Party Libraries
 All libraries used in DNN Platform have their licenses in the [Licenses folder](https://github.com/dnnsoftware/Dnn.Platform/tree/development/Website/Licenses).