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

Manual one-off thanks #35

Open
dtolnay opened this issue Aug 2, 2021 · 2 comments
Open

Manual one-off thanks #35

dtolnay opened this issue Aug 2, 2021 · 2 comments

Comments

@dtolnay
Copy link
Member

dtolnay commented Aug 2, 2021

I often would like to formally recognize users who have contributed significantly to resolving a Rust issue, even if their contribution is not in the form of code in @rust-lang or code review.

Would it be reasonable to recognize some kind of comment in the issue tracker and count the user a point on thanks.rust-lang.org?

Thanks! Your downstream workaround unblocks us in moving forward with this PR.

#thanks @username

or:

#thanks @username for ...

I am not sure how to ascribe such thanks to a specific release, but maybe it's sufficient to say these only count under "All time", not in any of the release-specific thanks.

@Mark-Simulacrum
Copy link
Member

It would be easy enough to add support in fashion similar to Reviewed-by: ... or similar if the line is embedded into a bors merge commit - we already have support for reviewed by (https://github.com/rust-lang/thanks/blob/master/src/main.rs#L331).

Do you think that would make sense as the means of supporting this? I'd prefer to avoid comment-style interaction, as it would mean integrating with a database of some kind to store the data, rather than solely fetching from git. It would likely mean non-github user names (name and/or email), too, I suspect.

@dtolnay
Copy link
Member Author

dtolnay commented Aug 3, 2021

I would definitely use that less often than a GitHub comment way -- to the point that I'm not sure that approach is worth implementing.

My company uses #thanks comments internally, which are internally publicly aggregated by recipient, by sender, and by team, and also presented to the manager when they are doing someone's performance review. In my experience they make a significant positive difference toward people feeling valued when they go out of their way to help someone.

I understand that introducing a database is a high complexity cost vs just git. Feel free to close if this doesn't seem like something you'd want in this project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants