address PR feedback

Author: ucodery

_posts/2025-10-02-why-we-choose-what-we-choose.md

@@ -23,7 +23,7 @@ Our rubric comes from five categories, approximately ordered as follows:
 
 We love open software! It's kind of in our name. We are always looking to nurture and support open source software, even beyond packaging projects. It should come as no surprise then, that we only choose tools in our packaging guide that are themselves open source.
 
-We don’t just appreciate open source though, we also look for projects that are open contribution – that do most of their maintenance, stewardship, and designing in public. This means that there is a public bug tracker, that new issues to that bug tracker are accepted from anyone, and also fixes for those bugs are accepted from non-maintainers. It may also mean that new features ideas are accepted from the community, or even given a period of public comment.
+We don’t just appreciate open source though, we also look for projects that are open contribution – that do most of their maintenance, stewardship, and designing in public. This means that there is a public bug tracker, that new issues to that bug tracker are accepted from anyone, and also fixes for those bugs are accepted from non-maintainers. It may also mean that new feature ideas are accepted from the community, or even given a period of public comment. Contributions from everyone, members and non-members, should be respected as the exchange of free ideas, and project authors should not seek to take exclusive ownership of the collaborative efforts of the community it is a part of. This means that contributors of any level and to any purpose of the project should be recognized publically. It also means that the project is not asking for the exclusive rights of those contributors' ideas (through Contributor License Agreements).
 
 Our commitment to open software goes beyond just projects that choose to host their code and bugs in a public manner. We also value Free Software; both as in Beer and as in Freedom. Permissive open source software empowers its users to take control of their tools and fix, extend, secure, and adapt code for the purposes that will best fit their own needs. Choosing projects that do not require a financial exchange in order to be used ensures that we can recommend our choices to anyone no matter their situation or location.
 
@@ -41,7 +41,7 @@ Projects that manage to attract and maintain a large collection of contributors
 
 It is very important to us that the tools and processes we stand behind support the full set of community standards.
 
-For Python, this typically means conforming to [PEPs](pep.python.org), but may also involve other standard bodies such as [SPECs](https://scientific-python.org/specs/).
+For Python, this typically means conforming to [Python Enhancement Proposals](pep.python.org), but may also involve other standard bodies such as [Scientific Python Ecosystem Coordination](https://scientific-python.org/specs/).
 
 Supporting community standards demonstrates that the project respects the community it is working within and is serious about interoperability with other tools and processes. When done right, these tools empower their users to move this workflow, or any of its inputs or outputs, to another standards-compliant tool or process with little to no friction. It also makes it easier to teach since many of the concepts, as well as in some cases entire parts of project data, are tool-agnostic and can feel "familiar" even to those that have never used the tool before. There is also likely to be more documentation developed through forums, blogs, workshops, and other online platforms, because they apply to more than one tool.