Merge branch 'master' into feature/cache-flag-from-events

.github/CONTRIBUTING.md

@@ -1,33 +1,16 @@
-
 ## Making Changes
 
-Depending on your changes there are certain rules you have to follow if you expect
-your Pull Request to be merged.
-
-**Note**: It is recommended to create a new remote branch for each Pull Request. 
-Based on the current `master` changes!
-
-1. Adding a new Method or Class
-    - If your addition is not internal (e.g. an impl class or private method) you have to write documentation.
-        - For that please follow the [JavaDoc template](https://jda.wiki/contributing/structure-guide/#javadoc)
-    - Keep your code consistent! [example](https://jda.wiki/contributing/contributing/#making-changes)
-        - Follow the guides provided at [JDA Structure Guide](https://jda.wiki/contributing/structure-guide/)
-        - Compare your code style to the one used all over JDA and ensure you
-          do not break the consistency (if you find issues in the JDA style you can include and update it)
-    - Do not remove existing functionality, use deprecation instead (for reference [deprecation policy](https://github.com/discord-jda/JDA?tab=readme-ov-file#versioning-and-deprecation-policy))
+Depending on your changes there are certain rules you have to follow if you expect your Pull Request (PR) to be merged.
 
-2. Making a Commit
-    - While having multiple commits can help the reader understand your changes, it might sometimes be
-      better to include more changes in a single commit.
-    - When you commit your changes write a proper commit caption which explains what you have done
+1. Check for existing pull requests that might already implement your changes.  
+    You can review those pull requests with your suggestions for improvements.
+1. Reference documentation or issues that are relevant to your changes.  
+    For instance, if you're implementing a new Discord feature, include a link to the [api docs](https://github.com/discord/discord-api-docs) pull request that documents the feature.
+1. If you implement a new feature, include some examples on how you intend it to be used in your PR description.
+1. Write documentation for all public API methods and types.
+1. Follow the JDA coding style, even if unconventional, we want to keep it consistent to maintain readability.
+1. Try to limit your PR to one logical change or closely related changes.  
+    For instance, do not refactor other code that is irrelevant to your changes. If you want to refactor something, make a dedicated PR.
 
-3. Updating your Fork
-    - Before you start committing make sure your fork is updated.
-      (See [Syncing a Fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork)
-      or [Keeping a Fork Updated](https://thoughtbot.com/blog/keeping-a-github-fork-updated))
-
-4. Only open Pull Requests to master
-    - Look at the [Repository Structure](https://jda.wiki/contributing/repository-structure/) for further details
-
-For more information please consult the [Contributing](https://jda.wiki/contributing/contributing/)
-section of our wiki.
+> [!TIP]
+> Before starting to implement your changes, you can post in our [lib-dev](https://discord.gg/qcy8K58zWb) channel on our Discord Server. Getting early feedback will help you and the reviewers save a lot of time.