🚧 This website is in construction! 🚧

Open Source Software Etiquette

Color Spaces: Representing clamped out-of-gamut colors #3737
Open hyperupcall opened this issue 2 weeks ago

filler

Edwin's profile picture: A red panda
hyperupcall commented 2 weeks ago

--quiet is an improvement over >/dev/null when checking the exit code to check for a string's existence. Using the former better ensures grep does not return an exit code that is unrelated to condition that a substring or regex is contained within a target string (which is the actual semantics of these particular command executions).

Thank you for being involved in an open-source project! You were probably linked to this page because someone thought you did not practice open-source software etiquette.

Below are some guidelines, ordered roughly by what (I think) is important. This site is for people that comment on issues or pull requests.

These items are additions on top of standard netiquette guidelines (link 1) (link 2)

  1. Before filing a GitHub issue
  2. When filing a GitHub

Most open-source maintainers volunteer their time and money to write code (that's often freely distributable). Be decent

For example, it would be disrespectful to berate a soup kitchen volunteer for making an honest mistake. Or, if a gardener was providing the fruits of their labor to their community, it would be indecent to tell that gardener how you think they should garden if you were a passerbyer.

❌ Bad

Why are you still using $OLD_BUILD_SYSTEM? You should update the build system to $NEW_BUILD_SYSTEM_1 or NEW_BUILD_SYSTEM2.

✅ Good

Make no comment.

Please properly format your issues

Maintainers often put time into reading and responding to issues. The least you could do is spent time to write an issue that's easy to read and understand. This isn't targeted at people where English is not their first language, but people who know better when filling an issue. If you are using Google Translate (looking at your Americans!), it is your responsibility to specify that you're using it, and write things in simple terms so translation is successful. Code is the least common denominator across languages, so use that to your advantage.

See this Markdown cheat sheet. If there is an issue template, fill it out to the best of your ability.

❌ Bad

Issue title: I want ot be able to just quick install program like in a packagemanager with a single command insted of plugin add then install then add to global
I have a lot of tool to install so i wan to be able to have a cli simple instead of program1 plugin add $tooltoinstall && program1 install $tooltoinstall latest && program1 global $tooltoinstall latest and when i try program1 on first run i want to be able to just program1 install programname and by default it add or propose to add the plugin and make it local or global by default.

✅ Good

Issue title: Quick install asdf plugin (like in a package manager) with a single command
I have a lot of tool to install so I want to be able to have a CLI simple install. Instead of: program1 plugin add $tool_to_install program1 install $tool_to_install latest program1 global $tool_to_install latest I just want program1 install programname and by default it add or propose to add the plugin and make it local or global by default.

Provide detail

❌ Bad

✅ Good

Look at pre-existing sources. If there is documentation, read it

If you have a question, look at pre-existing questions on the issue tracker, documentation or Google search, or Discord, or community forum. If you wish to file an issue, look for pre-existing ones in the bug tracker.

Mistakes happen, that's okay

always_keep_download