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

Consider adding publishers into the Priority of Constituencies #535

Open
jyasskin opened this issue Dec 6, 2024 · 3 comments
Open

Consider adding publishers into the Priority of Constituencies #535

jyasskin opened this issue Dec 6, 2024 · 3 comments

Comments

@jyasskin
Copy link
Contributor

jyasskin commented Dec 6, 2024

https://w3ctag.github.io/design-principles/#priority-of-constituencies says

User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.

The draft Vision says

We put the needs of users first: above authors, publishers, implementers, paying W3C Members, or theoretical purity.

That is, it adds "publishers". (It also adds W3C Members and removes spec writers, but I think there's a good reason to let those diverge between the W3C-level Vision and the Web-level Design Principles.)

In w3c/AB-public#216 (comment), @cwilso says this change was well-considered within the AB, and if there's a good reason to make it, we should make the same change in the Design Principles.

I'm sympathetic to splitting the authors (often individuals) from the publishers (often corporations), and I'd lean toward putting publishers between authors and implementers. @cwilso, can you elaborate on the AB's reasons for adding publishers?

@martinthomson
Copy link
Contributor

Personally, I'd prefer it if we lump publishers in with authors, as we have implicitly done so for many years.

(On the tangential note, I wonder if "paying W3C Members" is a substitution for "specification writers", rather than the big change it seems to be. I think that it's a bad change and would prefer not to see this sort of restatement of the principle at all. That has little bearing on what we might do in the design principles though, unless we accept that substitution as a good idea.)

@cwilso
Copy link

cwilso commented Dec 9, 2024

"paying W3C members" is absolutely not a substitution for specification writers. It was intended to capture for the purposes of the Vision that Members cannot override the needs of users, just because they're Members. The DP point about spec writers seems intent on "spec writers are not the ultimate authority, and also we shouldn't support things simply because it's convenient to write down".

To be clear, I don't think the "paying W3C members" point is relevant for the design principles; likewise, I don't think the spec writers point is particularly relevant in the vision.

As to publishers: this was intended to point out that the publication and delivery of content at scale tends to not be the same task at all as authoring; me writing a web page in visual studio is a very different aspect than "how does Medium deploy world-wide", let alone "how does MSN put together an article page".

@annevk
Copy link
Member

annevk commented Dec 10, 2024

I think the Vision document seems to miss a crucial aspect of the design principle. Namely that it's ordered. In the Vision document, it reads to me that implementers are on equal footing with authors, theoretical purity, and paying W3C Members (due to the usage of "or" and removal of the language that indicates the hierarchy).

It seems this point is missed above as well, as the principle actually stresses how unimportant specification editors are. Their needs are only just above theoretical purity. A far cry from an ultimate authority.

And given that it's supposed to be ordered, I don't see how distinguishing publishers helps. You can't put their needs above authors and their needs are already above implementers. So what is gained?

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

4 participants