all: improve automation for Issues and PR's (Github projects, labels, milestones, releases, changelog)
Description of the feature request
Problem statement
To keep up with our collaboration, for clarity, and make sure our efforts are tracked, there are 2 Github projects: https://github.com/awslabs/aws-lambda-powertools-typescript/projects
- AWS Lambda Powertools Typescript - Issues https://github.com/awslabs/aws-lambda-powertools-typescript/projects/2
- AWS Lambda Powertools Typescript - Pull Requests https://github.com/awslabs/aws-lambda-powertools-typescript/projects/3 All explanations of each column are added in the boards. While this structure is helpful, there is margin of improvement for how we can limit the manual effort to keep things tidy so that we understand what's going on.
Summary of the feature
Github related automation so that:
- Newly created issues SHOULD be added to the Issues board;
- Newly created issues / Issues that are in the "Needs clarification" column SHOULD NOT have assignees (because assignees = responsible to implement it);
- Newly created issues SHOULD be created with the relevant labels, no assignees, correct projects assigned;
- Issues that are in done done state should be automatically added in form of excerpt and references to the Changelog file and releases descriptions;
This can be achieved through relevant files/setup/configuration via Github actions or files in the .github folder.
Code examples
TBD.
Benefits for you and the wider AWS community
Automation of these tasks will allow maintainers and contributors to focus on the implementation of features rather than administration of tasks. Additionally, shifting the effort from human intervention to automation will reduce the rate of human errors.
Describe alternatives you've considered
Not at the moment.
Additional context
N/A.
Related issues, RFCs
@dreamorosi @bahrmichael @alan-churley keen to hear your perspective on this. Note that this is not a priority (which is why I did not add it to the beta milestone).
Thank you Sara for the proposal, hard agree on the topic.
Regarding PRs we could leverage the same boring-cyborg that the Python repo uses; since a PR contains the path of the changes labelling it should be easy enough to automate.
Regarding issues, we could use an action like this one which should allow us to remove assignees, add labels, and move to a project.
As pointed out by @DanyC97, there is an opportunity for us to explore the new beta projects that are set at a github org level.
I have updated the body of the original post to reflect the current scope, after which we can consider the issue complete.
cc @am29d
⚠️ COMMENT VISIBILITY WARNING ⚠️
Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.
⚠️ COMMENT VISIBILITY WARNING ⚠️
Comments on closed issues are hard for our team to see. If you need more assistance, please either tag a team member or open a new issue that references this one. If you wish to keep having a conversation with other community members under this issue feel free to do so.