search

vsoch / qme

QueueMe is a job queue, manager, and dashboard
https://vsoch.github.io/qme/
Mozilla Public License 2.0
12 stars 4 forks source link

Error message is misleading #44

Closed frafra closed 2 years ago

frafra commented 2 years ago

https://github.com/vsoch/qme/blob/72b3ded78566926083314e8690fd11123d31af21/qme/client/start.py#L25

Please do not use except without specifying the exception (like ModuleNotFoundError). This hinders other issues, like an error in binding the port.

vsoch commented 2 years ago

Thanks for the suggestion. Please feel free to open a PR to suggest changes.

frafra commented 2 years ago

Done, but please do not close issues that are valid while and not solved. Users might think that the issues has already been solved when they get the "Closed" notification from GitHub.

vsoch commented 2 years ago

Apologies - this felt more like you were scolding me than an issue, and I didn’t see any indication that you intended to fix it or were making a suggestion for how to.

frafra commented 2 years ago

Sorry for the misunderstanding, If I may, I would suggest not to close issues if they are confirmed or considered valid, even if a solution is not there yet. In this case, the software is showing an error message which is wrong, so it should be considered a bug, with or without a PR.

vsoch commented 2 years ago

I've been a maintainer for over ten years and I'm familiar with these practices. I have developed a low tolerance for issues that come across as demanding or belittling, and I tagged this one as of that nature. I see in retrospect I was incorrect and I apologize - happy to re-open the issue.

My suggestion is that if you are opening an issue don't target the maintainer or an action of the maintainer like "Please don't do X" Just take a look at how different these two read:

"Please don't do X"

I am complaining or being patronizing and targeting your action / doing as fault

The focus is on the maintainer(s) and not the issue. If it's not something explicitly broken the maintainer may read this as a suggestion, thank the submitter, and close it.

"The except here does not clearly identify the error and could be better replaced with ModuleNotFound"

I have identified an issue and I am not targeting a person or their actions

The focus is on the issue and not the maintainer(s), and there is a clear suggested direction (and it almost doesn't matter who does the fixing). This could also be more general like "could be better replaced with a more specific exception."

And you can do even better to say:

"The except here does not clearly identify the error and could be better replaced with ModuleNotFound. I will follow up with a PR to fix it."

I have identified an issue, want to help, and setting your expectation about a PR

Especially from the first to the last, we transform from something that can be interpreted as a trolling or patronizing comment into feeling like the person wants to help and/or work as a team. And unfortunately a lot is subject to interpretation - given many issues opened in a day or a week, we do a quick read and have to make a best guess about the intention and how to best respond. We only have some text to go by, and since there have been plenty of cases of others opening sort of scolding or trolling issues that I have to respectfully acknowledge and thank for the suggestion and close, I'm more likely to tag your issue as that (and again I apologize that I was wrong).

So all that said, I think generally when you don't know the maintainers or project, it's better to err on the safe side and keep discussion about the code and not the person, and clearly state the action you intend to do (if this is the case). I hope that makes sense, I've thought about these subtle interactions quite a bit!

frafra commented 2 years ago

I got it. I thank you for your message. As you might have understood now, it was not my intention to be condescending, I should have written a better comment as you suggested. I am sorry if I haven't done it.