re: Make an open source maintainer's day with this one weird trick VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Sidenote: please make somehow sure the maintainer likes receiving “thanks” as issues in the real project (read: has a lot of free time to read junk...
 

I was thinking the same here: the "issues" section is for, well, reporting issues. Sure, not all maintainers might be so picky to make of this a big deal, but also others like to keep of the sections clean, as it makes their life easier (it serves as statistic for bug-squashing, to represent how stable is the current state of the project, etc). Some just read the number of issues open and make themselves an idea of the project stability, without regarding if any of those is a "thanks for your hard work!".

This trick might be great for small projects, maintained by a small team, but for more mature projects you have other communication channels that are more appropriate (slack channels or mailing lists, or twitter as Aleksei mentions - or any other social network the project makes presence on).

I'm sure the intentions of these "thanks" are the best, don't get me (us) wrong. But, have you seen those "please don't talk to the driver" signs on buses? This is a similar thing.

 

Exactly. For the projects I maintain I receive issues directly into the mailbox I monitor during working hours. Unlike twitter, forums, dev.to, younameit.

That “thank” would make me jump out of the context, check email, see my project has got an issue, get frustrated, open the email—and finally get disgruntled if not angry for the wasted time and lost concentration.

This is very good intent and receiving that kind of feedback is very pleasant, but let’s use the appropriate communication channels for that.

code of conduct - report abuse