-
Notifications
You must be signed in to change notification settings - Fork 132
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
Add a reminder when contributor is new to ping all contributor bot #2484
Add a reminder when contributor is new to ping all contributor bot #2484
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2484 +/- ##
=======================================
Coverage 51.00% 51.00%
=======================================
Files 124 124
Lines 5384 5384
Branches 1162 1162
=======================================
Hits 2746 2746
Misses 2348 2348
Partials 290 290 ☔ View full report in Codecov by Sentry. |
const opts = github.rest.issues.listForRepo.endpoint.merge({ | ||
...context.issue, | ||
creator, | ||
state: 'all' | ||
}) | ||
const issues = await github.paginate(opts) | ||
|
||
for (const issue of issues) { | ||
if (issue.number === context.issue.number) { | ||
continue | ||
} | ||
|
||
if (issue.pull_request) { | ||
return // Creator is already a contributor. | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part lgtm but I am thinking of an alternative
Instead of checking all prs and see if there is any previous prs by the pr creator, I am thinking if we could utilise Github's built-in function to get the current list of contributors and check if the person is inside
https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#list-repository-contributors
Not sure if this approach would speed up the process since we do not have to go through every closed pr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @LamJiuFong, thanks for the suggestion, I think it will be more efficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes @KevinEyo1 ! LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @LamJiuFong after testing, I realised that since we are running the job on merge, the author is already part of the list by the time the action is run, so it fails to detect the author as a new contributor. I will revert to the original implementation, and I will try to figure out if there can be performance enhancements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see, sorry for missing that out
What about checking if the author has only one pr merged (which is the newly merged one), would that be possible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LamJiuFong I am trying to think of a more efficient solution as well but I think to check if the author has only one PR merged we would have to fetch all the PRs anyway (which is what is done in the current implementation) leading to a similar time taken
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spoke to Kevin about this previously and he did this check: Test run to check time which wasn't very long. So I don't think there is a need to overoptimize in this case.
Hi @KevinEyo1 thanks for the work! Could you also include some test workflows for us to check if its ok? |
Hi @yucheng11122017 I'm still working on the testing and fixing bugs, I will add the test workflows when I set this PR to ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
…markbind into 2457-ping-new-contrib
cb84513
to
69ec838
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No comments on implementation, which I think looks good now!
However, I don't love the look of the commit message. Is there a reason why we're pinging the contributor and asking them to ask to be recognised? It feels less friendly. I'm OK with it if we also amend the readme/expectations as well.
Also, I was thinking that this is essentially a "welcome" message to the repository of sorts. It might be nice to also use this to recognise and welcome the contributor even more, the same way some other OSSes have decided to work. Something like what scribeOS does? see this reflection
what do @MarkBind/active-devs think?
Edit: I realise this might be confusing bc of my previous comment on the issue, but I'd like to clarify my issue isn't with asking contributors to add themselves, but that the only place where recognition is talked about is asking contributor to add themselves. I personally would find it scary and wonder if a mistake was made, and people might be scared to ask for recognition or feel like their work is not recognised. Other repos which adopt asking contributors to add themselves make it part of the PR checklist and devdocs / readme so that it's clear its part of regular expectations. Otherwise, I think a reminder nudge to the person who merged the PR / active devs is the way to go!
Hi @kaixin-hc, those are some good points. Can I just clarify what you mean by welcoming them more? |
It's an open-ended thought - looking for ideas. I think more encouragement early on can be good for newer contributors? But I'm also not certain on implementation |
per_page: 100 | ||
}, | ||
(response) => response.data.filter(pr => pr.merged_at != null && pr.user.login === prAuthor && pr.number !== currentPR) | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do correct me if I am wrong, from my understanding this gets the last 100 pull requests and checks if the user has a merged PR within the last 100 PRs, would this mean that the comment will be sent for a user that hasn't had any merged PRs in the last 100 PRs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Definitely a useful GitHub action for MarkBind's maintainers! Thanks for the work!
@yucheng11122017 Each PR must have a SEMVER impact label, please remember to label the PR properly. |
What is the purpose of this pull request?
Overview of changes:
Fixes #2457
Added workflow to check on merge whether pr author is new to the repo, and ping a reminder to add them to contributors list
Anything you'd like to highlight/discuss:
Testing instructions:
test repo
Proposed commit message: (wrap lines at 72 characters)
GitHub Actions: ping new contributor
It is easy to forget to add new contributors.
Adding a workflow to automate reminders to add will help.
Let's on merge, check whether PR author has a prior merged PR,
pinging them if not since they are a new contributor.
This approach allows the user to remember to ask to be added to
the contributor list, if they want to.
Checklist: ☑️
Reviewer checklist:
Indicate the SEMVER impact of the PR:
At the end of the review, please label the PR with the appropriate label:
r.Major
,r.Minor
,r.Patch
.Breaking change release note preparation (if applicable):