Proposal of events for updating labels on issues and pull requests

[johlju]

These are the events around labels for issues and pull requests. These events would preferably be automated as far as we can. In the beginning this need to be done manually (as today). This is to reduce the repetitive work when maintaining the resources. These events are a first draft and are up for discussion. The list will be updated from discussion here, but also when more repetitive work is found. Maybe not all of these will be a reality.

Issues

Event	Add tag	Remove tag	Assigned	Comment
Contributor creates issue	--	--	Manually assignment, or assigned automatically to all maintainers individually.	GitHub support confirmed that it is not possible to assign an issue or PR to a team. Neither is it possible for a team to consist of both collaborators and organizational users.
Contributor creates issue for a new resource module submission	Manual New module submission		Entire community, so no assignment on these.	Automated comment linking to the documentation on how, and the requirements, to make a new module submission linking your own resource module to DSC Resource Kit. The issue should remain open for community feedback.
Contributor creates issue for 'resource module proposal'	--	--	--	These issues can be closed with a, preferrably automated, comment linking to documentation on how to publish your own resource module and how to link your own module to DSC Resource Kit.
Maintainer comments on issue	Manual Question, Bug, Enhancement, Documentation, Tests, Resource proposal, Needs investigation, Needs more information as the maintainer sees fit. 'Good first issue' should be set on those issues that can be taken up by a beginner who wants to learn the process of contribute on GitHub. 'High priority' should only be used in rare circumstances and is up to the maintainer.	Manual Needs investigation, Needs more information as the maintainer sees fit	Manual Re-assigned by maintainer if needed
Issue is assigned a 'work' label (Bug, Enhancement, Documentation, Tests)	Help wanted	--	Entire community, so no assignment on these.	An automated comment telling that this issue is up for grabs by anyone in the community.
Contributor comments that issue is being worked on	Manual In progress	--	Manually Assign to contributor. Currently not possible to assign to other than issue creator and organizational user.
Issue is mentioned in open PR	Manual In progress	--	Manually Assign to creator of PR. Currently not possible to assign to other than issue creator and organizational user.
Issue creator writes comment	--	--	--
Contributor, other than issue creator writes comment	--	--	--
Issue creator closes issue	Closed by author	Needs investigation, Needs more information	--
Maintainer closes issue	Manual Abandoned, By design, Duplicate, External, Not fixed.	Needs investigation, Needs more information	--	Maintainer also needs to comment why they are closing the PR.
Issue is closed by PR	--	Needs investigation, Needs more information, Help Wanted, In progress	--
Issue creator is unresponsive for 2 weeks	--	--	--	Only when label is 'Need more information'. Push automatic comment requesting a response.
Issue creator is unresponsive for 3 weeks	--	--	--	Only when label is 'Need more information'. Automatically close the issue.

Pull requests

Event	Add tag	Remove tag	Assigned	Comment
PR creation	Needs review	--	Manually assignment, or assigned automatically to all maintainers individually. Doesn't seem possible to assign an issue or PR collectively to a team. Neither does it look like a team can consist of both collaborators and organizational users.	Add an automated comment to the PR with a link to our documentation on how the review process works and what will happen next.
CLA bot test fails on PR	Waiting for CLA pass	Needs review, Waiting for author response, Waiting for code fix	--
CLA bot check passes and Tests check passes on PR	Needs review	Waiting for CLA pass, Waiting for code fix, Waiting for author response	--
Tests fail on PR	Waiting for code fix	Needs review, Waiting for author response	--
Contributor other than PR creator makes a comment through Reviewable	Waiting for code fix	Needs review, Updated by author	--	Automatic comment (when author is first-time-contributor) how contributor responds on review comments, for the reviewer to acknowledge comments.
Contributor other than PR creator makes a comment in the PR	Waiting for author response	Needs review	Manual Re-assigned by maintainer if needed	Should not add label if label 'Waiting for code fix' is already assigned.
PR creator adds new code to PR	Updated by author, Needs review	Waiting for author response, Waiting for code fix	--
Contributor other than PR creator approves PR (via GitHub review or LGTM comment from Reviewable)	Ready for merge	Updated by author, Waiting for author response, Needs review	--	Note: Soon Reviewable will support GitHub review approvals.
PR creator comments on PR	Updated by author, Needs review	Waiting for author response	--
PR creator closes PR (no merge)	Closed by author	Anything else	--
Maintainer closes PR (no merge)	Manual Label showing why the PR was closed OR no label and just a comment if PR is getting re-opened immediately	Anything else	--	If the CLA was not signed, we should make sure that label is kept when closing.
Maintainer merges PR	--	All labels	--
PR creator is unresponsive for X weeks (and CLA passed)	abandoned	Anything else	--	At this point another contributor may continue the work.
PR creator is unresponsive for X weeks (and CLA failed)	--	All labels	--	Automatically close.
When PR has merge conflict	Waiting for code fix	Needs review, Waiting for author response	--	Automatically write a comment saying that a merge conflict has occurred and a rebase is need, plus a link to instructions on how to make a rebase.

[johlju]

I have looked into automating these labels - I have gone through a bunch of GitHub Apps and looked at GitHub marketplace. Conclusion so far is that there are no GitHub Apps or tools that can completely handle our process/workflow. I love feedback from the community if there are apps that can help us that I missed!

Some GitHub Apps do potentially help a bit.

• Stale
  • Pros: For issues, can remind on issues that the issue will be closed if no more comments are made, and closes after a while, but only on issues that has not been assigned as work (bug, enhancement, etc). For pull requests it can label an issue as 'abandoned' when the issue is not label 'needs review' or 'on hold'.
  • Cons: None.
• Review Me
  • Pros: Adds and removes label 'needs review' when all status checks are success or one or more is failed.
  • Cons: Can only handle one label and one status. So we can't handle 'Waiting for CLA pass'.
• Label issues targeted by open pull requests
  • Pros: Labels issues with 'in progress' when a pull request references the issues using a closing keyword, and removes the label from the issues when PR is closed.
  • Cons: Big con - need permission to write access to code! Doesn't look like the BOT should need it to do the task.
• Welcome
  • Pros: See cons.
  • Cons: Couldn't get this one to work, and looking at the code it counts number of issues (PR's) the author has made, and if that is equal to 1 then it is suppose to post a welcome message. But could never get it to work. Might have been me making a mistake.
• No response
  • Pros: It closes issues with ‘needs more information’, but Stale does this too and more.
  • Cons: None.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[johlju]

Reviewable have finally released the new GitHub reviewer support - so now the same events can be used regardless where the PR is reviewed. 😄 We should update the events descriptions to reflect this change.

Although it is a limitation that PR authors can't approve there own pull requests, so there it is still needed to 'LGTM' in a comment, although I think such review and merge should be handle as a manual process.