On to Priority of constituencies
We were having a discussion about how browser developers should seek feedback from Web developers about the evolution of Web technology and the specifications that define it. I suggested the following list of things that browser developers should do, and Anne thought it was worth blogging:
Find out what are the most important problems that Web developers have.
(Also, in addition to "most important", it's also worth noticing "most bang for buck", to also catch not-so-important problems with really easy fixes.)
Tell developers about areas where we're working on solutions to the problems they've told us about, and solicit feedback (on whether it's still an important problem, on whether the solution actually solves the problem, on how the solution could be improved, and perhaps even on which parts of the solution are important).
Tell / teach developers about the places where we've shipped solutions to the problems they've told us about, to encourage those solutions to be used. (And, when doing this, keep soliciting feedback about additive improvements.)
Specifications are in some sense secondary to problems. A solution should be specified, but there might not be a one-to-one mapping between solutions and specifications. A solution might be part of one specification, or might be spread across multiple specifications.