Update contributors_guidelines.md

The Legal team reviewed this document since it ties to the Member Policies document.  This update is their changes.

Signed-off-by: Alan <alan@linux.com>

Author: aclark801

contributors_guidelines.md

@@ -1,13 +1,20 @@
-# OpenELA Contribution Guidelines
+# OpenELA Contribution and Intellectual Property Policy
 
 ## Scope
 
+This OpenELA Contribution and Intellectual Property Policy (Policy) applies 
+to contributions of new or revised source code to an OpenELA project.  It 
+does not apply to the evaluation of General Members’ contributions of time or 
+effort substantially furthering OpenELA’s mission for the purpose of membership 
+eligibility, which are determined at the discretion of OpenELA’s Board of Directors 
+or designee.
+
 OpenELA welcomes contributions from the community seeking to improve the
 experience of users on Enterprise Linux. Contributions to OpenELA must adhere
 to the following guidelines.
 
-The goal of OpenELA is to provide continuity for Enterprise Linux downstream
-distributions by providing a secure, transparent, and reliable Enterprise Linux
+The goal of OpenELA is to provide continuity for downstream
+distributions by providing a secure, transparent, and reliable 
 (EL) source that is globally available to anyone as a buildable base. OpenELA
 allows distributions to create and maintain downstream derivatives of EL.
 
@@ -22,16 +29,17 @@ OpenELA must have antecedents in the upstream for those distributions.
 Patches are fixes, changes, and enhancements specific to a single project or
 package.
 
-“Bug Fix Patches” are Patches that are present in the upstream repository or
+“Bug Fix Patches” are generally patches that are present in the upstream repository or
 the upstream distribution repository and improve stability, robustness or
-security of the already present features. They are backward binary compatible
-and do not break previously documented behavior or features.
+security of the already present features. They should be backward binary compatible
+and not break previously documented behavior or features. See also the Bug-For-Bug 
+Compatibility Standard below. 
 
 ### Contribute Upstream First
 
-Before Patches are considered for OpenELA, Developers are encouraged to
+Before patches are considered for OpenELA, developers are encouraged to
 contribute patches to upstream. If you’re having trouble finding the upstream
-for a particular project, check the Source line in the SRPM. We don’t want
+for a particular project, check the source line in the SRPM. We don’t want
 OpenELA to become a repository for orphaned patches, and it’s very important to
 encourage developers to contribute their efforts to the upstream projects.
 
@@ -110,7 +118,7 @@ add value to the OpenEL Ecosystem.
 
 Branches within the openela-contrib repo should retain the ‘contrib’ tag in
 their branch names, to ensure that it is clear that these branches are not
-bug-for-bug compatible with EL.
+bound to be bug-for-bug compatible with EL.
 
 ## Contributing Bug Fix Patches into -contrib repos
 
@@ -122,13 +130,13 @@ to `git clone` both the main and -contrib repositories into the same local git
 repo.
 
 Patches which are accepted to the -contrib branches should meet the “Bug Fix
-Patches” compatibility. The Technical Governance board can further define
-additional exceptions. Patches for -contrib branches must be present in the
-upstream project repository. Patches which are not applicable to or not
-accepted by upstream will require review by the Technical Steering Committee.
+Patches” compatibility standard described above. The Technical Steering Committee 
+can further define additional exceptions. Patches for -contrib branches must be 
+present in the upstream project repository. Patches which are not applicable to 
+or not accepted by upstream will require review by the Technical Steering Committee.
 
 ## Document Governance
 
-This document is owned and updated by the Technical Steering Committee. Please
+This document is maintained by the Technical Steering Committee. Please
 supply all suggested modifications for consideration by the Technical Steering
-Committee through the usual github constructs.
+Committee and/or OpenELA Board of Directors through the usual github constructs.