Please open an issue that explains what is the requirement, being as descriptive as possible. First review other issues in case someone already requested the feature, or join Discord to ask for more information. At the end, the issues in github have more chance to get developed, given that there are plenty of things to do for this kind of software.
If you discover a problem, or unexpected behaviour, feel free to join Discord to check if there is a simple way to overcome the inconvenience or to get some guidance. Reporting a bug is a good way to contribute. When reporting one, it should contain:
flow --versionIssues later on are tagged with proposed version to solve them, in case it’s a low hanging fruit, it’s possible that it can be solved pretty quick.
Spreading the word is another way to contribute to Flow Code growth.
Flow Control is programmed with zig.
Fork, no worries, if you happen to use codeberg, or sourcehut, it’s possible to fork and contribute via those services too.
Discussing via Discord is a good start to talk about what you are about to offer, or if you decide to pick an open issue, is a good practice first opening an issue and commenting in one of the channels to get some feedback and get to agreements or find guidance.
This summary can help on getting started to follow the codebase.
Please follow what you see in the source code for functions, Structs, variables, const names, etc… Functions have descriptive names to use less time adding and maintaining comments to communicate the purpose and intent. Don’t worry about commenting each function, module or parameter, there are automated tools that are currently helping with this, take a peek on deepwiki, if you find something inaccurate in those docs or others, do open an issue or jump in Discord and comment.
It’s better to use commits for different purposes, even if they look small and there is a temptation to include on the same new code, fixes and refactors. Making concise and self contained commits make review easier and future fixes possible, in case of need.
Use these prefixes as much as you can, doing so helps when identifying the features and eases the process of letting others know about what’s new, fixed and help communicate better when releasing.
feat: when there is a new feature, if specific to a mode, please use feat: [mode].refactor: when reorganizing code, usually when you make something clearer for future readers and commiters.fix: When something changed to a more expected behaviour.build: the commit doesn’t change code at all.It’s possible that the test set grows as the project evolves, given that the amount of relationships among components increase the opportunity to generate regressions.
Discord and Github issues are the main channels to do so.