As discussed with @ijemmy, I'd be happy to support with this one.

from aws-lambda-powertools-typescript.

Agree, additionally it'd be great if all issues could go by default in the "Issues" project as "Needs clarification or refinement (untriaged)" as well.

from aws-lambda-powertools-typescript.

Hi @AWSDB,
first of all thanks a lot for picking up this issue and detailing your proposal.
I noticed that the labels syntax has changes from key:value to key/value. I don't have a strong opinion about it, but do you find it more readable?

Scope

Are the possible values mutually exclusive? I am assuming not.
For PRs, it would be nice to add labels automatically based on changes happened on specific folders (docs, examples, .github). I would also add scope/cicd

Status

Looking at ways to reduce the manual tasks for maintainers, I think status/discussing is redundant. We acknowledge every open issue that is submitted, and then we politely reject it or agree on it.
Also, I am more keen on something like status/wontdo or similar rather than "status/rejected" as the latter feels more "confrontational" (in my opinion).

Type

It seems like this is a mix between our issue types and our semantic types.
Which one of the 2?

Pull request size

That's an interesting unit of measure. I normally look at PRs in terms of files.

from aws-lambda-powertools-typescript.

Thank you for the feedback @saragerion! Let me answer your questions.

key:value to key/value

It's rather category/value than key:value. E.g. compare with branch names like feature/something or bugfix/something. But we can surely use a colon instead of a forward slash keeping the key-value paradigm in mind - it's actually a matter of taste.

Scope
Are the possible values mutually exclusive?

I'd propose to keep them mutually exclusive (also for brevity). The scope label would describe the purpose, the main focus of the PR or issue. A packages PR can definitely contain tests (and actually should), as well as docs, but - from my point of view - labeling such PRs with all three labels (packages + docs + tests) adds not so much value. So I'd see the scope/* label not as "what's inside", but rather "what it's for".

Automated labeling for PRs is of course possible here (based on the changed content). scope/cicd fits into scope/infrastructure from my point of view. What do you think?

status/discussing

It's probably not the best naming. A better idea? My thoughts were: how would you tag issues that need some further input or clarification from the requester? "Feedback needed" or "On hold until clarified" etc. Do we want to distinguish such issues from the other ones? Otherwise, this label is redundant of course.

a mix between our issue types and our semantic types

Yes, it's a combination of both (a bit "condensed"). Do you feel like separating them would be beneficial? I tried to figure out the minimal number of types without being too verbose.

@dreamorosi, I agree - automation is key here. And I also believe some basic automation should be implemented right away, in the same PR - at least, the basic rules. This shouldn't bee too expensive to set up.

from aws-lambda-powertools-typescript.

This is an important feature for governance and management, but this shouldn't be a show stopper for the upcoming release candidate so setting a lower priority.

from aws-lambda-powertools-typescript.

Related to #133

from aws-lambda-powertools-typescript.

Here is my proposal how we could structure the labels for issues and pull requests. Please let me know if you'd like to change something!

Labels

General

Scope

Applies to: Issues, PRs

Status

Applies to: Issues

These labels do not resemble the columns in the Issues project, but rather focus on the actual issue state. The label helps understand if any action is required by maintainers or by the author(s).

Type

Identifies issues and PRs by their type. This label will be auto-assigned to all PRs linked to issues. For PRs without any issues (should be rarely the case), the label needs to be assigned manually.

Priority

Applies to: Issues, PRs

Identifies issues and PRs by their priority. Helps focus on things that really matter.
The PRs will get this label automatically from the issues they reference (if available).

Note: Won't Have is represented by status/rejected.

Source

Applies to: Issues, PRs

Identifies issues and PRs by their origin.
Helps keep track on the number of changes coming from the maintainers and from the community.

Packages

Applies to: Issues, PRs

Classifies the issues and the pull requests according to the changes needed in the tools (packages).
For issues, these labels can be assigned manually. For PRs, they will be assigned automatically based on the paths of the changed files. For issues and PRs not related to packages (like e.g. docs, infrastructure), no package/* labels will be assigned.
The label makes easier to identify the scope and see the statistics.

Pull request size

Applies to: PRs

Classifies the pull requests according to the number of changed code lines.
The label makes it easier to see how much time is needed for reviewing the PR.

Automation

from aws-lambda-powertools-typescript.

Thanks @AWSDB for the thorough proposal, I like it so far! Few notes/questions:

• Do you think it would make sense to add a scope/examples label, or would these fall under scope/docs?
• Would it be possible to try to label new issues with package/* & type/* based on the title? I know this won't work 100% of times but since we have templates in some cases it might work.
• What would happen to all the existing issues? Is there any way of re-labeling them according to the new system or should we do it manually (which is fine, just asking)

from aws-lambda-powertools-typescript.

Happy to discuss the points you mentioned, @dreamorosi!

• scope/examples: I think, we can decide what better suits our needs - scope/examples is more descriptive, but at the same time it adds a new label that doesn't much differ from scope/docs. Examples could be also seen as documentation, but they are of course somewhat different from the actual docs published. What would you prefer - a dedicated category or fewer labels?
• Auto-labeling: While we could define some regex guesses or rules, I doubt we can make this reliable enough. That means, we will still need to inspect and review the assigned labels for every issue. Should we maybe start without that first, settle the new labeling schema, and then try to add auto-labeling for package/* and type/*?
• Label migration: Some of the labels can be just replaced (e.g. bug with type/bug) - so old issues and PRs will automatically get the new labels instead of old ones. Not needed labels can be simply deleted. A script (manual workflow) can be created for automatically assigning new labels where possible (like size/* or package/*). Some labels will need to be assigned manually though.

from aws-lambda-powertools-typescript.

Agree with @saragerion here, I think automation is key to this topic. This way we can create a mechanism, on which we can iterate to improve it overtime, instead of relying on good intentions.

Not saying it has to be part of a single PR, I'd be happy to have one to set up labels and later automation but I'd like to at least get the ball rolling on this area before considering the issue as completed.

from aws-lambda-powertools-typescript.

⚠️ 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.

from aws-lambda-powertools-typescript.