Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[READ BEFORE POSTING] Issue and PR Guidelines #119

Closed
Ephenia opened this issue May 27, 2022 · 0 comments
Closed

[READ BEFORE POSTING] Issue and PR Guidelines #119

Ephenia opened this issue May 27, 2022 · 0 comments

Comments

@Ephenia
Copy link
Owner

Ephenia commented May 27, 2022

Before you post an open an issue, you should...

  • Look and search through pre-existing Issues to see if what you're trying to create an issue for has already being created (yes, this includes closed ones too).
  • If you're reporting a bug, please be detailed as possible about the bug.
  • Do not retract or delete your own content here (messages, reactions, etc). This is a rule as I do not appreciate presumably fake personalities, and I will not hesitate to block you if I deem you to be unappreciative of not just me and my work, but most importantly this project in its entirety.
  • If you are suggesting something, please try to remember to add [Feature Request] as a prefix to your Issue title.

If you are thinking about creating a PR...

  1. Be clear with what your PR is for and what it's doing or trying to accomplish.
  2. Try to keep the style of the code consistent across scripts. While I am open to different styles of coding and may not mind this, I could end up being picky about it and your PR may not be approved simply due to it. I wouldn't want this to be discouraging, and you should still code and make changes with how you want and see fit.
  3. Putting comments in your code while not necessary, is highly recommended.
  4. Performance and functionality is important and top priority, I would expect anything that you would be putting in a PR, that you would be thoroughly testing yourself. I would be testing when it comes to reviewing things, but don't rely on me doing all the quality assurance.
  5. It can be fine to update the README to reflect off of the change(s) that your PR is making.
  6. If changes that you're making to scripts happen to include new images, put the images into base64. This is important to ensure that they work on the Desktop version of the game, and that these scripts work fully offline.
  7. Don't change the directory of files in your PR, and if you're happening to create new scripts, make sure that they go in the correct places.
  8. If you are wanting to create a new script for something, make sure that its name follows the naming convention rule that I have going on. The name of the script must be comprised of 3 words.
  9. When it comes to the Credit section of scripts, it can be fine to include your name in the Credit section, but just make sure it follows the format that I have going and be sure to be appending your name following a comma in the parenthesis:
    Ex. Ephenia (Credit: Player1, YourUsername)
  10. When it comes to incrementing the version of the script, you are allowed to do so, but make sure to increment the version by 0.1. It's fine if you forget to increment the version, but it's important so that people who have the scripts installed via a script manager can automatically receive the update and be prompted to update the script conveniently.
  11. It would be a good idea to reference issues that you would be happening to fix/implement with your PRs, and or create an issue for things that you are also doing PRs for as well. While this isn't absolutely necessary, it's always a good thing to do if you can.
  12. Make sure that your PR has no conflicts at any given time with the master branch, and be sure to update your PR with additional commits to resolve any conflicts. If there are conflicts, your PR won't be merged. No ifs, ands, or buts.
  13. Please know that I would go in no particular order with reviewing PRs and may not comment on and or close PRs even if there are issues with them even after a reviewal. It's best to be reviewing these guidelines and be taking notes from the (closed) PRs that have been merged previously and what you may expect to pass through and or be approved.

These guidelines take effect immediately as of creating them, and may also be subject to change without any given notice prior.

Repository owner locked and limited conversation to collaborators May 27, 2022
@Ephenia Ephenia pinned this issue May 27, 2022
@Ephenia Ephenia closed this as completed Jun 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant