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

[Meta] Can PRs involving design and layout changes be passed without design review, if they're only available under labs? #19856

Closed
ShadowJonathan opened this issue Nov 22, 2021 · 3 comments

Comments

@ShadowJonathan
Copy link
Contributor

I just saw #19754, and i'm curious if this is something that's allowed in general;

When opening a PR that involves design and layout, would it be allowed to be merged without X-Needs-Design, if the feature is entirely contained in labs?

Notably, all features which involve visual changes involve the design team, however, seeing this exception being implied, i'm curious if more PRs could be merged and un-labbed later down the line if the design team approves of it, and/or get un-labbed without much fuss as the design team recommends tweaks, This would mean users could enjoy the feature early, while formal design gets hashed out behind the scenes.

@ShadowJonathan
Copy link
Contributor Author

(Apologies if i jumped the gun on this, but even if, this'd be a formal request to allow PRs to land in labs if the design team is busy or blocked)

@ShadowJonathan ShadowJonathan changed the title [Process] Can PRs involving design and layout changes be passed without design review, if they're only available under labs? [Meta] Can PRs involving design and layout changes be passed without design review, if they're only available under labs? Nov 22, 2021
@turt2live
Copy link
Member

It largely depends on the actual PR in question. While the formal policy allows for features to land behind labs without Design involvement, it's not usually the best way to go about things. There's also still a requirement that the dev team/product be okay with the feature moving forward, which typically happens as a discussion behind the scenes.

In the case of #19754, the goal is to accelerate progress on the feature by deliberately landing something that mostly works so the design team can create mockups and another team can write the required changes. For other cases, like developer tooling, we tend to let it through if it has an immediate need. The general case of feature development is more involved and typically works best with continuous design signoff throughout the development process.

For future reference, questions like this are best asked in the room. The issue tracker is best for raising feature requests and bug reports, not necessarily clarity on policy decisions or support.

@ShadowJonathan
Copy link
Contributor Author

ShadowJonathan commented Nov 22, 2021

Ah, thanks for the quick response.

I didn't want to ask this question in the room, as I thought it would interrupt too much, and i think it's useful to have a issue # to refer back or forward to. I'll keep this in mind for the future though.

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

2 participants