add OSS project scaffolding

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,35 @@
+---
+name: Bug Report
+about: Report a bug to help us improve
+title: ''
+labels: bug
+assignees: ''
+---
+
+## Description
+
+A clear description of the bug.
+
+## Steps to Reproduce
+
+1.
+2.
+3.
+
+## Expected Behavior
+
+What you expected to happen.
+
+## Actual Behavior
+
+What actually happened.
+
+## Environment
+
+- OS:
+- Rust version:
+- OpenData version/commit:
+
+## Additional Context
+
+Any other relevant information (logs, screenshots, etc.).

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,27 @@
+---
+name: Feature Request
+about: Suggest a new feature or improvement
+title: ''
+labels: enhancement
+assignees: ''
+---
+
+## Summary
+
+A brief description of the feature.
+
+## Motivation
+
+What problem does this solve? Why is it needed?
+
+## Proposed Solution
+
+How do you think this should work?
+
+## Alternatives Considered
+
+Any other approaches you've thought about.
+
+## Additional Context
+
+Any other relevant information.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,18 @@
+## Summary
+
+What does this PR do?
+
+## Related Issues
+
+Fixes #
+<!-- or: Relates to # -->
+
+## Test Plan
+
+How was this tested?
+
+## Checklist
+
+- [ ] Tests added/updated
+- [ ] `cargo fmt` and `cargo clippy` pass
+- [ ] Documentation updated (if applicable)

CONTRIBUTING.md

@@ -0,0 +1,155 @@
+# Contributing to OpenData
+
+Thank you for your interest in contributing to OpenData! We welcome contributions from the community.
+
+## Table of Contents
+
+- [Getting Started](#getting-started)
+- [How to Contribute](#how-to-contribute)
+- [RFCs](#rfcs)
+- [Development Setup](#development-setup)
+- [Code Style](#code-style)
+- [Testing](#testing)
+- [Pull Request Process](#pull-request-process)
+
+## Getting Started
+
+OpenData is a Rust workspace containing multiple crates:
+
+- `common` - Shared components and utilities
+- `tsdb` - Object storage-native timeseries database
+- `log` - Object storage-native event streaming backend
+
+Before contributing, we recommend reading the [README](README.md) to understand the project architecture and looking at existing issues and pull requests.
+
+## How to Contribute
+
+### Reporting Bugs
+
+Open an issue with:
+
+- Steps to reproduce the issue
+- Expected vs actual behavior
+- Your environment (OS, Rust version)
+- Relevant logs or error messages
+
+### Suggesting Features
+
+Open an issue describing:
+
+- The feature and the problem it solves
+- Any implementation ideas (optional)
+
+### Contributing Code
+
+1. For significant changes, open an issue or RFC first to discuss your approach
+2. Fork the repository and create a branch for your work
+3. Write code and tests
+4. Submit a pull request
+
+A maintainer will review the PR as soon as we have availability! 
+
+## RFCs
+
+Major changes require an RFC (Request for Comments) before implementation. This includes:
+
+- New database types
+- Changes to the storage, query, or metadata layers
+- New APIs or breaking API changes
+- Architectural changes affecting multiple crates
+- New dependencies on external systems
+
+### RFC Process
+
+1. Copy the [RFC template](rfcs/0000-template.md) to the appropriate directory:
+   - `rfcs/` - For cross-project or architectural changes
+   - `<project>/rfcs/` - For project-specific changes (e.g., `open-tsdb/rfcs/`)
+2. Name the file `NNNN-short-description.md` where `NNNN` is the next available number
+3. Fill out the template sections:
+   - **Summary** - Brief description of the proposal
+   - **Motivation** - The problem being solved and why it matters
+   - **Design** - Detailed explanation of the proposed solution
+   - **Alternatives** - Other approaches considered and why they were rejected
+   - **Open Questions** - Unresolved issues for discussion
+4. Submit a pull request with the RFC
+5. Maintainers and community members will provide feedback on the PR
+6. Once the RFC is approved by two maintainers and merged, implementation can begin
+7. Reference the RFC in any implementing PRs
+
+For bug fixes, documentation, and minor features, skip the RFC and go straight to a PR.
+
+## Development Setup
+
+### Prerequisites
+
+- Rust stable toolchain ([rustup](https://rustup.rs/))
+- Git
+
+### Building
+
+```bash
+git clone https://github.com/opendata-oss/opendata.git
+cd opendata
+
+cargo build --all-targets
+cargo test --all
+```
+
+## Code Style
+
+### Formatting
+
+Run `cargo fmt` before committing:
+
+```bash
+cargo fmt --all
+```
+
+### Linting
+
+All code must pass clippy with no warnings:
+
+```bash
+cargo clippy --all-targets --all-features -- -D warnings
+```
+
+### Guidelines
+
+- Follow Rust naming conventions
+- Write clear, self-documenting code
+- Add comments for complex logic
+- Prefer returning `Result` for fallible operations
+
+## Testing
+
+Include tests for new functionality.
+
+### Test Style
+
+Use the `should_` prefix and given/when/then pattern:
+
+```rust
+#[test]
+fn should_return_error_when_input_is_invalid() {
+    // given
+    let input = "invalid";
+
+    // when
+    let result = process(input);
+
+    // then
+    assert!(result.is_err());
+}
+```
+
+### Running Tests
+
+```bash
+cargo test --all                    # Run all tests
+cargo test --all -- --nocapture     # Run with output
+cargo test -p open-tsdb             # Run tests for a specific crate
+```
+
+## License
+
+By contributing, you agree that your contributions will be licensed under the [MIT License](LICENSE).

GOVERNANCE.md

@@ -0,0 +1,43 @@
+# OpenData Governance
+
+This document describes the governance model for the OpenData project.
+
+## Current Status
+
+OpenData is in its early stages. The governance structure described here is
+temporary and will be formalized as the project and community mature.
+
+## Committers
+
+Committers have write access to the repository and are responsible for reviewing
+and merging contributions.
+
+While bootstrapping the project, the following individuals have been granted
+commit access. If you are interested in becoming a founding commiter, please
+open a GitHub issue and one of us will schedule some time to review your
+background and evaluate your fit for the project.
+
+- [@agavra](https://github.com/agavra)
+- [@apurvam](https://github.com/apurvam)
+- [@cadonna](https://github.com/cadonna)
+- [@hachikuji](https://github.com/hachikuji)
+- [@rodesai](https://github.com/rodesai)
+
+## Decision Making
+
+- **Day-to-day decisions** (code review, minor features, bug fixes) are made by individual committers
+- **Significant changes** require an approved [RFC](CONTRIBUTING.md#rfcs) with sign-off from two committers
+- **Governance changes** require supermajority approval among all committers
+
+## Path to Committer
+
+Contributors who demonstrate sustained, high-quality contributions may be
+nominated for committer status. Factors considered include:
+
+- Quality and impact of contributions
+- Understanding of the project architecture and goals
+- Constructive participation in code reviews and discussions
+- Commitment to the project's long-term success
+
+Committer nominations are adopted by three +1 votes from existing committers
+and no -1 votes.

README.md

@@ -1,5 +1,10 @@
 # Overview
 
+<img src="https://github.com/opendata-oss/opendata/blob/main/public/github-banner.png?raw=true" alt="OpenData" width="100%">
+
+[![Discord](https://img.shields.io/badge/discord-join-7289DA?style=flat-square&logo=discord)](https://discord.gg/VsUK5FDj)
+[![GitHub License](https://img.shields.io/github/license/opendata-oss/opendata?style=flat-square)](LICENSE)
+
 OpenData is a collection of open source databases designed from ground up for object storage. We aim to deliver highly focused, objectstore-native versions of online databases that can power your application stack. As of today, we have a competitive timeseries database and a data streaming backend. We plan to ship vector search, text search, and other database types over time. Contributions are welcome!
 
 Building performant, cost-effective, and correct online systems on object storage takes special care. Successful designs all have to solve the problem of write batching, multiple levels of caching, and snapshot isolation for correctness. OpenData systems build on a common foundation to solve these problems. This common foundation gives OpenData systems a common set of operational tools, configuration systems, etc., that make our systems easier to operate in aggregate. 

rfcs/0000-template.md

@@ -0,0 +1,66 @@
+# RFC NNNN: Title
+
+**Status**: Draft | Under Review | Accepted | Rejected | Superseded
+
+**Authors**:
+- [Name](https://github.com/username)
+
+## Summary
+
+A brief (1-2 paragraph) description of the proposal. What is being proposed and
+why? This should be understandable without reading the rest of the document.
+
+## Motivation
+
+Why is this change needed? What problem does it solve? What use cases does it
+enable? Include any relevant background context that helps readers understand
+the motivation.
+
+## Goals
+
+- Specific goal 1
+- Specific goal 2
+
+## Non-Goals
+
+What is explicitly out of scope for this RFC? List items that might be assumed
+to be in scope but are intentionally deferred or excluded.
+
+- Non-goal 1 (left for future RFCs)
+- Non-goal 2
+
+## Design
+
+The detailed technical design. This is the core of the RFC and should be
+comprehensive enough for implementation.
+
+Break the design into logical subsections. Include:
+
+- Data structures and APIs
+- Algorithms and workflows
+- Code examples where helpful
+- Edge cases and error handling
+
+```rust
+// Example code blocks for API proposals
+struct Example {
+    field: Type,
+}
+```
+
+## Alternatives
+
+What other approaches were considered? Why were they rejected? This helps
+readers understand the design space and the reasoning behind the chosen
+approach.
+
+## Open Questions
+
+Optional section for unresolved questions that need input during the review
+process.
+
+## Updates
+
+| Date       | Description |
+|------------|-------------|
+| YYYY-MM-DD | Initial draft |