chore: sync CONTRIBUTING.md from .github templates

evansims · evansims · commit c687811090fe · 2026-01-06T03:49:54.000-06:00
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,288 +1,59 @@
-# Contributing to InferaDB Control
+# Contributing to InferaDB
 
-Thank you for your interest in contributing to the InferaDB Control! This document provides guidelines and best practices for contributing to this project.
+Thank you for your interest in contributing to InferaDB! We welcome contributions from the community and are grateful for any help you can provide.
 
-## Getting Started
-
-1. **Fork the repository** on GitHub
-2. **Clone your fork** locally:
-
-   ```bash
-   git clone https://github.com/YOUR_USERNAME/inferadb.git
-   cd inferadb/management
-   ```
-
-3. **Set up your development environment** following the [README.md](./README.md)
-
-## Development Process
-
-### 1. Create a Feature Branch
-
-Always create a new branch for your work:
-
-```bash
-git checkout -b feature/your-feature-name
-```
-
-Branch naming conventions:
-
-- `feature/` - New features
-- `fix/` - Bug fixes
-- `docs/` - Documentation changes
-- `refactor/` - Code refactoring
-- `test/` - Test additions or improvements
-- `chore/` - Build process, dependency updates, etc.
-
-### 2. Follow the Implementation Plan
-
-Refer to [PLAN.md](./PLAN.md) for the phased implementation roadmap. Each phase has specific tasks and deliverables.
-
-### 3. Write Quality Code
-
-#### Code Style
-
-- Follow Rust idioms and best practices
-- Use `rustfmt` for formatting: `cargo fmt`
-- Address all `clippy` warnings: `cargo clippy -- -D warnings`
-- Write clear, descriptive variable and function names
-- Add documentation comments for public APIs
-
-#### Testing
-
-- Write unit tests for all new functionality
-- Add integration tests for API endpoints
-- Ensure all tests pass: `cargo test`
-- Aim for >80% code coverage
-
-Example test structure:
-
-```rust
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn test_function_name() {
-        // Arrange
-        let input = ...;
-
-        // Act
-        let result = function_to_test(input);
-
-        // Assert
-        assert_eq!(result, expected);
-    }
-
-    #[tokio::test]
-    async fn test_async_function() {
-        // ...
-    }
-}
-```
-
-#### Error Handling
-
-- Use the `Result` type for operations that can fail
-- Provide meaningful error messages
-- Use the error types defined in `inferadb-control-core::error`
-
-#### Documentation
-
-- Add Rustdoc comments for all public APIs:
-
-  ````rust
-  /// Brief description of the function
-  ///
-  /// # Arguments
-  ///
-  /// * `param1` - Description of param1
-  ///
-  /// # Returns
-  ///
-  /// Description of return value
-  ///
-  /// # Errors
-  ///
-  /// Description of possible errors
-  ///
-  /// # Examples
-  ///
-  /// ```
-  /// use crate::module::function;
-  /// let result = function(arg);
-  /// ```
-  pub fn function(param1: Type) -> Result<ReturnType> {
-      // ...
-  }
-  ````
-
-### 4. Commit Your Changes
-
-#### Commit Message Format
-
-Follow [Conventional Commits](https://www.conventionalcommits.org/):
-
-```text
-<type>(<scope>): <subject>
-
-<body>
-
-<footer>
-```
-
-Types:
-
-- `feat`: New feature
-- `fix`: Bug fix
-- `docs`: Documentation changes
-- `style`: Code style changes (formatting, etc.)
-- `refactor`: Code refactoring
-- `test`: Test additions or improvements
-- `chore`: Build process, dependency updates
-
-Examples:
-
-```text
-feat(auth): implement password authentication
-
-Add password-based authentication with Argon2id hashing.
-Includes rate limiting and session management.
+## Code of Conduct
 
-Closes #123
-```
+This project and everyone participating in it is governed by the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to [open@inferadb.com](mailto:open@inferadb.com).
 
-```text
-fix(storage): handle FoundationDB connection timeout
+## How to Contribute
 
-Add retry logic with exponential backoff for FDB connections.
-```
+### Reporting Issues
 
-### 5. Push and Create a Pull Request
+- **Bug Reports**: Search existing issues first to avoid duplicates. Include version information, steps to reproduce, expected vs actual behavior, and relevant logs.
+- **Feature Requests**: Describe the use case, proposed solution, and alternatives considered.
+- **Security Issues**: Do **not** open public issues for security vulnerabilities. Instead, email [security@inferadb.com](mailto:security@inferadb.com).
 
-```bash
-git push origin feature/your-feature-name
-```
+### Pull Requests
 
-Then create a pull request on GitHub with:
+1. **Fork the repository** and create your branch from `main`
+2. **Follow the development workflow** documented in the repository's README
+3. **Write clear commit messages** following [Conventional Commits](https://www.conventionalcommits.org/):
+   - `feat:` New features
+   - `fix:` Bug fixes
+   - `docs:` Documentation changes
+   - `test:` Test additions or improvements
+   - `refactor:` Code refactoring
+   - `chore:` Maintenance tasks
+4. **Ensure all tests pass** before submitting
+5. **Update documentation** if your changes affect public APIs or user-facing behavior
+6. **Submit a pull request** with a clear description of your changes
 
-- Clear title describing the change
-- Description of what changed and why
-- Reference to related issues (e.g., "Closes #123")
-- Screenshots or examples if applicable
+### Development Setup
 
-## Pull Request Checklist
+Each repository has its own development setup and workflow. Please refer to:
 
-Before submitting a PR, ensure:
+- **[DEVELOPMENT.md](./DEVELOPMENT.md)** for repository-specific development and contribution guidance
+- **README.md** for general project information and quick start instructions
 
-- [ ] Code follows Rust style guidelines (`cargo fmt`)
-- [ ] All clippy warnings are addressed (`cargo clippy -- -D warnings`)
-- [ ] All tests pass (`cargo test`)
-- [ ] New functionality has tests
-- [ ] Documentation is updated (if applicable)
-- [ ] Commit messages follow Conventional Commits
-- [ ] PR description clearly explains the changes
+These documents cover prerequisites, dependencies, build commands, code style guidelines, and repository-specific requirements.
 
-## Code Review Process
+## Review Process
 
 1. **Automated Checks**: CI will run tests, linters, and formatters
-2. **Peer Review**: At least one maintainer will review your code
+2. **Peer Review**: At least one maintainer will review your contribution
 3. **Feedback**: Address any review comments
-4. **Approval**: Once approved, a maintainer will merge your PR
-
-## Development Guidelines
-
-### Security
-
-- Never commit secrets or credentials
-- Use environment variables for sensitive configuration
-- Follow secure coding practices (input validation, SQL injection prevention, etc.)
-- Report security vulnerabilities privately to <security@inferadb.com>
-
-### Performance
-
-- Profile code for performance-critical paths
-- Avoid unnecessary allocations
-- Use async/await properly to avoid blocking
-- Cache expensive operations when appropriate
-
-### Multi-Tenancy
-
-- Always validate organization/vault access
-- Ensure data isolation between organizations
-- Test cross-tenant access attempts
-
-### API Design
-
-- Follow RESTful conventions
-- Use appropriate HTTP status codes
-- Provide clear error messages
-- Version APIs when making breaking changes
-
-## Testing
-
-### Running Tests
-
-```bash
-# All tests
-cargo test
-
-# Specific package
-cargo test --package inferadb-control-core
-
-# Specific test
-cargo test test_name
-
-# With output
-cargo test -- --nocapture
-
-# Integration tests only
-cargo test --test '*'
-```
-
-### Test Coverage
-
-```bash
-# Install tarpaulin
-cargo install cargo-tarpaulin
-
-# Generate coverage report
-cargo tarpaulin --out Html
-```
-
-## Documentation
-
-### Generating Documentation
-
-```bash
-# Generate and open docs
-cargo doc --no-deps --open
-
-# Include private items
-cargo doc --no-deps --document-private-items
-```
-
-### Updating Architecture Docs
-
-When adding new features or making architectural changes, update:
-
-- [OVERVIEW.md](./OVERVIEW.md) - Entity definitions and behavioral rules
-- [AUTHENTICATION.md](./AUTHENTICATION.md) - Authentication flows
-- [PLAN.md](./PLAN.md) - Implementation roadmap
-
-## Getting Help
-
-- **GitHub Issues**: For bugs and feature requests
-- **Discussions**: For questions and general discussion
-- **Documentation**: Check [README.md](./README.md) and [OVERVIEW.md](./OVERVIEW.md)
+4. **Approval**: Once approved, a maintainer will merge your contribution
 
 ## License
 
-By contributing to this project, you agree that your contributions will be licensed under the BSL 1.1 License.
+By contributing to InferaDB, you agree that your contributions will be licensed under the same license as the repository you are contributing to. See the LICENSE file in each repository for details.
 
-## Code of Conduct
+## Questions?
 
-Please be respectful and professional in all interactions. We are committed to providing a welcoming and inclusive environment for all contributors.
+If you have questions or need help:
 
-## Thank You
+- Open a [Discussion](https://github.com/inferadb/inferadb/discussions) on GitHub
+- Email us at [open@inferadb.com](mailto:open@inferadb.com)
 
-Your contributions help make InferaDB better for everyone. We appreciate your time and effort!
+Thank you for helping make InferaDB better!
