This document outlines the general contribution guidelines that apply to WinRocket.
Tip
If you're new to open source, the Open Source Etiquette is an excellent read that you should check out before reading the rest of this document.
Important
Basic familiarity with Git and GitHub is required: If you are also new to these tools, visit GitHub for complete beginners for a comprehensive introduction to them.
-
Avoid vibe-coding large features - While probably most of us use AI while coding in our day to day lives, you should try to use it in a clever and targetted manner. Avoid submitting large vibe-coded features, because in 99% of the cases they will not behave as expected. These kinds of PR-s drain our energy and time that could be focused on something more useful, because what took a few seconds for the AI assistant to pump out will take us hours to test, discuss, and ultimately scrap because it doesn't take into account half the things a real programmer probably would. If you made heavy use of AI in your pull request, indicate it.
-
Do not break existing code - WinRocket aims to provide a seamless user experience, so please avoid the breakage of any existing features to the best of your abilities. Ensure that folks potentially upgrading to a new version that includes your changes won't have any problems, and address any migrations if they're required.
-
Do rigorous testing - WinRocket is used by tens of thousands of folks every day on a wide range of Linux distros, make sure that the PR you submit doesn't break compatibility on any of the mainstream distros.
-
If you're unsure, ask - If you want to start working on something large that you then intend for us to merge into WinRocket, it may be worth asking us first in an issue to understand if the feature is compatible with the philosophy of WinRocket and whether we want to include it. The same idea applies if you're unsure how to implement a feature in a way that's compatible with how WinRocket operates.
-
Avoid introducing new programming languages - WinRocket uses TypeScript & Vue for the Electron app, and Go & PowerShell for the Guest Server. Use these for getting things done.
-
Avoid introducing new foreign dependencies - Chances are there's an NPM / Go package for what you're trying to achieve or at least something similar. If there isn't, and it's a must to include it, discuss with us first.
Before contributing, you should always create a personal fork of WinRocket, where you can create a dedicated branch for the changes you're aiming to make. Once you're finished with your changes, you can go ahead and create a PR aiming to merge your changes to WinRocket's main branch. If you're still in the process of development, but you'd still like to open a PR for visibility or discussion, make sure that you open a draft PR instead.
Branch naming convention: Use descriptive names like feat/your-feature-name or fix/issue-description
Your PR title should include what it's trying to do, e.g. feat: Add VNC port into Configuration, while the description should outline it in more detail, potentially explaining how the feature works, details on the implementation, and/or why the feature is useful.
Make sure you reference any issues that are potentially linked to your Pull Request using GitHub's keywords, either via comments or commit messages.
WinRocket generally uses the Conventional Commits naming scheme. You should aim to stick to these conventions whenever possible.
After you've submitted your changes as a PR, a maintainer may request changes to your code before merging. If everything goes well, your PR will be merged and shipped in the next version of WinRocket.
In case we find issues later on, the PR commits might be reverted and additional discussion will take place in the PR thread or a separate issue.