Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
379 lines (265 loc) · 8.43 KB

CONTRIBUTING.md

File metadata and controls

379 lines (265 loc) · 8.43 KB

Contributing to Vectoryon Platform Documentation

Thank you for your interest in contributing to Vectoryon! We welcome contributions from the community to help make this platform better for everyone.

🤝 How to Contribute

Ways to Contribute

  1. 📝 Improve Documentation

    • Fix typos and grammar
    • Add clarifications and examples
    • Translate documentation to other languages
    • Create tutorials and guides

  2. 🐛 Report Bugs

    • Document issues you encounter
    • Provide reproduction steps
    • Suggest potential fixes

  3. 💡 Suggest Features

    • Propose new capabilities
    • Share use cases
    • Discuss implementation approaches

  4. 🔧 Build Tools

    • Create example tools
    • Share tool templates
    • Contribute integration patterns

  5. 💬 Help Others

    • Answer questions in Issues
    • Share your experiences
    • Provide code reviews

🚀 Getting Started

1. Fork the Repository

Click the "Fork" button at the top of this repository.

2. Clone Your Fork

git clone https://github.com/YOUR_USERNAME/platform-docs.git
cd platform-docs

3. Create a Branch

git checkout -b feature/your-feature-name
# or
git checkout -b fix/your-bug-fix

4. Make Your Changes

  • Edit documentation files
  • Add examples or templates
  • Test your changes locally

5. Commit Your Changes

git add .
git commit -m "docs: Add explanation for multi-tenant architecture"

Commit Message Format:

  • docs: - Documentation changes
  • feat: - New features or examples
  • fix: - Bug fixes
  • chore: - Maintenance tasks

6. Push to Your Fork

git push origin feature/your-feature-name

7. Create a Pull Request

  • Go to the original repository
  • Click "New Pull Request"
  • Select your branch
  • Fill in the PR template
  • Submit for review

📋 Contribution Guidelines

Documentation Style

Writing Style:

  • ✅ Clear and concise
  • ✅ Beginner-friendly
  • ✅ Use examples liberally
  • ✅ Include code snippets
  • ✅ Link to related documentation

Formatting:

  • Use Markdown formatting
  • Add headings for structure
  • Use code blocks with syntax highlighting
  • Include emojis for visual clarity (optional)

Example:

## Setting Up Authentication

To configure OAuth authentication:

\`\`\`typescript
const authConfig = {
  provider: 'microsoft',
  clientId: process.env.OAUTH_CLIENT_ID,
  redirectUri: 'http://localhost:3000/api/auth/callback'
};
\`\`\`

**Important**: Never commit your client secrets to version control.

Code Examples

Best Practices:

  • ✅ Complete, runnable code
  • ✅ Include necessary imports
  • ✅ Add comments for clarity
  • ✅ Follow TypeScript best practices
  • ✅ Use realistic examples

Example:

// ✅ GOOD: Complete example with context
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  process.env.SUPABASE_URL!,
  process.env.SUPABASE_ANON_KEY!
);

const { data, error } = await supabase
  .from('workflows')
  .select('*')
  .eq('tenant_id', tenantId);

if (error) {
  console.error('Failed to fetch workflows:', error);
  return;
}

console.log('Workflows:', data);
// ❌ BAD: Incomplete, unclear
const data = await supabase.from('workflows').select('*');
console.log(data);

🔍 Review Process

What We Look For

Documentation PRs:

  1. Accuracy - Information must be correct
  2. Clarity - Easy to understand for target audience
  3. Completeness - Covers the topic thoroughly
  4. Consistency - Matches existing style and tone

Code Examples:

  1. Correctness - Code must work as shown
  2. Best Practices - Follows Vectoryon patterns
  3. Security - No vulnerabilities introduced
  4. Comments - Well-documented for learning

Timeline

  • Initial Review: Within 48 hours
  • Feedback: We'll provide constructive feedback
  • Merge: Once approved, we'll merge promptly

Feedback Examples

Constructive Feedback:

  • "Great start! Could you add an example showing error handling?"
  • "This is clear, but let's add a note about RLS policies here"
  • "Love the example! Can we also show the TypeScript types?"

We aim to be encouraging and helpful, not critical.

🐛 Reporting Bugs

Bug Report Template

When reporting bugs, please include:

**Description**
A clear description of the bug.

**Steps to Reproduce**
1. Go to '...'
2. Click on '...'
3. See error

**Expected Behavior**
What you expected to happen.

**Actual Behavior**
What actually happened.

**Environment**
- OS: [e.g., macOS 14, Ubuntu 22.04]
- Node Version: [e.g., 20.10.0]
- Browser: [e.g., Chrome 120]

**Screenshots**
If applicable, add screenshots.

**Additional Context**
Any other relevant information.

Security Vulnerabilities

⚠️ Do NOT open public issues for security vulnerabilities

Instead, email: security@kinnovations.ch

We take security seriously and will respond within 24 hours.

💡 Feature Requests

Feature Request Template

**Feature Description**
Clear description of the proposed feature.

**Use Case**
Why is this feature needed? What problem does it solve?

**Proposed Solution**
How should this feature work?

**Alternatives Considered**
What other approaches did you consider?

**Additional Context**
Any other relevant information, mockups, or examples.

Evaluation Criteria

We evaluate feature requests based on:

  1. Impact: How many developers benefit?
  2. Alignment: Fits with platform vision?
  3. Feasibility: Can we implement well?
  4. Maintenance: Sustainable long-term?

📜 License

By contributing, you agree that your contributions will be licensed under the same Business Source License 1.1 as the project.

What This Means

  • Your contributions become part of the project
  • Same BSL restrictions apply to your contributions
  • In 2029, your contributions become Apache 2.0 licensed
  • You retain copyright, but grant us usage rights

🎯 Contribution Ideas

Good First Issues

Looking for ways to contribute? Try these:

Documentation:

  • Add examples for workflow patterns
  • Create tutorial for first tool
  • Translate README to German/French/Italian
  • Add diagrams for architecture
  • Document common error messages

Examples:

  • Create minimal tool template
  • Build calendar integration example
  • Add CRM connector example
  • Create testing examples
  • Build deployment scripts

Community:

  • Answer questions in Issues
  • Review pending PRs
  • Share your tool implementations
  • Write blog posts about Vectoryon

💬 Communication

Channels

  • GitHub Issues: Bug reports, feature requests
  • Email: dev@kinnovations.ch
  • Pull Requests: Code and documentation contributions
  • Discord: Coming soon

Response Times

  • GitHub Issues: Within 48 hours
  • Pull Requests: Within 48 hours for initial review
  • Email: Within 24 hours (business days)

Be Respectful

We follow the Contributor Covenant Code of Conduct. Please be:

  • Respectful of differing viewpoints
  • Constructive in criticism
  • Focused on what's best for the community
  • Patient with maintainers and contributors

🏆 Recognition

Contributors

We recognize all contributors in:

  • Repository README (Contributors section)
  • Release notes for significant contributions
  • Community Discord (when launched)

Significant Contributions

Major contributors may receive:

  • Early access to new features
  • Direct communication channel with core team
  • Revenue share opportunities (marketplace launch 2026)
  • Public recognition in announcements

❓ Questions?

General Questions: dev@kinnovations.ch Contribution Help: Open an issue with "Question:" prefix License Questions: See LICENSE-EXPLAINED.md

🙏 Thank You!

Every contribution, no matter how small, helps make Vectoryon better for the entire community. We appreciate your time and effort!

Happy Contributing! 🚀

Last Updated: December 2, 2025