Update contributing guidelines

public/markdown/contributing.md

@@ -19,8 +19,7 @@ Before making a contribution, it is important to make sure that the change you w
 
 ### Procedure
 
-1. Make sure you have signed the [Lightbend CLA](http://www.lightbend.com/contribute/cla); if not, sign it online.
-2. Ensure that your contribution meets the following guidelines:
+1. Ensure that your contribution meets the following guidelines:
     1. Live up to the current code standard:
         - Not violate [DRY](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch30.html).
         - [Boy Scout Rule](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) needs to have been applied.
@@ -41,10 +40,10 @@ Before making a contribution, it is important to make sure that the change you w
         * Features are forever, always think about whether a new feature really belongs to the core framework or if it should be implemented as a module
         * Code must conform to standard style guidelines and pass all tests (see [Run tests](documentation/latest/BuildingFromSource#run-tests))
     6. New files must:
-        * Have a Lightbend copyright header in the style of ``Copyright (C) 2009-2019 Lightbend Inc. <https://www.lightbend.com>``.
+        * Have a copyright header in the style of ``2011-2021 Lightbend Inc., since 2022 the original author or authors from the Play Framework project``.
         * Not use ``@author`` tags since it does not encourage [Collective Code Ownership](http://www.extremeprogramming.org/rules/collective.html).
-3. Ensure that your commits are squashed.  See [working with git](/documentation/latest/WorkingWithGit) for more information.
-4. Submit a pull request.
+2. Ensure that your commits are squashed.  See [working with git](/documentation/latest/WorkingWithGit) for more information.
+3. Submit a pull request.
 
 If the pull request does not meet the above requirements then the code should **not** be merged into master, or even reviewed - regardless of how good or important it is. No exceptions.
 
@@ -57,6 +56,6 @@ Generally, all bug fixes, improvements and new features will go to the master br
 * The change only affects the documentation
 * The change fixes a regression that was introduced in a previous stable release from that branch
 * The change fixes a bug that impacts significant number of members of the open source community with no simple work arounds available
-* Any other reason that Lightbend deems appropriate
+* Any other reason that Play steering committee deems appropriate
 
 All backports and other commits to stable branches, in addition to satisfying the regular contributor guidelines, must also be binary and source compatible with previous releases on that branch.  The only exception to this is if a serious bug is impossible to fix without breaking the API, for example, a particular feature is not possible to use due to flaws in the API.