Suggest that new proposals include a possible solution.

[jyasskin]

Based on a discussion at
https://twitter.com/sundress/status/1109585673357393920. @alice gets all the
credit.

Note that the "did it well" example around filesystem storage had the benefit of already having several possible solutions in the email thread.

[domenic]

I am -1 on this. I think the most valuable part of this documentation is getting people to not propose particular solutions, and instead focus on the problem space.

From Twitter, I gather folks have approached other standards venues and been asked for a solution, and that prompted this pull request. But I haven't heard of that happening here, and instead we deal a lot with the opposite problem. So I would rather we keep the current wording.

[alice]

Out of curiosity, what does the opposite problem look like?

[domenic]

I don't want to pick on specific examples, but just browsing through recent discourse.wicg.io threads, or things labeled "addition/proposal" on various WHATWG repositories, there are clear instances of people doing things like:

• Suggesting a new HTML element without stating what problem the element is solving
• Suggesting new ways of solving long-standing problems like credentials or passwords, instead of stating that they are concerned about those problems and giving us a chance to point them toward groups that are doing excellent work already in those areas.
• Suggesting features by analogy to features from other domains, without considering whether the new domain has the same problems to be solved as the old one
• Proposing replacements for HTML/JS/CSS without stating what's wrong with those languages that causes them to need replacing
• Suggesting solutions based on the author's expertise instead of based on the problem space. E.g. suggesting new HTML elements to solve styling concerns, or new CSS properties to solve scripting concerns. Hearing about the styling and scripting concerns would then allow a more productive dialogue, not focused on shooting down their HTML element/CSS property idea, but on building a CSS property/JS API together.

In general these kinds of setups creates a problematic start to the conversation, where first we need to invest energy trying to gently get the original poster to let go of their pre-conceived solutions, before we can productively work together on the problem space.

[alice]

Thanks for all the examples! Yeah, that sounds tiring.

I do think there's something to the idea that people naturally tend to go to solutions, and that problems are often illuminated by an idea for a solution. As Jeffrey pointed out, the linked example did come in the context of a proposed solution.

In AOM, similarly, we didn't get to our list of use cases until we'd already designed a solution that didn't end up working. It was only through the process of coming up with a design that the problems really took shape.

Is there a way that we can keep the emphasis on problems while not unrealistically expecting people not to generate ideas for solutions, or excluding the possibility that a proposed solution, while not the final design, might help frame the problem better?

[jyasskin]

Do you think https://discourse.wicg.io/t/proposal-allow-scrolling-to-a-specified-text-snippet-in-a-navigation/3442 is an example of a good problem statement? Is it made worse by the fact that it links to an example solution? (If you don't like it, what is an example of a good proposal?)

I think the prevalence of bad proposals indicates that the current text isn't succeeding at its job. I don't really expect more people to read or pay attention to the new text either. I do think people need to do a bit of work to ensure that it's possible to solve their problem (e.g. "I want a way to tell if this function halts" is a bad problem statement.), and the text I'm suggesting is more respectful to the output of that work.

[hober]

I think requiring people who raise problems to provide a possible solution would negatively affect the ability of many engineers at large companies to raise issues in the first place. Consider the IPR difference of "there is a problem here" and "here is an idea I had to solve this problem".

[jyasskin]

@hober The title of this issue doesn't exactly match the text I'm suggesting, and I think the text successfully avoids the problem of "requiring people who raise problems to provide a possible solution". If you disagree, is there other text that would better express that it's ok but not required to provide a possible solution or proof of concept?