Add GPy community-driven development tenet

- Establish principle that GPy belongs to the community, not any single person
- Emphasize community consensus over individual preferences
- Clarify that community-driven means balanced, respectful collaboration
- Address conflicts between expertise and new perspectives
- Provide examples of good and bad practices for community decision-making

tenets/community-driven-development.md

@@ -0,0 +1,51 @@
+---
+id: "community-driven-development"
+title: "Community-Driven Development"
+created: "2025-08-15"
+last_updated: "2025-08-15"
+version: "1.0"
+tags:
+- tenet
+- community
+- collaboration
+- governance
+---
+
+# Community-Driven Development
+
+## Tenet
+
+*Description*: GPy is a community-driven project. All significant decisions, architectural changes, and new features should be driven by community consensus and needs rather than individual preferences. The project belongs to its users, contributors, and maintainers, not to any single person or organization. Community-driven does not mean that any single voice can veto progress - it means respectful debate, evidence-based discussion, and balanced decision-making that considers both long-term contributors' expertise and broader community needs. This principle ensures GPy remains relevant, sustainable, and truly useful to the broader machine learning community.
+
+*Quote*: *"The community owns the project, not the creator"*
+
+*Examples*:
+- Proposing new features through open discussion and gathering community feedback before implementation
+- Creating RFCs (Request for Comments) for major architectural changes and waiting for community consensus
+- Prioritizing bug fixes and features based on community needs rather than personal preferences
+- Involving multiple maintainers and contributors in important decisions
+- Using structured processes like CIPs (Code Improvement Plans) to document decisions and their rationale
+- Respecting the expertise of long-term contributors while remaining open to new perspectives
+- Engaging in evidence-based debates rather than opinion-based arguments
+- Finding compromise solutions that address multiple community concerns
+
+*Counter-examples*:
+- Implementing major changes without community discussion or consensus
+- Prioritizing features based solely on personal interest without considering user needs
+- Making unilateral decisions about project direction without community input
+- Ignoring feedback from long-time contributors and maintainers
+- Rushing changes through without proper review and discussion
+- Allowing any single voice to block progress without providing constructive alternatives
+- Dismissing concerns from new contributors simply because they're new
+- Engaging in personal attacks or dismissive behavior during debates
+- Refusing to compromise or find middle-ground solutions
+
+*Conflicts*:
+- *Conflict*: Need for rapid development vs. community consensus building
+- *Resolution*: Use time-boxed discussions, clear decision-making processes, and temporary implementations that can be refined based on feedback
+- *Conflict*: Technical excellence vs. community accessibility
+- *Resolution*: Strive for both by providing clear documentation, gradual migration paths, and maintaining backward compatibility where possible
+- *Conflict*: Long-term contributor expertise vs. new contributor perspectives
+- *Resolution*: Value both - use expertise to guide decisions while remaining open to fresh insights and approaches
+- *Conflict*: Individual preferences vs. community consensus
+- *Resolution*: Use evidence, user needs, and project sustainability as the primary decision criteria, not personal preferences