Contributing
Thank you for considering contributing to Spade! This chapter contains some details on various things that are useful to know when contributing. When you inevitably have questions, reach out on Discord community or in the Matrix channel. (These are bridged, pick your favorite platform.)
Repositories
We are currently in the process of moving from gitlab.com to codeberg. For a while, the compiler and swim build tool will remain on GitLab (https://gitlab.com/spade-lang/), but many other projects have been migrated to (https://codeberg.org/spade-lang/).
What to Work On?
We are open to contributions of any kind: improvements and bug fixes to the compiler and build system of course, but also documentations, new functions in the standard library or even new cool libraries for the ecosystem.
In the compiler and build system, we have a good first issue label which we apply to issues which we think are solvable by someone new to the project. We are also more than happy to guide you through the implementation, just leave a comment in the issue or in the chat channels!
Contributor Documentation
The following pages may be useful when contributing:
Information on the tools available while working on the project:
Descriptions of how the compiler works:
AI Policy / LLM contributions
Contributions must not include content generated by large language models or other probabilistic tools, including but not limited to Copilot or ChatGPT. This policy covers code, documentation, pull requests, issues, comments, and any other contributions to the Spade project.
For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects. Our rationale is as follows:
Maintainer burden: Reviewers depend on contributors to write and test their code before submitting it. We have found that these tools make it easy to generate large amounts of plausible-looking code that the contributor does not understand, is often untested, and does not function properly. This is a drain on the (already limited) time and energy of our reviewers. In addition, reviewing a human contributed contribution not only brings N lines of code into the project, but helps mentor a potential future maintainer. An LLM coded contribution takes the same amount of effort to review, but only brings in the additional N lines of code.
Copyright issues: Publicly available models are trained on copyrighted content, both accidentally and intentionally, and their output often includes that content verbatim. Since the legality of this is uncertain, these contributions may violate the licenses of copyrighted works.
Ethical issues: LLMs require an unreasonable amount of energy to build and operate, their models are built with heavily exploited workers in unacceptable working conditions, and they are being used to undermine labor and justify layoffs. These are harms that we do not want to perpetuate, even if only indirectly.
Correctness: Even when code generated by LLMs does seem to function, there is no guarantee that it is correct. While both humans and AI can and will make mistakes, when a human makes a mistake there is someone available to ask about why a decision was made, and how code can be adapted to fix the issue in a way that does not cause future issues. With AI, there is no such opportunity.