Case study 2 of 2 · all case studies

A light theme request open for two years: when demand is clear and the decision is not

A worked example of turning a long-running feature request (netbirdio/dashboard#412 (opens in a new tab)) into a decision, requirements, and a UX concept. Where the first case study was about a bug whose existence was in doubt, this one is about a need nobody doubts and a decision nobody can see.

Read this first. This is an independent portfolio exercise, not affiliated with NetBird and not a statement about its roadmap or its people. It uses the public issue, its 22 comments, and the public metadata of three linked pull requests, all read on 12 Oct 2026. NetBird’s source code and its dashboard’s actual colors were not reviewed or measured. The visible thread is not the whole story: decisions can happen elsewhere, and silence in a thread is not proof of inaction. Commenters’ usernames are not shown.

What the issue says

Live metadata

State: Open
Opened: 9 Sept 2024
Last updated: 8 Oct 2026
Comments: 22
Labels: needs-triage, feature-request
Data: Live from GitHub (cached up to 15 minutes)

The user’s need

The reporter, who describes themselves as an older developer, finds the dashboard’s dark theme (gray on black) hard to read. They ask for a light theme and point out that the documentation site’s light theme is readable.

They also notice a theme control in the top right where Light and System are shown but disabled, and wonder whether the feature is in the works.

Evidence and verification status

Each claim says who made it and whether anyone has verified it. Most of the “verified” items here are GitHub's own public counts and metadata, which are facts; the explanations for them are not.

Reported, not measuredIssue description by the reporter
The reporter finds the dark theme (gray on black) hard to read, says the light theme on the documentation site is readable, and notes a theme control in the top right whose Light and System options are disabled.
Verified (GitHub data)GitHub public data, read on 12 Oct 2026
The issue has 29 thumbs-up reactions and 22 comments over about 25 months. It is still open and still carries the label needs-triage.
Reported by othersThree comments by other users
Several commenters give personal reasons for wanting a light theme: older eyes, astigmatism, and working in direct sunlight. This analysis does not evaluate those medical or environmental claims.
Verified, with a caveatGitHub author association of each comment
None of the 22 comments comes from an account GitHub marks as owner, member, or collaborator. Three come from accounts marked “contributor” that speak about the project’s progress, which shows this signal can understate real team involvement.
Verified (visible thread)The visible thread only; replies may exist elsewhere, for example in the pull requests
Maintainers were asked directly in April 2025 whether the feature is wanted, and in August 2026 to review the two open pull requests. No reply from a team member is visible in the thread.
Verified (GitHub data)GitHub pull request metadata
Community pull request #461 (“Added light/system theme”) was opened on 29 Apr 2025, changed 110 files, and was closed without merging on 27 Aug 2026, with no inline review comments.
Verified (GitHub data)GitHub pull request metadata
Pull request #658 (“Add Light Mode Switching”) was opened on 2 Jun 2026 and is open, with 52 commits, 176 changed files, and 19 inline review comments.
Verified (GitHub data)GitHub pull request metadata
The client’s light mode (netbirdio/netbird#7344) was opened by a project collaborator on 28 Aug 2026 and merged on 11 Sep 2026 after 22 inline review comments.
Stated in a commentComments by accounts marked “contributor”
Light mode is part of release candidate 0.79 of the client, the dashboard is next, and final touches are being made after feedback from a front-end engineer.
UnknownNobody has measured it in the thread
The existing dark theme fails contrast requirements.
UnknownNot explained in the issue thread
Why pull request #461 was closed, and what #658 still needs before it can merge.

The triage board’s discussion panel can load the real thread, with commenter names left out, so that you can check the claims above yourself.

Discussion (22 comments on GitHub)

Loaded only when you ask, to stay within GitHub’s rate limit. Commenter names are not shown; each comment links to the original.

Timeline

Items marked “Verified” come from GitHub's data. The one marked “Stated in a comment” is what a commenter said, which was not checked here.

9 Sep 2024Verified
Issue opened, labelled needs-triage and feature-request.
21 Apr 2025Verified
A commenter points to a community-built container image with a light-mode branch. It is third-party and was not evaluated here.
29 Apr 2025Verified
Community pull request #461 is opened (110 files). The same week a commenter asks the maintainers whether the feature is wanted.
Oct 2025 to Jul 2026Verified
A steady stream of short upvotes and requests for news, plus three comments giving personal reasons (older eyes, astigmatism, direct sunlight).
2 Jun 2026Verified
A second pull request, #658, is opened.
6 Aug 2026Verified
A commenter asks the maintainers to look at the two open pull requests and decide how to proceed.
27 Aug 2026Verified
Pull request #461 is closed without merging, 16 months after it was opened.
28 Aug to 11 Sep 2026Verified
The client’s light mode is opened by a project collaborator and merged two weeks later.
15 to 21 Sep 2026Stated in a comment
Contributors say light mode is in release candidate 0.79 and that the dashboard is next, with final touches under way.
8 to 9 Oct 2026Verified
A commenter reports the dashboard pull request is still pending. Pull request #658 is updated the next day and remains open.

Demand versus decision

The interesting thing about this issue is not how many people want a light theme. It is how little of that demand turned into a visible decision.

Demand: loud and consistent

29 thumbs-up reactions and 22 comments over about 25 months.
By this analysis's count, 10 of the 22 comments are short upvotes or requests for news, 3 add a personal reason, and 7 carry information (pointers and status).
Two separate community pull requests and a third-party image, built without being asked.
Independent reasons that go beyond taste: older eyes, astigmatism, glare.

Decision: hard to see from outside

No owner, member, or collaborator comment in the thread, though accounts marked “contributor” did post status updates.
Direct questions to the maintainers in April 2025 and August 2026 with no visible reply.
The first community pull request closed after 16 months with no inline review comments.
The label is still needs-triage after 25 months.
By contrast, the client’s light mode, opened by a project collaborator, merged in 14 days after 22 inline review comments.

What this analysis concludes, and how sure it is

Hypothesis, not fact: the bottleneck was not demand but prioritization, ownership, and review capacity. Demand was visible within weeks; the first sign of a team-led change came after more than two years.

Other explanations fit the same facts: the team may have wanted the client first for consistency, a design system may have needed work before a theme was practical, the 110-file first pull request may have been too large to review, or the decisions may have been made in places this analysis cannot see. That is why Step 0 asks before it builds.

Step 0: validate before building

The newest facts change the right first move. A pull request is already in active review, so the product questions are about evidence, quality, and communication, not about whether to start.

Measure the current dark theme. Run an automated contrast audit on the key screens and review the failures by hand. If normal text falls below 4.5:1, that is an accessibility defect in its own right and can be fixed without waiting for a new theme.
Find out what stands between #658 and a merge. Read its review discussion and ask the reviewers: design sign-off, tests, visual regressions, or sheer size (176 files)? Also ask why #461 was closed, so the next contributor learns from it.
Publish a decision on the issue. Scope, owner, target release, and what happens to the open pull requests. Replace needs-triage. Even “not in the next release, because …” beats silence.
Stop the control from over-promising. If the release is not imminent, hide the disabled Light and System options or label them “not available yet”.

If the audit finds failures

Ship the contrast fix first (R2) as a small, separate change. It helps every current user.

If #658 is close to merging

Spend the effort on verification and communication (R2, R3, R5), not on a rewrite.

If it is not close

Choose between the options below, and say which one in the issue.

Problem framing and hypotheses

Three separable problems are tangled together in one thread. Separating them lets the team fix the cheapest real one first.

Preference

Some people simply see better and work more comfortably on light backgrounds, and want to choose.

Readability

The dark theme may be below accepted contrast levels. That would be a defect, not a preference.

Process

Who decides, by when, and where can the people who asked see the answer?

Hypotheses (unverified, from the outside)

H1The current dark theme has text below the accepted contrast level in places
How to test: Run an automated contrast audit on the key screens (peers, networks, access control, settings) and review failures by hand. Measure; do not rely on anyone’s impression, including the reporter’s.
H2What blocked the community pull requests was review and design sign-off capacity, not demand or code quality
How to test: Read the review discussion on #658 and ask the reviewers what stands between it and a merge: design sign-off, test coverage, visual regressions, or the size of the change (176 files).
H3A visible decision, even “not now, because X”, would have prevented much of the repeated upvote and news-request traffic
How to test: After a decision is posted, count new comments of that kind over the following months, and compare with the rate before.

Options

Effort is unknown and needs engineering input. The size of the open pull request (176 files) only shows that a theme touches much of the interface.

ALight theme onlyPartial
Meets the explicit ask. It leaves the visible System option broken, and the larger problem of a missing decision untouched.
BLight, Dark, and System (follow the device)Recommended target
Matches what the existing control already shows, and respects accessibility settings people have already made on their devices. The extra cost over A is modest if the theme is built on shared design tokens (an assumption to check).
CFix dark-theme contrast firstDo first if the audit fails
If H1 is confirmed, this is an accessibility defect that stands on its own. It is smaller than a new theme, helps every user of the dark theme, and gives a quick, honest win while the larger work proceeds.
DDecline publicly, with reasonsLegitimate, but costly here
A clear “no” is a valid product decision if the cost is too high. With 29 reactions, an accessibility angle, and a pull request in active review, it would need a strong reason, and the disabled options would have to go.
EAdopt pull request #658 as the base, or rewriteDepends on Step 0
An active review (19 inline comments) is a sign it is moving. At 176 files the review burden is real, so the decision turns on what reviewers say is still missing, not on a preference for either path.

Recommendation: run Step 0 now. If the audit fails, ship C immediately. Target B, using #658 as the base if its reviewers say it is sound. Whatever the outcome, do R5 this week: it costs one comment and removes the main source of repeated noise.

Proposed requirements

Written as user-visible outcomes, not implementation. Priorities use MoSCoW and assume the work goes ahead.

R1Must
The theme control offers Light, Dark, and System. The choice is remembered in the browser, and System follows the device and updates when the device setting changes.
Why: Delivers what the visible control already promises and respects people’s system-level accessibility settings.
Verified by: Each option works; the choice survives a reload; changing the device theme while System is selected changes the dashboard without a reload.
R2Must
In both themes, text and meaningful interface parts meet WCAG 2.2 AA contrast: 4.5:1 for normal text, 3:1 for large text and interface components.
Why: The reporter’s need is readability. A light theme that fails contrast would repeat the problem in a different color.
Verified by: An automated audit reports no contrast failures on the key screens in either theme, backed by a manual review of states the audit cannot reach (hover, focus, disabled).
R3Must
The page never flashes the wrong theme while loading, including after a reload and on a first visit with System selected.
Why: A white flash before a dark page is the most visible defect a theme feature can have.
Verified by: Record page loads in both themes and confirm that the first painted frame already uses the chosen theme.
R4Should
Embedded components (charts, code blocks, the integrated SSH terminal) follow the theme, or any exception is documented.
Why: Third-party components are where a theme most often leaks through.
Verified by: A checklist of every embedded component, with a screenshot in each theme.
R5Must
The issue receives a visible decision: scope, owner, target release, the status of the open pull requests, and an updated label.
Why: After 25 months without one, the cost to trust and to triage is already larger than the cost of saying “not now”.
Verified by: A maintainer comment exists that answers the questions asked in the thread, and the needs-triage label is replaced.
R6Should
Until the feature ships, the theme control never shows options that do nothing. Hide them, or label them “not available yet” with a link to progress.
Why: A dead control invites the same question again and again.
Verified by: No visible control is both enabled-looking and inert.
R7Should
The default for existing users is an explicit decision, not a side effect. Proposal: keep today’s default, ship System as opt-in, and revisit the default after feedback.
Why: Changing what thousands of existing users see on first load, without warning, is a product change in its own right.
Verified by: The release notes state what the default is and how to change it.
R8Could
Follow-ups for the readability motive beyond color: adjustable text size or density, and a higher-contrast variant.
Why: Several commenters describe vision needs that a color theme alone may not meet.
Verified by: Defer until the audit in R2 shows what is still hard to read.

Non-goals

Custom brand themes or per-user color pickers.
Redesigning layouts or navigation as part of a theme change.
Shipping anything from this prototype into NetBird. It is a portfolio concept only.

Concept mocks

Two small interactive pieces. Both are concepts: neither is NetBird's interface.

The theme control, three versions

Choose a version to preview

1. As reported

2. Interim: say so

3. Proposed

Concept mock · not the real dashboardAs reported

Theme

Light

Dark

System

Peers

Preview of an illustrative screen in the dark theme

build-runner-01Connected
db-serverConnected
laptop-anaOffline

Add peer

Design rationale

The reporter describes a theme control in the top right where Light and System are visible but disabled, with nothing explaining why.
A control that shows options which do nothing promises something it does not deliver. It invites exactly the “is this coming?” comments seen in the thread.
This is drawn from the issue text. It is not a recording of the real dashboard.

Turning “hard to read” into a number

R2 needs an acceptance criterion that two people cannot argue about. Contrast ratio is one. Move the sliders to see where gray text on a near-black background stops being enough.

Text gray level#767676

Background gray level#121212

Contrast ratio

4.12:1

Normal text (needs 4.5:1)Fails
Large text and UI parts (needs 3:1)Passes

WCAG 2.2 success criterion 1.4.3 (Contrast, Minimum). Large text means 24px, or 18.66px and bold, and up. These grays are illustrative; NetBird’s real dashboard colors were not measured.

What the triage board said, and what it cannot see

The triage board scored this issue from its title, description, comment count, and recency. Comparing that with the evidence above shows where an automatic score is useful and where it is blind.

The board’s suggested draft scores

impact: 4
urgency: 3
effort: 3

Starts at 2 (unknown).
+1: 22 public comments (an engagement proxy, not measured user impact).
+1: 15 or more comments suggests many people are affected.
Starts at 2 (unknown).
+1: still active (updated within 30 days).

Suggestions are planning inputs, not facts. Effort is never inferred.

What the score cannot see

The 29 reactions. It counts comments, not reactions.
That two pull requests exist, and what state they are in.
That no team member has replied, unless someone loads the discussion.
That the request has an accessibility angle, which may make it a defect rather than a preference.
That the decision, not the demand, is what is overdue.

Judgment: the board’s medium priority understates it. What deserves urgency is not the build, which is already in review, but the missing decision (R5) and the possible readability defect (R2). No number is put on effort here: the remaining work is review and verification, and only the people doing it can estimate that. Open this issue on the triage board to adjust its scores and draft its ticket.

Success metrics, risks, open questions

Proposed metrics

No baselines exist yet; each needs one before it can be a target.

Time from a request to a visible decision (here: not yet, after 25 months).
Contrast failures on the key screens, in each theme (target: none).
Share of people who choose Light or System, if usage data exists.
New upvote and “any news?” comments after the decision is posted.

Risks and trade-offs

Visual regressions across a very large surface.
Two themes to test and maintain from now on.
Embedded components that ignore the theme.
Reviewing a very large change well, versus shipping it fast.
Contributor goodwill: closing a large pull request without explanation discourages the next one.

Open questions

Does the dark theme meet AA contrast today?
Why was #461 closed, and what blocks #658?
Does the project have usage data to size demand?
Should System become the default eventually?
Do the client and the dashboard share design tokens?

See also: Case study 1: silent SSO session expiry, a bug report whose evidence is thin and whose first step is to find out whether it still happens.

A light theme request open for two years: when demand is clear and the decision is not

A worked example of turning a long-running feature request (netbirdio/dashboard#412) into a decision, requirements, and a UX concept. Where the first case study was about a bug whose existence was in doubt, this one is about a need nobody doubts and a decision nobody can see.