Actions that can trigger the dwylbot

[SimonLab]

dwylbot on PRs

• When a PR is assigned to someone then add "awaiting-review" label on the PR and on the issues listed in the description of the PR Feature: automatic awaiting review label upon reviewer added to PR #62

• When a PR has "awaiting-review" label and the PR's author belongs to the team of the project then add a comment to the PR with "Please assign someone to review your PR, thanks" Feature: reminder to assign reviewing if PR has awaiting review label #63

• When a PR has "awaiting-review" & merge conflict then add "resolving-merge-conflict" label, assign the author of the PR and add comment on the issue with "Hi, please resolve the merge conflict and reassign, thanks" Feature: assign author and comment on PR if a merge conflict occurs after a correct pr is merged #64

• When a PR is assigned to someone & the description contains "fixes/closes #{issue number}" then add a comment to the PR with "Please change fixes/closes to see or linked to #{number issue} to avoid Github to automatically close the issues without letting the Product Owner testing the solution on the issues". (Unfortunately the issues will be closed if some commit messages have "fixes or closes")

• When a PR is merged then add "please-test" label to the issues linked to the PR

• When a PR is created with an empty description or without any issues linked to the PR then add a comment to the PR: "Please add a complete description of your PR with the references to the issues" and assign the author of the PR

• When a PR has "awaiting-review" and the coverage on the PR is going down then remove "awaiting-review", assign the author and add comment "Please improve the coverage"

• When a PR has the "awaiting-review" label and the Readme.md hasn't been updated then add a comment to the PR with "Please update the Readme"

• When a PR has the "awaiting-review" label and some files have been deleted then add a comment to the PR with: "This PR will delete some files!" and assign the author of the PR for confirmation

• When a PR has the "awaiting-review" label and some images or binary files have been added then add a comment with "Some binary files are will be included with this PR, is this ok?" and assign back the author of the PR for confirmation

• When a PR has "awaiting-review" label and the tests are failing then add the label "updating-tests" and assign the author of the PR Feature: automatic assignment of updating-tests label #65

• When a PR has some labels in conflict ("awaiting-review" & "in-progress") then add the label "conflict-labels" and add a comment with "Please resolve the labels conflict"

• When a PR as "awaiting-review" label and the version of the applcation hasn't been updated then add a comment with "Please update the application version" and assign the author of the PR Feature: PR awaiting review automatic reminder if application version is outdated #66

• When a PR is merged then delete the branch

• When a PR as "awaiting-review" and some unchecked checkboxes in the description then add a comment with "Some checkboxes are not ckecked!", remove "awaiting-review" label and assign the author

dwylbot on issues

• When an issue is inactive then add a comment with "Is this issue still needed?" Automatically Remind People to Review/Close and issue after set time? #3

• When an issue stay inactive after a first warning message then close the issue, assign the author of the issue and add a comment "This issue is inactive and had been close, please reopen it if it's still needed"

• When an issue has the "in-progress" label and no one is assigned to the issue then add a comment with "Please assign someone" and assign the author of the issue Feature: "in-progress" label with no assignee #7

• When an issue has the "in-progress" label and no estimation time label has been added then add a comment with "Please estimate the issue before starting working on it" and assign the author of the issue Feature: warning on in-progress issues with no time estimate  #61

• When an issue has the "in-progress" label and the time spend on the issue is greater than the estimation time then add a comment with "The issue is taking longer than estimated, any help needed?"

[nelsonic]

@SimonLab these features looks good as a starting point. please pick one to start with and create a user-story/issue for it. 👍

[iteles]

@nelsonic We walked through these yesterday as well. They will eventually each be their own issue but @SimonLab is starting with #7 (comment)

[samhstn]

Some ideas that have come to mind:

• Ensuring issues have descriptions, dwylbot should explain good practices for issues when this happens New issue must have a description #76
• I would like gitbot to tell you to write smaller prs when you make a pr that is too long
• Writing commits that are too small which would create bad commit histories should be addressed, dwylbot should tell you to use git commit --amend instead and to be told that it's never bad to make too many prs, but is bad to have too many commits in prs
• I would like gitbot to ensure commit messages arn't too long
• I would like gitbot to tell you to rebase branches to make pr reviewing easy to read
• If I assign someone who isn't me and add the awating-review label, I would like gitbot to place those people as reviewers

I also think that one would find the dwyl contributing guidelines easier to digest if portions are shown the first time a user does a particular github action (open an issue, make a pr).