Question on proposal name format

[olitomlinson]

What's the value in having this information encoded in the file name?
Why not simply embed it into the proposal template itself?

https://github.com/dapr/proposals#proposal-name-format

[mukundansundar]

What's the value in having this information encoded in the file name

Try to get information on what area that proposal affects at a glance.

Why not simply embed it into the proposal template itself?

Agree it should ideally be part of the template also.

https://github.com/dapr/proposals#proposal-name-format

[olitomlinson]

Agree it should ideally be part of the template also.

Doing both invites the opportunity for them going out of sync. So wouldn't recommend putting it in both the filename and the body of the proposal.

My question, is it more important to have it in the filename or in the body of the proposal?

Consider this, if the objective is to be able to triage/categorise in-flight proposals that touch the same area (B,C,I,P,R,S) then I think there needs to be a better mechanism to allow that search and selection. Using labels is a simple and effective mechanism for this.

[mukundansundar]

@olitomlinson Good point. These labels can be added by PR author manually if needed.
Probably have an Affected Areas section within the proposal template.

Affected Areas

remove the quote indent for affected areas
/area/runtime
/area/building-block
/area/components
/area/sdk
/area/proposal-process
/area/cli

We can also have automation.
Once a PR is created have a dapr-bot automation that labels the PR based on the defined areas.

WDYT?

[mukundansundar]

cc @johnewart

[johnewart]

The only downside (and it's probably not a huge issue) is that the functionality is tied to GitHub bots doing some work and, if you clone the repository, you won't have the tags locally so the information is lost. That being said I don't have any hard attachment to the actual approach and labels have the benefit of being useful in GitHub queries / filters / etc.

[artursouza]

I agree that the current format is too complex. I would simplify it to:

YYYYMMDD-<short title>.md

It is highly unlikely two parallels proposals will conflict and the date can simply be the date the PR is created. It will give us a sense of chronological order without being too strict about the format.