Adding initial commit of the ASWF Development Philosophy

project_best_practices_guides/dev_philosophy.md

@@ -0,0 +1,43 @@
+# ASWF Development Philosophy
+
+## AI, LLMs, and how we’re thinking about technology innovation in software development
+
+This document is being written in the “age of AI” \- a time when how we as software engineers write and interact with code is rapidly changing, and keeping track of these changes is a job in itself. However, the philosophies and best practices laid out in this document are nothing new. They are long-held beliefs and unspoken (read: obvious) parts of being good stewards of our craft, especially in the open source landscape. The decision to put them in writing is our attempt to be clear, forward-thinking thought leaders in our space, and for the Foundation to continue to be a place that developers, companies, and productions trust in their critical creative work.
+
+We write this document in order to help our organization move forward with technology, and equip our maintainers and contributors with the tools and documentation they need to succeed. These policies, for now, focus on code and tooling. We have several projects within the Foundation whose outputs and/or inputs are non-code (assets, data sets, images) \- these may require separate policies and procedures that differ from AI-assisted code.
+
+Please refer to individual Foundation project repositories for detailed policies and contribution guidelines. 
+
+### What this document **is not**:
+
+* A stance on AI-generated content not related to code contributed to our projects. We are a small piece in a very big puzzle, and the scope of this document is too.  
+* Finished. This is only the start, and we will adapt, change, and re-write as necessary.   
+* Absolute. This document is a general guideline, a starting place. Projects within our foundation are independent, and may create additional and even contradictory stances to what is written here.
+
+# Author Responsibility
+
+The human submitting a pull request is considered the author and is fully responsible for the code they contribute. Our code contribution policy is quite clear \- you must sign the DCO (Developer Certificate of Origin) with a valid email address and name, and have completed the appropriate version of a Contributor License Agreement (if applicable) before your code will be reviewed and/or merged. By signing and posting a PR, you as the author are stating that the code you submit follows the licensing and authorship rules of the project, the ASWF, and the Linux Foundation. The PR author should understand, be able to converse around, and explain their submission. There is nothing new about this policy, and no exceptions will be made. 
+
+# Disclosure
+
+Another aspect of author responsibility is disclosure. It has long been a best practice to disclose the process, inspiration, and research used in your code submission. In the same way, we now require disclosure of tools used, including agentic coding solutions and AI. This can be as simple as “this PR was assisted by X tool to aid in Y and Z”. Maintainers might ask follow up questions, and as noted above, authors should be prepared to defend their solutions. 
+
+This requirement is not meant to dissuade use of AI-assisted tools \- the opposite. We are interested in learning how these new technologies are being used in Foundation projects. This disclosure is therefore useful to us in more ways than one: it encourages good code contribution practices and enables us to track their use. This in turn helps us evolve, stay current and use data to help drive future decisions. 
+
+# Respect Maintainers
+
+Being a maintainer of an open-source software repository is often a thankless job. The folks that do it are passionate and knowledgeable about their craft.  The standard for submissions to ASWF projects is high, and will only continue to grow as the tools and technology aiding developers get better. We expect contributors to be considerate, thoughtful, and communicative. Any contributions with evidence of exploitive or extractive elements will not be tolerated. This includes but is not limited to: lack of testing, understanding, or explanation of the contribution, using bots or other automated tooling to communicate in place of a human author, or work obviously not in the process or style of the project. A goal of a great contribution should be to make a maintainer’s life easier, not harder.
+
+# Learning & Collaboration
+
+At the core of its mission, the ASWF strives to be a neutral forum where folks can collaborate safely, freely, and creatively. We pride ourselves on being giving with our time and knowledge, to newcomers and old hats alike. To that end, we expect contributors to foster and grow that environment. Software and the way we create code may be changing, but that should be viewed as an opportunity to increase learning, not to be lazy. Shortcuts taken to an end rarely help anyone, most importantly new contributors looking to grow. We encourage all contributors to explore new technology developments (that is also learning\!) to create a workflow and toolset that works best for their growth \- but don’t use it as a crutch. 
+
+# Conclusion
+
+If you’ve read this far and are thinking “wait, I still don’t know what their policy on AI generated code is” \- that’s technically correct. That is not the purpose of this document. That policy should be decided on a project level, and may change frequently \- just as technology does. While we may add more to this document over time, the basic philosophy should serve as a guiding and testing framework for policy in individual projects and contributors. However, here’s a quick summary:
+
+* Humans are responsible for code contributions \- and they must be able to explain the work.  
+* Explicitly state if AI assistance was used in a contribution, and for what purpose.  
+* Submit high-quality, tested code. Bot-generated noise or low-effort PRs are a distraction, not a help.  
+* Use new technology to enhance your skills and workflow, not as a shortcut to avoid understanding the code.  
+* Be flexible: individual projects will set their own specific AI-coding policies.