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

github: Add GitHub action to greet first time contributors #56093

Merged

Conversation

kartben
Copy link
Collaborator

@kartben kartben commented Mar 22, 2023

Adds the configuration file for a GitHub action that will greet first-time contributor the first time they:

  • open an issue
  • open a PR
  • get a PR of theirs merged

Copy link
Member

@stephanosio stephanosio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No objection to this in general, but would like a bit more community input before we merge this.

.github/config.yml Outdated Show resolved Hide resolved
.github/config.yml Outdated Show resolved Hide resolved
@kartben
Copy link
Collaborator Author

kartben commented Mar 22, 2023

Thanks for the swift review @stephanosio! And +1 to gather community input (I actually considered opening an RFC but that felt overkill?)
FWIW @carlescufi just suggested that this might be better off implemented as a Github action, e.g. using https://github.com/marketplace/actions/first-interaction

@kartben kartben marked this pull request as draft March 22, 2023 11:06
@stephanosio
Copy link
Member

stephanosio commented Mar 22, 2023

FWIW @carlescufi just suggested that this might be better off implemented as a Github action, e.g. using https://github.com/marketplace/actions/first-interaction

AFAICS, that action adds a comment when a user opens their first issue/PR, not when the first PR is merged.

p.s. I suppose you could make it comment when the first PR is merged by restricting the pull_request event types to merged -- not sure if that is a supported configuration/works with that particular action though.

@kartben
Copy link
Collaborator Author

kartben commented Mar 22, 2023

FWIW @carlescufi just suggested that this might be better off implemented as a Github action, e.g. using https://github.com/marketplace/actions/first-interaction

AFAICS, that action adds a comment when a user opens their first issue/PR, not when the first PR is merged.

Yup, there's a bug open actions/first-interaction#226

p.s. I suppose you could make it comment when the first PR is merged by restricting the pull_request event types to merged -- not sure if that is a supported configuration/works with that particular action though.

Ya I can try -- but my guess it will then not properly determine that the now-merged-PR is the first one from this contributor https://github.com/actions/first-interaction/blob/main/src/main.ts#L149..L151
EDIT: mmm actually it might just work -- i misinterpreted the == 0 check above.
EDIT2: oh well, this one is actually a blocker: https://github.com/actions/first-interaction/blob/main/src/main.ts#L19-L22. Guess I might just fork the action

@kartben
Copy link
Collaborator Author

kartben commented Mar 22, 2023

OK so following @carlescufi's recommendation, I've forked the actions/first-interaction GH action to add support for "comment on first PR merged".
I am trying to see with the upstream project if they are willing to take my PR, or if we will have to go with a fork.

In the meanwhile, for those interested, below is the wording I came up with. I've added the GH action to this test repo, feel free to try it out: https://github.com/kartben/delete-me4.

name: first-interaction

on:
  issues:
    types: [opened]
  pull_request:
    types: [opened, closed]

jobs:
  check_for_first_interaction:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3 
      - uses: kartben/[email protected]
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          
          issue-message: >
            Hi @${{github.event.issue.user.login}}! We appreciate you submitting your first issue
            for our open-source project. 🌟


            Even though I'm a bot, I can assure you that the whole community is genuinely grateful
            for your time and effort. 🤖💙

          pr-opened-message: >
            Hello @${{ github.event.pull_request.user.login }}, and thank you very much for your
            first pull request to the Zephyr project!
            

            As our Continuous Integration jobs run checks on your PR to ensure it's compliant and
            doesn't cause any issues, you might want to take this opportunity to review the
            project's [Contributor
            Expectations](https://docs.zephyrproject.org/latest/contribute/contributor_expectations.html)
            and make any updates to your pull request if necessary. 😊



          pr-merged-message: >
            Hi @${{ github.event.pull_request.user.login }}! 
            
            Congratulations on getting your very first Zephyr pull request merged 🎉🥳. This is a
            fantastic achievement, and we're thrilled to have you as part of our community!
            

            To celebrate this milestone and showcase your contribution, we'd love to award you the
            Zephyr Technical Contributor badge. If you're interested, please claim your badge by
            filling out this form: [Claim Your Zephyr Badge](https://forms.gle/oCw9iAPLhUsHTapc8).
            

            Thank you for your valuable input, and we look forward to seeing more of your
            contributions in the future! 🪁

@mbolivar-nordic
Copy link
Contributor

As our Continuous Integration jobs run checks on your PR to ensure it's compliant and doesn't cause any issues

@kartben misleading: CI workflows for first-time contributors must be manually approved on every push

@kartben
Copy link
Collaborator Author

kartben commented Mar 28, 2023

As our Continuous Integration jobs run checks on your PR to ensure it's compliant and doesn't cause any issues

@kartben misleading: CI workflows for first-time contributors must be manually approved on every push

+1, I also caught that, thanks! Will update the wording.

@kartben
Copy link
Collaborator Author

kartben commented Mar 30, 2023

As our Continuous Integration jobs run checks on your PR to ensure it's compliant and doesn't cause any issues

@kartben misleading: CI workflows for first-time contributors must be manually approved on every push

Actually, I just remembered thinking twice while writing it -- it is in fact the correct wording :) As this is implemented as a Github action, the bot will in fact comment on the PR only when someone will have manually approved CI. If you think that can help people understand better how we work the message could actually be reworded something like "A project maintainer just triggered our CI pipeline to run on your contribution, ...."

@kartben
Copy link
Collaborator Author

kartben commented Mar 30, 2023

Unfortunately, I haven't heard back from the maintainers of the actions/first-interaction (see actions/first-interaction#226).

Can someone please help me get this fork https://github.com/kartben/first-interaction/tree/v1.1.2-zephyr hosted under the zephyrproject-rtos organization?
@carlescufi

@kartben kartben changed the title github: Add config for first-pr-merge GitHub bot github: Add GitHub action to greet first time contributors Mar 30, 2023
@kartben kartben force-pushed the add_config_for_pr_bot branch 3 times, most recently from 01aaf25 to ccac693 Compare March 30, 2023 17:15
@kartben kartben added the DNM This PR should not be merged (Do Not Merge) label Mar 30, 2023
@mbolivar-nordic
Copy link
Contributor

As this is implemented as a Github action, the bot will in fact comment on the PR only when someone will have manually approved CI.

Ah, OK! That makes sense.

If you think that can help people understand better how we work the message could actually be reworded something like "A project maintainer just triggered our CI pipeline to run on your contribution, ...."

I think that would be an improvement.

@kartben
Copy link
Collaborator Author

kartben commented Mar 30, 2023

I think that would be an improvement.

+1. I've fixed the wording.
I am ready to move the PR out of draft state -- would be great if someone can assist me with getting a new repo created into the org for the GH action. Ideally it's created as a actual fork of https://github.com/actions/first-interaction so that it properly shows up in Github as being a fork.

@mbolivar-nordic
Copy link
Contributor

would be great if someone can assist me with getting a new repo created into the org for the GH action.

Take the PR out of draft and add TSC label -- if nobody gets to it by the next TSC meeting, it can be handled then

@kartben kartben added the TSC Topics that need TSC discussion label Mar 31, 2023
@kartben kartben marked this pull request as ready for review March 31, 2023 08:59
@kartben
Copy link
Collaborator Author

kartben commented Apr 18, 2023

No objection to this in general, but would like a bit more community input before we merge this.

@stephanosio please have another look when you get a chance. Thanks!

@nordicjm
Copy link
Collaborator

I guess my question to this is pretty brief: why?

nashif
nashif previously approved these changes Apr 18, 2023
@kartben
Copy link
Collaborator Author

kartben commented Apr 18, 2023

I guess my question to this is pretty brief: why?

Mmmh I guess I could reply briefly too... why not? The idea is simply to encourage first time contributors (which we get on a daily basis) to get more involved and to really make the point that we do value their contributions. While it certainly won't be the silver bullet that will get people to automagically consider becoming long-time contributors, my hope is that it can contribute to getting some of them to come back.

FWIW, out of the 500+ unique individuals who contributed to Zephyr over the last 6 months, roughly 50% contributed 2 commits or less (in fact, 33% contributed only 1). Even if we capture a small portion of these folks, I'll consider this to be a win, but YMMV.

Copy link
Member

@stephanosio stephanosio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am very concerned about the isFirstPull function implementation:
zephyrproject-rtos/action-first-interaction@5d55935#diff-7934bf411fea192ad8cd69e0a12911648a2842cb0f2409a8fb67b41b7069d757R153

function isFirstPull(client, sender, curPullNumber, closed, page = 1) {
    var _a;
    return __awaiter(this, void 0, void 0, function* () {
...
        return yield isFirstPull(client, sender, curPullNumber, closed, page + 1);
    });
}

Here you are effectively querying every pull request that has ever been created in the repository whenever a pull request is opened or closed, with each query API request returning 100 of them.

We currently have a total of 38670 pull requests in the Zephyr main repository, and that means 387 API requests per every PR open/close!

This is simply not going to scale and we will hit the API request limit very quickly.

@nordicjm
Copy link
Collaborator

nordicjm commented Apr 18, 2023

FWIW, out of the 500+ unique individuals who contributed to Zephyr over the last 6 months, roughly 50% contributed 2 commits or less (in fact, 33% contributed only 1). Even if we capture a small portion of these folks, I'll consider this to be a win, but YMMV.

I've seen numerous PRs that are a first time contribution for someone fixing a typo or fixing a very minor issue with the documentation - and that's the only PR they ever do, it's a wrong assumption to assume that every contributor is going to submit multiple PRs to the project, maybe they're correcting an issue they saw and other than that they're entirely happy with how the code is. From my perspective I don't see the value this adds, if someone has something to contribute, they can contribute it, if not, then there's nothing to submit.

@carlescufi
Copy link
Member

As our Continuous Integration jobs run checks on your PR to ensure it's compliant and doesn't cause any issues

@kartben misleading: CI workflows for first-time contributors must be manually approved on every push

Not all of them though! Just a subset, which is confusing.

@carlescufi
Copy link
Member

carlescufi commented Apr 18, 2023

@kartben I have no objections to this PR, thanks for the effort in forking the original action and modifying it to add the functionality we need. The comments from @stephanosio however need to be investigated. I wonder if there is an easier way to find out? For example using https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#get-a-repository to get the contributor list and then check if the user is on that list?

@kartben
Copy link
Collaborator Author

kartben commented Apr 18, 2023

We currently have a total of 38670 pull requests in the Zephyr main repository, and that means 387 API requests per every PR open/close!

This is simply not going to scale and we will hit the API request limit very quickly.

I was just starting to think about it and yes, you're probably right :) I got misled by the way the original action was doing things, and the fact that it said that there's no API to filter PRs by creator (see https://github.com/actions/first-interaction/blob/main/src/main.ts#L126) so didn't look/think further.

I will look at @carlescufi's suggestion but it also looks like I can probably get all I need with the /search API (is:pr repo:zephyrproject-rtos/zephyr author:janedoe, for which the rate limit is 30 requests per minute which should be plenty.

@stephanosio
Copy link
Member

but it also looks like I can probably get all I need with the /search API (is:pr repo:zephyrproject-rtos/zephyr author:janedoe, for which the rate limit is 30 requests per minute which should be plenty.

Agreed. The search-based solution sounds quite promising.

The contributor list approach has the following issue;

This endpoint may return information that is a few hours old because the GitHub REST API caches contributor data to improve performance.

@dkalowsk
Copy link
Contributor

FWIW, out of the 500+ unique individuals who contributed to Zephyr over the last 6 months, roughly 50% contributed 2 commits or less (in fact, 33% contributed only 1). Even if we capture a small portion of these folks, I'll consider this to be a win, but YMMV.

I've seen numerous PRs that are a first time contribution for someone fixing a typo or fixing a very minor issue with the documentation - and that's the only PR they ever do, it's a wrong assumption to assume that every contributor is going to submit multiple PRs to the project, maybe they're correcting an issue they saw and other than that they're entirely happy with how the code is. From my perspective I don't see the value this adds, if someone has something to contribute, they can contribute it, if not, then there's nothing to submit.

I tend to fall in the same camp here. I find such automated messages to be annoying and generally a turn off to contributing further. I also don't see any harm in trying something new to encourage contributions. If it works, great. If it doesn't it can be iterated to a better solution or disabled later. Most of the regular contributors will never even see the message.

@kartben
Copy link
Collaborator Author

kartben commented Apr 19, 2023

Agreed. The search-based solution sounds quite promising.

And so much easier too! Action has been updated in this PR: zephyrproject-rtos/action-first-interaction#1

Adds the configuration file for a GitHub action that will greet first-time
contributor the first time they:
- open an issue
- open a PR
- get a PR of theirs merged

Fixes zephyrproject-rtos#56092.

Signed-off-by: Benjamin Cabé <[email protected]>
@kartben kartben requested review from nashif and dleach02 April 25, 2023 10:51
@mbolivar-nordic mbolivar-nordic merged commit a3ce0b0 into zephyrproject-rtos:main Apr 25, 2023
@nordicjm
Copy link
Collaborator

A side effect of this is you can now no longer tell the status of issues submitted, given the following list of queries, is someone dealing with them/asking questions or is it a bot posting a comment?

Screenshot_20230426_092734

@kartben
Copy link
Collaborator Author

kartben commented Apr 26, 2023

A side effect of this is you can now no longer tell the status of issues submitted, given the following list of queries, is someone dealing with them/asking questions or is it a bot posting a comment?

Screenshot_20230426_092734

I get your point but I'd argue that only using "has 0 comment" as the criteria to determine if someone has engaged is probably not the best approach in the first place as it can miss instances where the original author made several comments // see e.g the following issues, by only looking at the first two pages of opened issues
#56614
#56670
#56697
#57037

@kartben kartben deleted the add_config_for_pr_bot branch April 26, 2023 09:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants