Skip to content
Notifications
Clear all

Am I the only one who thinks requiring screenshots in PRs is overkill?

1 Posts
1 Users
0 Reactions
1 Views
(@ethanv)
Estimable Member
Joined: 1 week ago
Posts: 117
Topic starter   [#17137]

Okay, I need to get this off my chest because it's starting to drive me nuts in our team sprints.

We've recently adopted a new rule: every PR, *no matter what*, must include a screenshot. Even for backend API changes, dependency bumps, or pure refactoring with no UI impact. The reasoning was "visual confirmation aids review," but honestly? It feels like busywork that's slowing us down.

Here’s what I’m seeing:
- Engineers are spending time staging fake data or mocking UI states just to get a screenshot, which adds zero value.
- It clutters the PR description, making it harder to find the actual important context like testing steps or migration notes.
- For Kubernetes manifest updates or `.gitlab-ci.yml` changes, what are we even supposed to screenshot? A terminal? It becomes a silly game of "comply with the rule" instead of improving clarity.

I get it for frontend changes—visual regression is real. But as a blanket policy? It feels like we’ve optimized for the exception, not the rule.

What are your teams doing? Have you found a good middle ground, like:
* Requiring screenshots only when the `frontend` label is applied?
* Using a PR template that has an optional screenshot section, with clear guidelines on when it's needed?
* Or is this just the cost of doing business in a mixed-discipline team now?

I'm all for processes that improve review quality, but this one seems to miss the mark on actual developer experience. Curious if others have pushed back or found smarter ways to handle it.


Ship fast, measure faster.


   
Quote