-
Notifications
You must be signed in to change notification settings - Fork 135
Description
This issue is mostly targeted for people who would like to make a first contribution to Vortex (or to an open-source project in general) but don't really know where to start.
We have been generating / refactoring / moving around quite a lot of code over the past few months. Unsurprisingly, this has caused code quality (as in documentation, testing, modularity) to not be ideal in some cases.
Here are some things that we would like but not a lot of us have the bandwidth for:
- Document / comment code that has insufficient explanation for someone to understand on a first pass.
- Clean up tests by either deleting bad tests or documenting what good tests do. We have quite a lot of LLM-generated tests that basically do not test anything meaningful, and we have often seen that some tests are completely incorrect (i.e. they test that the incorrect behavior is still incorrect).
- Rename any confusing internal (not public) types, variables, functions, etc. Many concepts / names that make sense to the maintainers who work on this every day might be incredibly confusing to a newcomer. If you are confused about something, please open a discussion and maybe we can make understanding it easier.
- Make sure code is modular. This could be as simple as extracting logic out of huge functions!
Note that we prefer smaller PRs over large ones, and we are happy to review and merge PRs that just add 20 or so lines of documentation. Feel free to open a PR, no need to claim anything. Here are some examples of small PRs improving quality:
- pvalue::cast returns VortexResult #6532
- chore: fix typos in PR template #6550
- chore: make auto
clang-formatconsistent #6568 - More detailed backcompat comments #6609
If you are unsure of where to first start looking, start with the code at either vortex-array/src/arrays or the crates in encodings/. You can also head over to our public Slack channel and ask us any questions you have!