chore: Modified bug issue template to add checkbox to report potentia…

[bhavya2109sharma]

• Modified bug issue template to add checkbox to report potential regression.
• Added GitHub action to add/remove label potential-regression when issue is created/edited.

NOTE:

• The GitHub action code was ported from CDK repo.
• The label potential-regression would need to be created manually (we could use color #FF6700 and description Marking this issue as a potential regression to be checked by team member to make it consistent across SDK repos)

Label potential-regression would make issue standout in the list and help engineers to handle high severity issues effectively.

[lucix-aws]

I don't see any merit in having this workflow.

• This should be determined at triage, I don't expect or necessarily even trust an issue reporter to try and make the distinction of whether or not the behavior they're describing constitutes a regression.
• The term "regression" is ill-defined here especially when you consider that we have a v1 SDK. I know we have a separate issue template for that, but those guidelines aren't exactly infallible.

At best it isn't really giving us any value, at worst it's creating an impetus to triage/investigate something on the potentially false grounds of it being a regression.

[ashishdhingra]

I don't see any merit in having this workflow.

• This should be determined at triage, I don't expect or necessarily even trust an issue reporter to try and make the distinction of whether or not the behavior they're describing constitutes a regression.
• The term "regression" is ill-defined here especially when you consider that we have a v1 SDK. I know we have a separate issue template for that, but those guidelines aren't exactly infallible.

At best it isn't really giving us any value, at worst it's creating an impetus to triage/investigate something on the potentially false grounds of it being a regression.

@lucix-aws Thanks for sharing the concern. The proposed change was first implemented in CDK in response to a regression that was lingering around for almost a month and was escalated to management. It was due to misinterpretation of the issue during triage by the team which resulted in potential security breach in customer's infrastructure. After the implementation, it has helped team to quickly identify at least 50% of the regression issues flagged by this change during triage.

Triage happens after a team member self-assigns the issue. There might be times when there is a good backlog of issues that need to be triaged and it might delay triage of actual regression issues. The intent of this change is to avoid potential delay in triage of such issues.

Hence, based on discussion within the team, we felt it is valuable to implement this change across SDK(s) as it would help identify such issues more effectively during triage. There is an assumption assumption that some of these issues might not be regression, but it's always wise to treat such issue as p0, which could be downgraded later if that is not the case.

Please free to reach out to @kellertk if there is any concern.

Thanks,
Ashish