Test-infra: Owners File Recognition/Reward Bot
What would you like to be added:
A bot that will be kicked off when a PR gets merged adding someone (individual; not an alias) to an owners file as a reviewer or approver. Content will be:
- a congratulations,
- links to important documentation for reviewers/approvers like community expectations/responsibilities/tips, and
- instructions on how to get a promo code to order a free contributor patch from the cncf store (email [email protected] with the PR link - or could this be automated too? :) ).
Why is this needed:
we don't reward and recognize our contributors enough in a scalable way, especially our owners who do countless reviews, etc. we also need important community governance and operational docs to be surfaced to these folks.
parispittman
All 22 comments
/sig contributor-experience
The plugin adds a "positive emoji" whenever an owner is added:
I think this is a cool idea :) but just thinking out loud...would it be weird if we are removing more folks than adding? :see_no_evil: :thinking:
nikhita
on 29 Mar 2019
instructions on how to get a promo code to order a free contributor patch from the cncf store
To be clear, this is only if the contributor doesn't already have the patch, right? Just to make sure we get the message in the bot comment right :grimacing:
nikhita
on 29 Mar 2019
they can collect more than one patch if they wish or ask for another item and if we have the inventory we can provide
parispittman
on 29 Mar 2019
/help
parispittman
on 15 Apr 2019
@parispittman:
This request has been marked as needing help from a contributor.
Please ensure the request meets the requirements listed here.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
/help
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
k8s-ci-robot
on 15 Apr 2019
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 14 Jul 2019
/remove-lifecycle stale
linking to the issue I'm using as an umbrella for all things OWNERS/contributor-ladder related kubernetes/community#1808
spiffxp
on 24 Jul 2019
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 22 Oct 2019
/remove-lifecycle stale
still needs to get done :)
parispittman
on 22 Oct 2019
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 20 Jan 2020
/remove-lifecycle stale
parispittman
on 20 Jan 2020
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 19 Apr 2020
/lifecycle frozen
On Sun, Apr 19, 2020 at 11:35 PM fejta-bot notifications@github.com wrote:
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually
close.If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta
https://github.com/fejta.
/lifecycle stale—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/test-infra/issues/11994#issuecomment-616197434,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AD24BUA7MGI7FBGNSURUFTTRNM4PHANCNFSM4HCGPCIA
.
nikhita
on 19 Apr 2020
@nikhita @parispittman do you still need a hand at this?
Should it be a new plugin, or rename+modify heart?
matthyx
on 10 Sep 2020
/assign
matthyx
on 11 Sep 2020
Content will be:
- a congratulations,
- links to important documentation for reviewers/approvers like community expectations/responsibilities/tips, and
- instructions on how to get a promo code to order a free contributor patch from the cncf store (email [email protected] with the PR link - or could this be automated too? :) ).
@parispittman could you give an example... I think the text+links could go to config/prow/plugins.yaml
@cjwagner do you think it's wise to reuse heart.go or should I put this in a different plugin?
I think it really depends if we wanna do something generic or specific to k/k
matthyx
on 17 Sep 2020
It seems like this should be easy to make configurable and generic for use outside k/k. I think this would be a reasonable extension to the heart plugin if you'd like to integrate there, but as Nikhita mentioned the logic for detecting additions to OWNERS is currently pretty simple and should probably be updated (e.g. distinguish adding users from adding labels).
cjwagner
on 17 Sep 2020
@cjwagner I wonder if it wouldn't be easier to react inside verify-owners as we already load the files and parse the added owners...
I also wonder whether we should not remove heart completely, even though it makes a simple example of a prow plugin.
matthyx
on 21 Sep 2020
@parispittman and @nikhita, couple of questions:
- should we comment inside the PR adding the new reviewer/approver, or we contact them differently (mail, slack, …)?
- should we check whether the individual is a trusted user (i.e. member of the org)?
- should we add a specific label to the PR to identify the PRs later?
- what happens if the individual is moved from reviewer -> approver?
- what happens if the individual was already reviewer/approver elsewhere in the same repo?
- what happens if the PR is modified and no new owner is added, should we purge the welcome message?
matthyx
on 22 Sep 2020
@cjwagner I wonder if it wouldn't be easier to react inside
verify-ownersas we already load the files and parse the added owners...
Sharing code with verify-owners would be fine, but I don't think we should add recognition/reward logic to the validation plugin, those a pretty different roles and it would be nice to enable/configure them separately
I also wonder whether we should not remove heart completely, even though it makes a simple example of a prow plugin.
Unless it's too expensive, which I don't think is the case, I'd like to keep the heart plugin. It is simple and fun. I don't think deprecating and removing it would be a productive use of time.
should we check whether the individual is a trusted user (i.e. member of the org)?
IIRC verify-owners will guarantee this and can be assumed to be enabled since check-config warns if approve or blunderbuss are enabled without it.
cjwagner
on 22 Sep 2020
@cjwagner I have started with something here: https://github.com/kubernetes/test-infra/pull/19449
matthyx
on 5 Oct 2020
@parispittman any update on the text+links to include to the comment?
matthyx
on 19 Oct 2020
Related issues
lavalamp
·
3Comments
xiangpengzhao
·
3Comments
BenTheElder
·
3Comments
chaosaffe
·
3Comments
stevekuznetsov
·
4Comments