So, you don't like a web platform proposal

Jul 20 2023

Has this ever happened to you?

You wake up one morning, scrolling the feeds while sipping your coffee, when all of the sudden you land on a post related to a web platform proposal that you really don't like. Worse, one that you believe would have significant negative consequences on the web if shipped?

At that point, you may feel that your insights and experience can be valuable to help steer the platform from making what you're sure is a huge mistake. That's great!! Getting involved in web platform discussions is essential to ensure it's built for and by everyone.

At the same time, there are some pitfalls you may want to avoid when engaging in those discussions.

Given that the above has certainly happened to me, here are some lessons I learned in my years working on the web platform, both before and after I was employed by a browser vendor.

# Things to bear in mind

# Don't assume consensus nor finished state

Often a proposal is just that - someone trying to solve a problem by proposing technical means to address it. Having a proposal sent out to public forums doesn't necessarily imply that the sender's employer is determined on pushing that proposal as is.

It also doesn't mean that the proposal is "done" and the proposal authors won't appreciate constructive suggestions for improvement. Different proposals may be in different stages of their development, and early stage proposals are often extremely malleable.

All that means is that with the right kind of feedback at the right time you can raise concerns early, and significantly increase the chance they would be properly addressed and mitigated.

# Don't assume a hidden agenda

When thinking about a new proposal, it's often safe to assume that Occam's razor is applicable and the reason it is being proposed is that the team proposing it is trying to tackle the use cases the proposal handles. While the full set of organizational motivations behind supporting certain use cases may not always public (e.g. a new device type not yet announced, legal obligations, etc), the use cases themselves should give a clear enough picture of what is being solved.

# Avoid legal language

The fastest way to get someone working for a large corporation to disengage from a discussion is by using legal or quasi-legal language. Such language will prevent them from replying to your claims without talking to their corporate legal counsel, which will probably mean they will not reply to your claims. If you want to have a productive exchange with the folks making the proposal, it's best to not pretend you're a lawyer. (and if you are one, may be best to pretend you're not)

# We're all humans

Every one working on the web platform is a human being, with human feelings, who's trying to do their job. Even if you disagree with their choice of employment, their technical decisions or their conclusions, that doesn't change that fact.

To be more concrete and clear, personal attacks or threats addressed at the folks working on the platform are not OK. That's not how you get your voice heard, that's how you get yourself banned!

# What should I do then?

# Be the signal, not the noise

In cases where controversial browser proposals (or lack of adoption for features folks want, which is a related, but different, subject), it's not uncommon to see issues with dozens or even hundreds of comments from presumably well-intentioned folks, trying to influence the team working on the feature to change their minds.

In the many years I've been working on the web platform, I've yet to see this work. Not even once.

On the receiving end, this creates a deluge of emails that's very hard to sort out. While some of those may be full of technical insights, it's very hard to find them in that pile and distinguish them from the other forms of commentary. So while it may feel good to join a good old-fashioned internet pile-up, it's very unlikely to lead to the outcomes you actually want.

You should instead try to provide meaningful technical feedback (more on that in the next section), and do that in places where that signal is less likely to drown in the noise.

# Provide technical arguments

There are a few things you want to focus on when debating technical proposals.

# Use cases

The use cases the proposal tackles are typically the core of the problem the team pushing the proposal is trying to solve. Everything else flows from that. Focusing on use cases would enable you to distill the essence of the proposal, and potentially propose alternatives that still address them without the bits you find harmful or risky.

In some cases, you may consider the use cases themselves to be ones you think shouldn't be supported on the web. If that's the case, if I'm being honest, you're up for an uphill battle. But you can still make your case by building a solid argument as to why these use cases shouldn't be supported on the web, while considering the different trade-offs that support for them or lack-thereof would entail. At the very least, that would help you establish a common language with the feature's proponents and have a frank discussion regarding the trade-offs.

In other cases, adjacent use cases you may care about are not covered by the proposal. Raising issues on that front can help expand the proposal to cover those use cases or at the very least ensure that it can be expanded in the future.

# Risks

If the proposal contains risks in terms of compatibility, interoperability, or any other risks to the open and safe nature of the web platform, that's something worthwhile pointing out.

Any such risks need to be addressed by the proposal and properly mitigated before that feature is shipped. That doesn't mean that any claim for risks would be taken at face value, but if your arguments about the risk are sound, you can expect the proposal owners to respond to them.

# Considered alternatives

Another area to focus on is what an alternative proposal that addresses the use cases may look like. In many cases, such alternatives are already outlined in the proposal's explainer, with their trade-offs spelled out. But it's also possible that some reasonable alternative was not considered, and could be an improvement on the current proposal. If such an alternative comes to mind, that could be good feedback to the team working on the feature, so that they can consider it and potentially change course.

# Use professional language and be kind

This should come without saying, but.. people are less likely to understand and internalize your constructive feedback when it's littered with distracting and unprofessional language.

Beyond that, you should remember that on the other end of the keyboard there are humans that are trying to do their job to the best that they can. They are most likely stressed out about engaging publicly regarding their project and how it'd be received. Even if you disagree with them or even the premise of their work, providing your feedback with kindness and empathy has literally no downsides. You can deliver the exact same message without the sarcasm.

# So, get (constructively) involved!

Obviously, the above doesn't guarantee that the next point of feedback you provide on a proposal would be accepted and integrated. But at the same time, I think these guidelines can increase your chances of being heard and impacting the outcome of the discussions you're involved in. And after all, that's the point of getting involved, right?

← Home