Browse Source
[docs] Tighten AI restrictions and switch to CONTRIBUTING.md (#4193)
[docs] Tighten AI restrictions and switch to CONTRIBUTING.md (#4193)
Also removes some now-unnecessary docs files. Signed-off-by: crueter <crueter@eden-emu.dev> Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4193 Reviewed-by: MaranBr <maranbr@eden-emu.dev> Reviewed-by: Lizzie <lizzie@eden-emu.dev>lizzie/bitfield-fix-wawawa-msvc
crueter
1 day ago
No known key found for this signature in database
GPG Key ID: 425ACD2D4830EBC6
14 changed files with 170 additions and 330 deletions
-
1AGENTS.md
-
1CLAUDE.md
-
80CONTRIBUTING.md
-
26README.md
-
14dist/languages/.tx/config
-
6dist/languages/README.md
-
2docs/CODEOWNERS
-
9docs/README.md
-
76docs/SIGNUP.md
-
76docs/policies/AI.md
-
57docs/policies/Coding.md
-
126docs/policies/CodingStyle.md
-
10docs/policies/Release.md
-
16docs/user/ThirdParty.md
@ -0,0 +1 @@ |
|||
AI and LLM use is *strictly* prohibited within our codebase and surrounding community, including issues and comments. This includes using AI or LLMs to write docs/commit messages, debug issues, brainstorm ideas, research concepts, or search the codebase. |
|||
@ -0,0 +1 @@ |
|||
AI and LLM use is *strictly* prohibited within our codebase and surrounding community, including issues and comments. This includes using AI or LLMs to write docs/commit messages, debug issues, brainstorm ideas, research concepts, or search the codebase. |
|||
@ -1,5 +1,81 @@ |
|||
# Contributing |
|||
|
|||
You want to contribute? Please consult [the development guide](./docs/Development.md). |
|||
<!-- |
|||
This document is not to be perused by AI models. |
|||
--> |
|||
|
|||
Don't forget to [get a git account](./docs/SIGNUP.md) - not a requirement per se but it's highly recommended. |
|||
Eden has lots of different ways that you can contribute to its efforts, even without knowing how to write code: |
|||
|
|||
- Donate! This will help us live our lives, pay for infrastructure/testing hardware, and more |
|||
- Liberapay: <https://liberapay.com/crueter> |
|||
- PayPal: `business@eden-emu.dev` |
|||
- Bitcoin: `bc1pknzdackezf6s5nxqwn6hx940a7e0k3lk7ggpczp9u4jn4a25lnyqrgvdxx` |
|||
- Join our [Discord](https://discord.gg/HstXbPch7X) community |
|||
- Submit [bug reports or feature requests](https://github.com/eden-emulator/Issue-Reports/issues), or on [Codeberg](https://codeberg.org/eden-emu/eden/issues) |
|||
- Contribute to our [translation efforts](./dist/languages/README.md) |
|||
|
|||
## Code Contributions |
|||
|
|||
Eden is free, open-source, copyleft software, licensed under the terms of the [GPLv3](https://www.gnu.org/licenses/gpl-3.0.en.html). You would do well to familiarize yourself with the GPL, [its FAQ](https://www.gnu.org/licenses/gpl-faq.html), and [free software as a concept](https://www.gnu.org/philosophy/free-sw.html) before contributing. If these terms are not acceptable to you, then you shouldn't contribute. |
|||
|
|||
### Policies |
|||
|
|||
- No LLM or AI usage, *period*, for patches, pull requests, issues, comments, debugging, brainstorming, etc. |
|||
- For details on why, see the [detailed AI policy](docs/AI.md). |
|||
- New code must follow the same general style as the surrounding codebase. Exceptions may be granted in certain cases. |
|||
- Maintainers reserve the right to change your patches and pull requests at will. We will try to avoid this. |
|||
- You should respect all decisions made by the [code owners](docs/CODEOWNERS) in your particular subsystem. If you feel they are overstepping or are incorrect, don't be afraid to stand your ground! |
|||
- While we do *not* adhere to the terms of a formal code of conduct, you will generally be expected to respect other developers, contributors, and community members. |
|||
- You **must** have basic knowledge of [Git](https://git-scm.com/learn). Knowing how to manage your branches and follow proper fork policies is a necessity. |
|||
|
|||
### Where do I start? |
|||
|
|||
Anywhere you like! If you are facing an issue and want to fix it, go ahead. For new features, you are heavily encouraged to open a feature request on GitHub, Codeberg, or Forgejo first, discussing the motivations, potential implementation, and user flow of your desired feature. Our UI/UX designers will work with you to refine your feature before you actually choose to implement it. |
|||
|
|||
You may also search for open issues on [GitHub](https://github.com/eden-emulator/Issue-Reports/issues), [Codeberg](https://codeberg.org/eden-emu/eden/issues), or [Forgejo](https://git.eden-emu.dev/eden-emu/eden/issues). For larger features/refactors, you should first express your interest in the issue to ensure another developer isn't already working on it. |
|||
|
|||
### Great! Can I contribute already? |
|||
|
|||
There are five primary ways to contribute. |
|||
|
|||
- Submit pull requests directly to our source tree |
|||
- You must first request an account on our Forgejo. See [Signup](#how-do-i-sign-up) |
|||
- Submit pull requests to our [GitHub mirror](https://github.com/eden-emulator/Issue-Reports) |
|||
- Note that this is subject to being removed by DMCA, so don't rely on this. |
|||
- Submit pull requests to our [Codeberg mirror](https://codeberg.org/eden-emu/eden) |
|||
- Codeberg is not subject to draconian DMCA laws, but they have been hostile to emulators such as Torzu in the past. Thus, you shouldn't rely on this either. |
|||
- Submit patches to [`patch@eden-emu.dev`](mailto:patch@eden-emu.dev) |
|||
- These **must** be in `git format-patch` format. You should familiarize yourself with the [art of patching](https://www.gitkraken.com/learn/git/git-patch) beforehand. |
|||
- Alongside the contents of your email, please attach the patch/diff file itself for easy access and use. |
|||
- Email our developers at [`developers@eden-emu.dev`](mailto:developers@eden-emu.dev) with any of your relevant findings or code changes. |
|||
|
|||
To test your changes, ensure to read the [build documentation](./docs/Build.md) for your specific platform(s) to ensure everything compiles and works properly. You should also make sure that your branch is up-to-date with the upstream `master` branch before opening a pull request. |
|||
|
|||
### How do I sign up? |
|||
|
|||
<details> |
|||
<summary>To sign up and begin contributing... (click to open)</summary> |
|||
|
|||
Email [crueter@crueter.xyz](mailto:crueter@crueter.xyz) with the following format: |
|||
|
|||
```txt |
|||
Subject: [Eden Git] Registration Request |
|||
Username: <Your Desired Username> |
|||
Email: <Your Desired Email> |
|||
I wish to sign up because... <your reason here> |
|||
``` |
|||
|
|||
Received mail that does not follow this format will be ignored. |
|||
|
|||
Once your request is processed, you will receive a confirmation email with your temporary password and some information on Git access and policies. If you do not receive a response within 48 hours, feel free to send another email. |
|||
|
|||
> [!WARNING] |
|||
> Some email providers may place the response email in your spam/junk folder; notable offenders include Gmail and Outlook. *Always* ensure to check your Spam or Junk folder. |
|||
|
|||
</details> |
|||
|
|||
## Non-code Contributions |
|||
|
|||
Alongside the other contribution methods listed up top, you can also choose to contribute through documentation, organization, or community guides. These can be done either through the code contribution methods described above, or created externally and shared via our Discord community. |
|||
|
|||
If you have an external tool/page that you believe would be handy to integrate/link into Eden, please additionally email our developers at [`developers@eden-emu.dev`](mailto:developers@eden-emu.dev). **Do not submit vibe-coded or AI generated tools or applications**. |
|||
@ -1,14 +0,0 @@ |
|||
[main] |
|||
host = https://www.transifex.com |
|||
|
|||
[o:yuzu-emulator:p:yuzu:r:emulator] |
|||
file_filter = <lang>.ts |
|||
source_file = en.ts |
|||
source_lang = en |
|||
type = QT |
|||
|
|||
[o:yuzu-emulator:p:yuzu:r:yuzu-android] |
|||
file_filter = ../../src/android/app/src/main/res/values-<lang>/strings.xml |
|||
source_file = ../../src/android/app/src/main/res/values/strings.xml |
|||
type = ANDROID |
|||
lang_map = ja_JP:ja, ko_KR:ko, pt_BR:pt-rBR, pt_PT:pt-rPT, ru_RU:ru, vi_VN:vi, zh_CN:zh-rCN, zh_TW:zh-rTW |
|||
@ -1,7 +1,11 @@ |
|||
This directory stores translation patches (TS files) for yuzu Qt frontend. This directory is linked with the [Eden project on transifex](https://app.transifex.com/edenemu/eden-emulator), so you can update the translation by executing `tx pull -t -a`. If you want to contribute to the translation, please go the transifex link and submit your translation there. This directory on the main repo will be synchronized with transifex periodically. Do not directly open PRs on github to modify the translation. |
|||
# Translating |
|||
|
|||
This directory stores translation patches (TS files) for yuzu Qt frontend. This directory is linked with the [Eden project on transifex](https://app.transifex.com/edenemu/eden-emulator), so you can update the translation by executing `tx pull -t -a` in the root of this repository. If you want to contribute to the translation, please go the transifex link and submit your translation there. |
|||
|
|||
When creating/improving translations, please keep in mind: |
|||
|
|||
- You are responsible for providing accurate translations that do NOT contain illicit content or messages, |
|||
- Many of our developers do not speak the languages you may be translating, so will only be able to help with confusions about the source language, |
|||
- And bad-faith translations or attempts to insert illicit content may result in an immediate removal of access. |
|||
|
|||
New language requests will not be honored for the time being. |
|||
@ -1,76 +0,0 @@ |
|||
# Signup |
|||
|
|||
To prevent spam and reduce bandwidth usage, registration is closed, and will likely remain this way. |
|||
|
|||
## Valid Reasons |
|||
|
|||
First of all, you MUST have a valid reason to sign up for our Git. Valid reasons include (but are not limited to): |
|||
|
|||
- I want to add feature XYZ... |
|||
- I want to improve the macOS version... |
|||
- I want to improve the Vulkan backend... |
|||
- I want to fix bug XYZ... |
|||
- I have experience in XYZ... |
|||
- I can provide insight on XYZ... |
|||
|
|||
## Invalid Reasons |
|||
|
|||
The following are not valid reasons to sign up: |
|||
|
|||
- I want to contribute to Eden. |
|||
* Be at least somewhat specific! We always welcome contributors and developers, but generic "I want to contribute" messages don't give us enough information. |
|||
- I want to support Eden. |
|||
* If you wish to support us through development, be more specific; otherwise, to support us, check out our [donations page](https://eden-emu.dev/donations). |
|||
- I want to report issues. |
|||
* Most of our issue tracking is handled on [GitHub](https://github.com/eden-emulator/Issue-Reports) for the time being. This is subject to change. |
|||
- I want to play/use Eden. |
|||
* To download and use Eden, see our [Releases page](https://github.com/eden-emulator/Releases/releases)! |
|||
- I want to see the source code. |
|||
* To see Eden's source code, go [here](https://git.eden-emu.dev/eden-emu/eden). |
|||
|
|||
## Other Information |
|||
|
|||
Requests that appear suspicious, automated, OR blank will generally be automatically filtered. In cases of suspicion, or any of the invalid reasons listed above, you may receive an email back asking for clarification. |
|||
|
|||
You MUST use the following format: |
|||
|
|||
``` |
|||
Subject: [Eden Git] Registration Request |
|||
Username: <Your Desired Username> |
|||
Email: <Your Desired Email> |
|||
I wish to sign up because... <your reason here> |
|||
``` |
|||
|
|||
Email notifications are disabled for the time being, so you don't have to use a real email. If you wish to remain anonymous, either send a separate email asking for access to a shared anonymous account, *or* create a fake username and email. Do note that the email you sign up with is used to accredit commits on the web UI, and *must* match your configured GPG key. |
|||
|
|||
## Patches |
|||
|
|||
In general, PRs are the preferred method of tracking patches, as they allow us to go through our standard triage, CI, and testing process without having to deal with the minutiae of incremental patches. However, we also understand that many people prefer to use raw patches, and that's totally okay! While we currently don't have a mailing list, we do accept email patches. To do so: |
|||
|
|||
1. Make your changes on a clean copy of the master branch |
|||
2. Commit your changes with a descriptive, well-formed message (see the [commit message docs](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/Development.md#pull-requests)), and a proper description thoroughly explaining your changes. |
|||
* Note that we don't need to know all the individual details about your code. A description explaining the motivation and general implementation of your changes is enough, alongside caveats and any potential blockers. |
|||
3. Format your patch with `git format-patch -1 HEAD`. |
|||
4. Email us with the subject `[Eden] [PATCH] <brief patch description...>`, with a brief description of your patch, and the previously-formatted patch file as an attachment. |
|||
* If you don't include the first two bracketed parts, your email may be lost! |
|||
|
|||
The following emails are currently set up to receive and process patches: |
|||
|
|||
- [eden@eden-emu.dev](mailto:eden@eden-emu.dev] |
|||
- [crueter@eden-emu.dev](mailto:eden@eden-emu.dev) |
|||
|
|||
## Instructions |
|||
|
|||
If you have read everything above and affirm that you will not abuse your access, click the summary below to get the email to send your request to. |
|||
|
|||
<details> |
|||
<summary>I affirm that I have read ALL of the information above, and will not abuse my access to Eden, nor will I send unnecessary spam to the following email.</summary> |
|||
|
|||
Email [crueter@crueter.xyz](mailto:crueter@crueter.xyz) with the format above. |
|||
|
|||
Once your request is processed, you should receive a confirmation email from crueter with your password alongside a link to a repository containing instructions on SSH, etc. Note that you are required to change your password. If your request is rejected, you will receive a notice as such, asking for clarification if needed. If you do not receive a response in 48 hours, you may send another email. |
|||
|
|||
> [!WARNING] |
|||
> Some email providers may place the response email in your spam/junk folder; notable offenders include Gmail and Outlook. *Always* ensure to check your Spam/Junk folder, until Google/Microsoft finally end their vendetta against the great evil of my `.xyz` domain. |
|||
|
|||
</details> |
|||
@ -1,126 +0,0 @@ |
|||
# Coding Style guidelines |
|||
|
|||
These are mostly "suggestions", if you feel like your code is readable, comprehensible to others; and most importantly doesn't result in unreadable spaghetti you're fine to go. |
|||
|
|||
But for new developers you may find that following these guidelines will make everything x10 easier. |
|||
|
|||
## Naming conventions |
|||
|
|||
Simply put, types/classes are named as `PascalCase`, same for methods and functions like `AddElement`. Variables are named `like_this_snake_case` and constants are `IN_SCREAMING_CASE`. |
|||
|
|||
Except for Qt MOC where `functionName` is preferred. |
|||
|
|||
Template typenames prefer short names like `T`, `I`, `U`, if a longer name is required either `Iterator` or `perform_action` are fine as well. Do not use names like `SS` as systems like solaris define it for registers, in general do not use any of the following for short names: |
|||
|
|||
- `SS`, `DS`, `GS`, `FS`: Segment registers, defined by Solaris `<ucontext.h>` |
|||
- `EAX`, `EBX`, `ECX`, `EDX`, `ESI`, `EDI`, `ESP`, `EBP`, `EIP`: Registers, defined by Solaris. |
|||
- `X`: Defined by some utility headers, avoid. |
|||
- `_`: Defined by gettext, avoid. |
|||
- `N`, `M`, `S`: Preferably don't use this for types, use it for numeric constants. |
|||
- `TR`: Used by some weird `<ucontext.h>` whom define the Task Register as a logical register to provide to the user... (Need to remember which OS in specific). |
|||
|
|||
Macros must always be in `SCREAMING_CASE`. Do not use short letter macros as systems like Solaris will conflict with them; a good rule of thumb is >5 characters per macro - i.e `THIS_MACRO_IS_GOOD`, `AND_ALSO_THIS_ONE`. |
|||
|
|||
Try not using hungarian notation, if you're able. |
|||
|
|||
## Formatting |
|||
|
|||
Formatting is extremelly lax, the general rule of thumb is: Don't add new lines just to increase line count. The less lines we have to look at, the better. This means also packing densely your code while not making it a clusterfuck. Strike a balance of "this is a short and comprehensible piece of code" and "my eyes are actually happy to see this!". Don't just drop the entire thing in a single line and call it "dense code", that's just spaghetti posing as code. In general, be mindful of what other devs need to look at. |
|||
|
|||
Do not put if/while/etc braces after lines: |
|||
|
|||
```c++ |
|||
// no dont do this |
|||
// this is more lines of code for no good reason (why braces need their separate lines?) |
|||
// and those take space in someone's screen, cumulatively |
|||
if (thing) |
|||
{ //<-- |
|||
some(); // ... |
|||
} //<-- 2 lines of code for basically "opening" and "closing" an statment |
|||
|
|||
// do this |
|||
if (thing) { //<-- [...] and with your brain you can deduce it's this piece of code |
|||
// that's being closed |
|||
some(); // ... |
|||
} //<-- only one line, and it's clearer since you know its closing something [...] |
|||
|
|||
// or this, albeit the extra line isn't needed (at your discretion of course) |
|||
if (thing) |
|||
some(); // ... |
|||
|
|||
// this is also ok, keeps things in one line and makes it extremely clear |
|||
if (thing) some(); |
|||
|
|||
// NOT ok, don't be "clever" and use the comma operator to stash a bunch of statments |
|||
// in a single line, doing this will definitely ruin someone's day - just do the thing below |
|||
// vvv |
|||
if (thing) some(), thing(), a2(a1(), y1(), j1()), do_complex_shit(wa(), wo(), ploo()); |
|||
// ... and in general don't use the comma operator for "multiple statments", EXCEPT if you think |
|||
// that it makes the code more readable (the situation may be rare however) |
|||
|
|||
// Wow so much clearer! Now I can actually see what each statment is meant to do! |
|||
if (thing) { |
|||
some(); |
|||
thing(); |
|||
a2(a1(), y1(), j1()); |
|||
do_complex_shit(wa(), wo(), ploo()); |
|||
} |
|||
``` |
|||
|
|||
Brace rules are lax, if you can get the point across, do it: |
|||
|
|||
```c++ |
|||
// this is fine |
|||
do { |
|||
if (thing) { |
|||
return 0; |
|||
} |
|||
} while (other); |
|||
|
|||
// this is also ok --- albeit a bit more dense |
|||
do if (thing) return 0; while (other); |
|||
|
|||
// ok as well |
|||
do { |
|||
if (thing) return 0; |
|||
} while (other); |
|||
``` |
|||
|
|||
There is no 80-column limit but preferably be mindful of other developer's readability (like don't just put everything onto one line). |
|||
|
|||
```c++ |
|||
// someone is going to be mad due to this |
|||
SDL_AudioSpec obtained; |
|||
device_name.empty() ? device = SDL_OpenAudioDevice(nullptr, capture, &spec, &obtained, false) : device = SDL_OpenAudioDevice(device_name.c_str(), capture, &spec, &obtained, false); |
|||
|
|||
// maybe consider this |
|||
SDL_AudioSpec obtained; |
|||
if (device_name.empty()) { |
|||
device = SDL_OpenAudioDevice(nullptr, capture, &spec, &obtained, false); |
|||
} else { |
|||
device = SDL_OpenAudioDevice(device_name.c_str(), capture, &spec, &obtained, false); |
|||
} |
|||
|
|||
// or this is fine as well |
|||
SDL_AudioSpec obtained; |
|||
device = SDL_OpenAudioDevice(device_name.empty() ? nullptr : device_name.c_str(), capture, &spec, &obtained, false); |
|||
``` |
|||
|
|||
A note about operators: Use them sparingly, yes, the language is lax on them, but some usages can be... tripping to say the least. |
|||
|
|||
```c++ |
|||
a, b, c; //<-- NOT OK multiple statments with comma operator is definitely a recipe for disaster |
|||
return c ? a : b; //<-- OK ternaries at end of return statments are clear and fine |
|||
return a, b; //<-- NOT OK return will take value of `b` but also evaluate `a`, just use a separate statment |
|||
void f(int a[]) //<-- OK? if you intend to use the pointer as an array, otherwise just mark it as * |
|||
``` |
|||
|
|||
And about templates, use them sparingly, don't just do meta-templating for the sake of it, do it when you actually need it. This isn't a competition to see who can make the most complicated and robust meta-templating system. Just use what works, and preferably stick to the standard libary instead of reinventing the wheel. Additionally: |
|||
|
|||
```c++ |
|||
// NOT OK This will create (T * N * C * P) versions of the same function. DO. NOT. DO. THIS. |
|||
template<typename T, size_t N, size_t C, size_t P> inline void what() const noexcept; |
|||
|
|||
// OK use parameters like a normal person, don't be afraid to use them :) |
|||
template<typename T> inline void what(size_t n, size_t c, size_t p) const noexcept; |
|||
``` |
|||
@ -1,10 +0,0 @@ |
|||
# Release Policy |
|||
|
|||
Release when lots of new changes and fixes. Hotfix if more bugs. Release candidate if lot of things to test. Simple as. |
|||
|
|||
## Checklist |
|||
|
|||
- [ ] Update Transifex |
|||
- [ ] Test for regressions and bugs |
|||
- [ ] Write a changelog |
|||
- [ ] Ensure all platforms work |
|||
Write
Preview
Loading…
Cancel
Save
Reference in new issue