add a first draft of a template

Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>

Author: connortsui20

0000-template.md

@@ -0,0 +1,67 @@
+- Feature Name: (fill in with a unique identifier, e.g. `my_feature`)
+- Start Date: (today's date, YYYY-MM-DD)
+- RFC PR: [vortex-data/rfcs#0000](https://github.com/vortex-data/rfcs/pull/0000)
+- Tracking Issue: [vortex-data/vortex#0000](https://github.com/vortex-data/vortex/issues/0000)
+
+## Summary
+
+One paragraph explanation of the proposed change.
+
+## Motivation
+
+What problem does this solve? Include concrete use cases where possible.
+
+- What specific use cases does this enable or improve?
+- What workflows or operations are painful, slow, or impossible today?
+
+## Design
+
+Describe the proposed design in enough detail that someone familiar with Vortex could implement it. This should cover:
+
+- New or modified APIs, traits, or vtable entries.
+- How this interacts with existing components (encodings, layouts, scan, file format, etc.).
+- Key implementation details and corner cases.
+- Why is this the best approach in the space of possible designs?
+- Which crates are affected and how the dependency graph changes, if at all.
+
+Use code examples and diagrams where they might help.
+
+## Compatibility
+
+- Does this change the file format or wire format? Is it backward/forward compatible?
+- Does this break any public APIs? If so, what is the migration path?
+- Are there performance implications?
+
+If there are no compatibility concerns, briefly state why.
+
+## Drawbacks
+
+- Why should we _not_ do this?
+- What is the maintenance cost of this change?
+- Does this add complexity that could be avoided?
+
+## Alternatives
+
+- What other designs were considered and why were they rejected?
+- What is the cost of **not** doing this?
+- Is there a simpler approach that gets us most of the way there?
+
+## Prior Art
+
+How have other systems solved this or similar problems? Consider:
+
+- Other columnar formats (Parquet, Arrow, Lance, Nimble, etc.).
+- Database internals (DuckDB, DataFusion, Velox, etc.).
+- Relevant academic papers or blog posts.
+
+This section helps frame the design in a broader context. If there is no relevant prior art, that is fine.
+
+## Unresolved Questions
+
+- What parts of the design need to be resolved during the RFC process?
+- What is explicitly out of scope for this RFC?
+- Are there open questions that can be deferred to implementation?
+
+## Future Possibilities
+
+What natural extensions or follow-on work does this enable? This is a good place to note related ideas that are out of scope for this RFC but worth capturing.