Maintenance: revisit automation for Issues and PR's

[saragerion]

Note, the body of this issue was edited to reflect the new scope:

• If possible, when a new issue is created we should add it to the GitHub project (note, this is not a Project (classic) in GH nomenclature)
• Review & make sure that when a new PR is opened, this job runs and if the PR body doesn't contain a string that matches this regex, which should be Issue number: #digits, the proper labels and comments are added to the PR.
• Review & make sure that when this workflow runs and labels an issue as status/pending-release, it also removes the current status/* label as well as help-wanted (if present).
• If possible, implement this workflow in this repo, with the difference that in our case it: 1/ queries all issues marked as status/pending-release (which should be all closed), 2/ removes the label, 3/ adds a label status/completed, 4/ leaves a comment that says the thing has been released (this last point is optional & not a must)
• If possible, extend this workflow to label PRs with the correct areas based on title suffix and with the areas being the utilities only (i.e. area/logger, area/parameters, etc. - full list here)
• If possible, implement a boring cyborg workflow that does this for Issues and this for PRs.
• Consider renaming this workflow to remove V2 notation

Older issue body below, hidden for clarify/brevity and to reflect the new focus.

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

1. AWS Lambda Powertools Typescript - Issues https://github.com/awslabs/aws-lambda-powertools-typescript/projects/2
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

[saragerion]

@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).

[dreamorosi]

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.

[saragerion]

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.