l3ocho
11b6be87c8
✅ Task 1.1 - Project Foundation Setup: - Repository structure with Python packaging (setup.py, pyproject.toml) - Development dependencies and requirements - Contributing guidelines and MIT license - GitHub workflows for CI/CD (test.yml, release.yml) - Issue and PR templates for community contributions - Comprehensive project documentation ✅ Task 1.2 - Core Client Structure: - wikijs package with proper module organization - Core client class foundation in client.py - Exception hierarchy for error handling - Base model classes and page models - Type checking support (py.typed) - Utility modules and helper functions 📊 Progress: Phase 1 MVP Development now 40% complete 🎯 Next: Task 1.3 - Authentication System implementation 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
187 lines
6.0 KiB
Markdown
187 lines
6.0 KiB
Markdown
# Wiki.js Python SDK - Community Governance
|
|
|
|
**Project**: wikijs-python-sdk
|
|
**Stage**: MVP Development
|
|
**Version**: 1.0
|
|
**Last Updated**: July 2025
|
|
|
|
---
|
|
|
|
## 🎯 Mission Statement
|
|
|
|
Create a high-quality Python SDK for Wiki.js that serves developers' needs while fostering an inclusive, collaborative community.
|
|
|
|
**Core Values:**
|
|
- **Quality**: Prioritize working code and user experience
|
|
- **Simplicity**: Keep processes lightweight and focused
|
|
- **Community**: Welcome contributors of all experience levels
|
|
- **Transparency**: Open development with clear communication
|
|
|
|
---
|
|
|
|
## 👥 Project Roles
|
|
|
|
### **Maintainer**
|
|
**Current**: Project Lead
|
|
**Responsibilities:**
|
|
- Project direction and roadmap decisions
|
|
- Code review and merge approval
|
|
- Release management
|
|
- Community support and issue triage
|
|
|
|
**Authority:**
|
|
- Final decision on feature additions
|
|
- Merge rights to main branch
|
|
- Create releases and manage PyPI publishing
|
|
|
|
### **Contributors**
|
|
**Anyone participating in the project**
|
|
**How to Contribute:**
|
|
- Report bugs with clear reproduction steps
|
|
- Suggest features with use cases
|
|
- Submit pull requests following our standards
|
|
- Help answer questions in discussions
|
|
- Improve documentation and examples
|
|
|
|
**Recognition:**
|
|
- All contributors listed in CONTRIBUTORS.md
|
|
- Significant contributors highlighted in releases
|
|
- Path to maintainer role for consistent contributors
|
|
|
|
---
|
|
|
|
## 🚀 Development Process
|
|
|
|
### **Issue Management**
|
|
1. **Bug Reports**: Use issue templates with reproduction steps
|
|
2. **Feature Requests**: Describe use case and expected behavior
|
|
3. **Questions**: Use GitHub Discussions for general help
|
|
4. **Priority**: Focus on MVP completion, then community feedback
|
|
|
|
### **Pull Request Process**
|
|
1. **Fork & Branch**: Create feature branch from `main`
|
|
2. **Develop**: Follow coding standards and write tests
|
|
3. **Test**: Ensure all tests pass and coverage maintained
|
|
4. **Review**: Maintainer reviews and provides feedback
|
|
5. **Merge**: Approved changes merged to main
|
|
|
|
### **Release Process**
|
|
- **Version**: Semantic versioning (MAJOR.MINOR.PATCH)
|
|
- **Frequency**: Regular releases based on feature completion
|
|
- **Testing**: All quality gates must pass before release
|
|
- **Communication**: Release notes published with each version
|
|
|
|
---
|
|
|
|
## 📋 Quality Standards
|
|
|
|
### **Code Requirements**
|
|
- **Tests**: All new features must include tests
|
|
- **Coverage**: Maintain >85% test coverage
|
|
- **Types**: Type hints required for public APIs
|
|
- **Style**: Follow black, isort, flake8 formatting
|
|
- **Documentation**: Docstrings for all public methods
|
|
|
|
### **Review Criteria**
|
|
- [ ] Code follows established patterns
|
|
- [ ] Tests cover new functionality
|
|
- [ ] Documentation updated if needed
|
|
- [ ] No breaking changes without discussion
|
|
- [ ] Performance impact considered
|
|
|
|
---
|
|
|
|
## 🤝 Community Guidelines
|
|
|
|
### **Expected Behavior**
|
|
- Be respectful and constructive in all interactions
|
|
- Focus on the code and ideas, not the person
|
|
- Welcome newcomers and help them get started
|
|
- Share knowledge and learn from others
|
|
- Assume good intentions in communications
|
|
|
|
### **Unacceptable Behavior**
|
|
- Personal attacks or harassment
|
|
- Discriminatory language or behavior
|
|
- Trolling or intentionally disruptive behavior
|
|
- Sharing private information without consent
|
|
|
|
### **Enforcement**
|
|
- **Level 1**: Private discussion with maintainer
|
|
- **Level 2**: Public warning and guidance
|
|
- **Level 3**: Temporary restriction from participation
|
|
- **Level 4**: Permanent ban (only for severe violations)
|
|
|
|
Report issues to: [Maintainer Contact] - all reports handled confidentially.
|
|
|
|
---
|
|
|
|
## 📞 Communication Channels
|
|
|
|
### **GitHub Issues**
|
|
- Bug reports and feature requests
|
|
- Project planning and roadmap discussions
|
|
- Technical questions about implementation
|
|
|
|
### **GitHub Discussions** *(Coming Soon)*
|
|
- General help and usage questions
|
|
- Community showcase and success stories
|
|
- Brainstorming new ideas and improvements
|
|
|
|
### **Response Expectations**
|
|
- **Issues**: Response within 48-72 hours
|
|
- **Pull Requests**: Initial review within 1 week
|
|
- **Discussions**: Community-driven with maintainer backup
|
|
|
|
---
|
|
|
|
## 🔄 Decision Making
|
|
|
|
### **For MVP Development**
|
|
- **Maintainer Authority**: Final decisions on scope and implementation
|
|
- **Community Input**: Gathered through issues and discussions
|
|
- **Focus**: Complete MVP first, then expand based on feedback
|
|
|
|
### **Post-MVP Development**
|
|
- **Feature Requests**: Community voting and discussion
|
|
- **Breaking Changes**: Require community discussion period
|
|
- **Major Decisions**: Seek consensus among active contributors
|
|
|
|
---
|
|
|
|
## 📈 Growth & Evolution
|
|
|
|
### **Path to Contributor Recognition**
|
|
1. **First-time Contributors**: Welcomed and guided through process
|
|
2. **Regular Contributors**: Recognized in releases and documentation
|
|
3. **Core Contributors**: Trusted with triage and review responsibilities
|
|
4. **Maintainers**: Full project authority for proven long-term contributors
|
|
|
|
### **Governance Evolution**
|
|
This lightweight governance will evolve as the community grows:
|
|
- **10+ Contributors**: Add formal contributor guidelines
|
|
- **Community Growth**: Implement more structured decision processes
|
|
- **Multiple Maintainers**: Establish maintainer team processes
|
|
|
|
---
|
|
|
|
## 🚀 Getting Started
|
|
|
|
### **New Contributors**
|
|
1. **Read** this governance and project README
|
|
2. **Browse** open issues labeled `good first issue`
|
|
3. **Ask Questions** in GitHub Discussions
|
|
4. **Start Small** with documentation or test improvements
|
|
5. **Follow** the pull request process
|
|
|
|
### **Quick Links**
|
|
- **[Development Plan](wikijs_sdk_release_plan.md)**: Current roadmap and priorities
|
|
- **[Architecture](wikijs_sdk_architecture.md)**: Technical design overview
|
|
- **[CLAUDE.md](../CLAUDE.md)**: AI-assisted development workflow
|
|
- **[Contributing Guide](../CONTRIBUTING.md)**: Detailed contribution process *(Coming Soon)*
|
|
|
|
---
|
|
|
|
**Questions about governance?** Start a discussion or reach out to the maintainer directly. We're here to help and always open to improving our processes!
|
|
|
|
**Ready to contribute?** Check out our [current development priorities](wikijs_sdk_release_plan.md) and jump in! |