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

Switching to pull requests for design proposals #638

Open
wipfli opened this issue Apr 30, 2024 · 2 comments
Open

Switching to pull requests for design proposals #638

wipfli opened this issue Apr 30, 2024 · 2 comments

Comments

@wipfli
Copy link
Contributor

wipfli commented Apr 30, 2024

I have sometimes a hard time understanding at what stage a design proposal is. I think the problem is that we currently use issues for design proposals which are basically a running discussion thread. There is no clear signal if the design proposal was accepted, rejected, or is waiting for feedback from the author or other community members.

To improve that situation we could start using labels like "approved", or "waiting for feedback" as one solution.

Or we could start using pull request for design proposals. The advantage of pull requests would be that you have at the end of the process a written document which states what the plan is and which everyone hopefully has agreed on.

What do you think @HarelM and @louwers as maintainers? What do you think @msbarry and @DavidBuerer as people who recently contributed design proposals?

Thanks for the feedback in advance!

@wipfli wipfli added bug Something isn't working and removed bug Something isn't working labels Apr 30, 2024
@louwers
Copy link
Collaborator

louwers commented Apr 30, 2024

I think most of the time it makes sense to have a discussion up front before a design proposal is written. Some of the design proposal issues are more vague ideas, and that is OK too.

Instead of labels I would use a Project, because there's an associated board with a clear progression.

Maybe we can start with:

  • "Idea"
  • "Gathering Feedback" - when a concrete design has crystalized.
  • "Approved" - when there is a consensus around a concrete design and it can be implemented.
  • "Added" - when a a design proposal was added to the spec.
  • "Rejected" - when a proposal failed to gather enough approval.

@HarelM
Copy link
Collaborator

HarelM commented Apr 30, 2024

The question from my point if view is how to track implementation of the spec changes.
Issues and PRs are relatively similar in terms of a discussion in Github, so I don't have strong feelings either way.
A possible problem with a PR is that it talks about implementation in some cases, and starting a discussion after someone opened a PR is sometime discouraging, or at least this is how I perceive it.

Regarding the state - if the spec (v8.json and/or the docs) was updated then a decision for the spec update was approved, otherwise, it wasn't.

Since this is a community decision, sometimes it's hard to define when something is approved, or what other information is needed to get it approved.

But, feel free to push a process change to improve this.

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

3 participants