Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question on proposal name format #4

Open
olitomlinson opened this issue Nov 18, 2022 · 6 comments
Open

Question on proposal name format #4

olitomlinson opened this issue Nov 18, 2022 · 6 comments

Comments

@olitomlinson
Copy link

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
Copy link
Contributor

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
Copy link
Author

olitomlinson commented Nov 18, 2022

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.

image

@mukundansundar
Copy link
Contributor

mukundansundar commented Nov 18, 2022

@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
Copy link
Contributor

cc @johnewart

@johnewart
Copy link
Contributor

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants