--- .title = "Contributing", .date = @date("2025-07-06T00:00:00"), .author = "Igor Támara", .layout = "tutorial.shtml", .draft = false, .custom = { .githubedit = "/docs/contributing.smd", } --- []($section.id("request")) ## Asking for a feature Please [open an issue](https://github.com/neurocyte/flow/issues) 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](https://discord.com/invite/4wvteUPphx) 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. []($section.id("issues")) ## Reporting a problem If you discover a problem, or unexpected behaviour, feel free to join [Discord](https://discord.com/invite/4wvteUPphx) to check if there is a simple way to overcome the inconvenience or to get some guidance. [Reporting a bug](https://github.com/neurocyte/flow/issues) is a good way to contribute. When reporting one, it should contain: * Flow version. You get it with `flow --version` * What you were doing, if possible, step by step to reproduce it * What actually happened * What was expecting to happen * Any other information, like screenshots, video, screencast, the platform allows to add that information. Issues later on are tagged with proposed version to solve them, in case of low hanging fruit, it's possible that it can be solved pretty quick. []($section.id("showcase")) ## Help others and share your workflows We are happy when you [share your workflows](https://discord.gg/XeYatDhh) or when someone asks something and gets a helpful answer, for example, a 30 sec video is really helpful because it exactly shows how something can be achieved. Use [asciinema](https://asciinema.org/) or whatever allows others to see how you get things done. Spreading the word is another way to contribute to Flow Code growth, making blog entries and sharing with others what you can build or achieve with flow; battle testing flow on daily basis helps its improvement and bring ideas from other places too. []($section.id("developing")) ## Developing [Flow Control](https://flow-control.dev/) is programmed with [zig](https://ziglang.org/). [Fork](https://github.com/neurocyte/flow/fork), no worries in case there is something with gh, if you happen to use [codeberg](https://codeberg.org/neurocyte/flow), or [sourcehut](https://git.sr.ht/~neurocyte/flow), it's possible to contribute via those services too. Using [Discord](https://discord.com/invite/4wvteUPphx) is a good starting point to discuss about what you are about to offer, or if you decide to pick an open issue, is a good practice first commenting in one of the channels to get some feedback and get to agreements or find guidance. This [summary](/docs/architecture) can help on getting started to follow the codebase. []($section.id("coding_style")) ### Coding style 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](https://deepwiki.com/neurocyte/flow); if you find something inaccurate in this doc or others, do open an issue or jump to [Discord](https://discord.com/invite/4wvteUPphx) and comment, it's valid to [improve too](https://github.com/neurocyte/flow-website/tree/master/content/docs/contributing.smd"). []($section.id("commits")) ### Commit comments 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 committers. * `fix:` When something changed to a more expected behaviour. * `build`: the commit doesn't change code at all. []($section.id("testing")) ### Testing 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. If you are new to zig a good place to start to learn about the codebase is [adding some tests](/docs/testing) []($section.id("resources")) ## Resources * [nerd fonts cheatsheet](https://www.nerdfonts.com/cheat-sheet): When icons are needed, you can look for them. * [logging](/docs/architecture#logging): When developing flow and need to trace some messages. * [showing key-presses](/docs/architecture#show_input): When the keyboard don't seem to work. []($section.id("next")) ## Next steps * [Join Discord](https://discord.com/invite/4wvteUPphx) * [Fill an issue](https://github.com/neurocyte/flow/issues) * [Add some tests](/docs/testing) * [Back to architecture](/docs/architecture)