Currently the github app creates an issue in the discussion board as soon as it find a toxic comment of the user. Deciding hostility of user on basis of 1 comment is not correct. We should increase the toxic comments limit from 1 to 5, so we are sure that the user is actually hostile

Currently the app searches for opened issues for users who have been hostile and open issues for newly found hostile users in maintainers-discussion repo inside the app's installers account. We have to move that to {appInstallerName}-discussions repo under probot-background-check org.

Hey all! 👋

I am Aditya Agarwal. A pre-final year CSE undergrad at JSSATE Noida, India.

This April, I got selected as Student Developer at Probot in Google Summer of Code. 😄
I would like to thanks @bkeepers , @gr2m , @JasonEtco , @wilhelmklopp and the awesome Probot community for giving me this opportunity.

So, this summer, my major task here is to develop a Background Check application for GitHub.

In this locked issue, I will be sharing weekly updates on my progress.

Please feel free to share any ideas, suggestions, updates, etc., by creating an issue for it or discussing about it in #contributors on Slack!

on installation of app, create a repo for the owner

Add getUserDiscussionIssue sandbox to directly run getUserDiscussionIssue without any mocks etc.

Example -

expect(toxicScore).toBeGreaterThanOrEqual(toxicScore)

Currently the app's org is set to probot-background-check, but this temporary and most likely to change. After @JasonEtco @bkeepers set up a org with private repo plan, that org will be used. Other than that, developers who deploy their own instance of the app will most likely use a different org for their version of this app, so there should be a central place where they can update the org name and not jump in different files to do this

@itaditya I got an instance of this repository deployed and the app is installed on this repository: https://github.com/apps/background-check. Any change that makes it into master will get automatically deployed.

What permissions do you need the GitHub App to have? Here's what is currently selected:

And here are the events that it's subscribed to:

Maintainers should be able to view the list of comments which the app flagged as toxic.

When the github app is installed on an account (individual or org) (referenced as appInstallerName from now) the person who installed the app (sender in payload) should be added as collaborator to {appInstallerName }-discussions repo under probot-background-check org.

currently we are using assertions only. The problem that arise is that the expected output has to be first logged to console and then copy pasted in the assertions. This can be avoided via snapshot testing. In the latter approach, jest will create a snapshot of the output and store it in files. Next time we run test jest itself cross checks the output with the snapshot and raises error if they don't match. If the change was expected we just have to call jest with -u flag to tell jest to update the snapshots with the new output.

Based on feedback from @JasonEtco , it is concluded that the description must be, well, more descriptive 😅 . The description must describe the meaning of background checking effectively.

When a person installs the github app, a discussion repo in probot-background-check should be created

Due to the PR #68 the inline docs at some places are incorrect. Fix them

dependency injection will help us to unit test backgroundFinder easily

Following the example given in https://probot.github.io/docs/testing/ setup basic unit tests for backgroundFinder

Since the probot-background-check org has now the ability to create private repos, the app should switch the discussion repos to private repos only

In the past implementation, a maintainers-discussion repo was required for the app to function. This is not the case now, so that part should be removed from the readme

Currently in analyseSentiment.test.js many tests make request to Perspective API. This is taking too much time to finish and might blow the API quota limit. To solve this, use nock for most tests and in only one test send the request to the API

When installing https://github.com/apps/background-check to one of my repositories, these were the permissions requested:

... permissions:

• Read access to code
• Read access to metadata
• Read and write access to administration, issues, members, and pull requests

Is there no way to not need write access to all those?

The github-api contains these methods -

createDiscussionIssue
getCommentsOnIssue
getUserCommentedIssues
getUserDiscussionIssue

Write unit tests for each of the following

cover api docs for github-api functions

Hi @itaditya, we were looking through all of Probot's repositories and decided we have to reduce the maintenance overhead of the Probot team. One thing that would help us is to move some of the apps out to the account of the people who created it.

As you created the background-check app, would you mind moving it to your account?

Use Perspective API to run sentiment analysis on the text extracted from user comments and use the toxicity information for further actions of the bot.

Hi @itaditya.

I see this bot is "finds background of github users" but I'm not sure what that means. Can you clarify?

As mentioned by @gr2m

gregor [11:56 PM]
@dev_aditya you probably discussed that already, but I wonder if there is an alternative to a private repository? I fear it will prevent a lot of open source projects that use a GitHub Organization to use it due to the cost of an upgrade for private repositories. I wonder if the app could post a message to a team chat for example :thinking_face: Not sure if an app can do that

These are all valid points. Would love to know everybody's opinions on this.

/cc @bkeepers @JasonEtco

Currently the app will error out since getUserDiscussionIssue & createDiscussionIssue dependency is not provided to backgroundFinder in index.js. The tests didn't catch it because in the tests the mock of getUserDiscussionIssue & createDiscussionIssue dependency is indeed provided

This can be useful later on

Currently we pass analyseSentiment util and PERSPECTIVE_API_KEY to backgroundFinder. However backgroundFinder has no direct requirement of PERSPECTIVE_API_KEY. It just uses the key to pass to analyseSentiment which returns a sentimentAnalyserInstance. This creates a lot of confusion.

It's much better to pass a sentimentAnalyserInstance to backgroundFinder

use jest to write unit tests for sentiment analyser

In case of false positives, the maintainers can close the issue opened for a user in the maintainers-discussion repo. To implement this feature, we just have to limit the discussion issue search to open issues only.

Currently context is passed to github-api methods and then context.github is used to make requests to github. This tightly couples these api methods to the app and to probot. Instead if we just use a github parameter then we can pass any github client like octokit etc. and still use the github-api methods.

Currently, we use getUserCommentedIssues to get 30 (due to pagination) issues as search result. Then for each issue we get 30 (again due to pagination) comments from which we filter out the user's comments. Then we run sentiment analysis on the user comments. Till we don't exhaust the toxic comments limit, the app keeps on fetching comments on issues. This must have an upper limit other wise the app will waste to much time on one user only

Use documentation.js to generate API docs for the github app

When a hostile user is found, open an issue regarding him in the org's maintainers-discussion repo

The functions don't check if the passed parameter even exist or not. This can cause issues while usage.