Slowness in approving PRs

[melvincarvalho]

Following up from #93:

At least 3 approving reviews are required to merge this pull request.

It looks like we haven’t had a single approving review in over 6 months on this relatively simple term, and we need 3 approvals to proceed. But it doesn’t say who those reviewers are.

Would it make sense to explore a shared or community-maintained alternative for developers who want to move quickly with Solid vocabularies? I’d like to build a wallet, but I’m currently blocked.

If there’s interest, and we can agree on what to call it, I’d be happy to help spin something up.

[uvdsl]

If you just want to define new terms, e.g. to create something quickly, you can always do it yourself and host the vocabulary on the Web. No issue in that.

However, I'd like to point out that defining a term by yourself for yourself (and potentially for others to re-use later) is one thing, while creating a shared conceptualization of a common domain of interest -- i.e. finding consensus in what the terms mean -- is another:
The Solid vocabulary is more than just a list of terms that you can re-use in your app. For these terms, people from the community have agreed on what concepts the single terms refer to. Requiring multiple reviews before modifying the Solid vocabulary reflects that process of finding consensus / a common understanding.

#93 only shows the importance of this discussion in the community. We are not all on the same page what solid:Wallet actually refers to. Without a discussion, our understanding of the concepts will not align and people start using terms however they interpret them, giving rise to ambiguity and thereby hindering interoperability.

Again, I am not saying that you should not define new terms if you need them to create an application. I encourage you to not try to circumvent the fundamental discussion if you want to introduce these terms into a curated vocabulary that is used by a wider community.

[melvincarvalho]

The 3-approval rule doesn’t say who the approvers are. So things can get stuck indefinitely.

That’s not just slow, it’s structurally unhelpful. Makes it hard to build, and easy to block without accountability.

Builders need to build. And if terms can be stalled for half a year or more, app builders need a way to reach consensus and unblock, so devs can keep moving without getting trapped in bureaucracy.

While it's true that anyone can make a vocab, we need something project wide to unblock developers.

[melvincarvalho]

Just as another data point:

#57 — uses the quite sensible PublicDocument and PrivateDocument.

Been open six years!

If even simple, useful terms can’t land in that time, something’s not quite working. RDF only helps when shared meaning can actually spread.

Might be time to rethink how we unblock vocab work across the project.

[elf-pavlik]

I proposed this issue for next week CG meeting https://hackmd.io/@solid/cg-weekly#solidvocab-Slowness-in-approving-PRs-96

[uvdsl]

Re #57:

Why is it still open? Is it still open because there was no feedback or because the feedback was not incorporated? I see three reviews with suggested changes, and one specifically requesting consideration of suggested changes. Why were the suggested changes not incorporated or even discussed?

[melvincarvalho]

Thanks again @elf-pavlik for raising this in the last CG call — great to see the discussion surface.

That said, a few systemic concerns remain unresolved:

“At least 3 approving reviews are required…”

This requirement, while well-intentioned, lacks implementation detail. Specifically, there is no public list of who the approvers are. Without that, we're left with a process that is unbounded in time and undefined in accountability. In practice, this means useful terms can sit in PRs for months or even years without progress — not due to disagreement, but due to structural opacity.

To illustrate: #57 introduces reasonable terms like PublicDocument and PrivateDocument. It’s been open for six years. That’s not a reflection of the proposal’s quality, it’s a reflection of a broken pipeline.

We have to ask ourselves: what signal does this send to contributors and implementers? If a project lead can’t land well-scoped terms after six years, what chance does a new contributor have?

The ability to iterate on shared vocabularies is foundational to the Solid ecosystem. But if the process to do so is brittle, undocumented, or slow to the point of unresponsiveness, the ecosystem becomes uninviting to new developers and exhausting for existing ones.

Proposal: As we transition to ODI stewardship, we have an opportunity to re-evaluate and formalize the review process. Specifically:

• Define who the reviewers are.
• Set reasonable time bounds for merging (e.g., 30–45 days).
• Allow opt-in fast-track vocabularies for app developers that can later be proposed for elevation.

This isn’t about bypassing consensus — it’s about designing for throughput and trust. If we want shared meaning to emerge, we have to make participation viable.