Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
36 lines (19 loc) · 4.76 KB

CONTRIBUTING.md

File metadata and controls

36 lines (19 loc) · 4.76 KB
Raw

Contributing to NotProton

Thank you for considering contributing code to NotProton. NotProton is a large undertaking. I'm happy to do it. Contributions can reduce the load and can make it easier to figure out what people want.

The NotProton contribution policy is fairly straightforward. It's primarily about being thoughtful with how you use development tools, not biting off more than you think you can chew, thinking carefully before and while you touch complex parts of NotProton and working together to make things better.

This policy is not a 'hard' policy. As in, I will review whatever is submitted regardless. I am not going to yell at someone for not following my precious requests. These are nice to haves, but they are not a true must, since I can always improve things regardless. I'm not a monster. I'm friendly, I swear.

Please do not let this document stop you from contributing to the project. I would much rather have a PR that is not perfect but is something I can work from versus nothing at all.

So, policies:

  1. If you are able to, please write the pull request description by hand. Translation is fine. Human text is easier for me to read and parse than text that was generated by software.

  2. Please check for previous closed PRs before opening a new PR, to avoid wasted work. Some features are not goals of this project, like adding support for Wine runtimes that are not CrossOver.

  3. I have a certain comment style. If you also have the same comment style, it reduces my work slightly. If not, no big deal. My style is this: short comments, inserted where the subject is complex. The idea being that the comments are aids for a human (me!) when evaluating the hard parts of the app.

  4. I much prefer comments in code to be human written, as parsing Claudisms is hard for humans (or at least for me). 'Does this comment help me understand what this logic does?' is a good rule to go by. If the comment requires additional knowledge that one would not naturally possess by reading the code in that individual file up until that point, I would try to rewrite the comment. Shorter is better than longer, but clarity is the true goal. Again, you do not need to do this.

You can comment your tests (if you introduce any with a PR) however you like.

  1. My responsibility is to understand how your code works and how it interacts with the rest of the code base. When I take a day and review PRs to merge, I review them to understand how they work, to see if the logic can be simplified, to test them deeply. This can cause a bit of a backlog, but I'm only human.

I review PRs for code quality, for correctness, for unintended issues. For everything. This is a manual process. It’s fairly intensive in terms of time, but I don’t know of a better alternative. This can cause some delay for first time contributors (though as of October 11th, the delay in merging PRs is caused by me still resting after shipping a very large update).

  1. Different parts of the code base have, obviously, different levels of complexity. Making changes to how the app works (to fix a bug, to add a feature) does not involve code that is running inside the Steam process. It doesn't involve complex interaction between a run script, lsteamclient and Steam itself. It may not involve game saves (unless you are working on the stuff in the app that does involve that) and, well, you get the idea. I hope. Some parts of this app are easier to work on than others.

By all means, work on anything you want. Do ask yourself if you are ready to work on a complex part of the project, though. Did you consider the different ways that your change interacts with other components? Did you consider multiple Steam accounts, multiple libraries, multiple macOS users, different file systems? These are things that matter. If you have thought the entire thing through, that's great. That helps a lot.

  1. When PRs that touch complex parts of the app come in, I review them heavily. I may rewrite parts of them. I may rewrite them heavily. But that does not mean I don't value the PRs and the author of them! I value them deeply. I want to make NotProton better and improve the quality of the macOS gaming experience. My policy (in scenarios where I make substantial changes to a PR) is to assign authorship to the original PR author.

I apply a much more critical eye the first few PRs from a person than I do to later ones. I always test and validate, but if you have contributed to this project successfully before, don't expect a long delay on a PR being merged.

I think that about covers it? Be thoughtful. Think before and while making changes to complex parts of the app. Talk to me if you need any help. Tell me if your PR is a best effort but needs further work (I can help!). Let's work together to make the Mac more pleasant to game on.