One of the problems TC39 has is soliticiting feedback on new features. Not all developers are aware of our process, and those who participate are self-selecting. The JavaScript developer population is large. We also have a lot of features in the pipeline which are not being validated in a rigourous way.
The goal of this feature is to explore how to make the feedback cycle seamless, and how to make the data that we get back from it reflect the reality of JavaScript programmers. We need mechanisms for identifying characteristics of users and their usecases (see "who are javascript developers") and we need to be able to ask them questions about features that may be of interest to them. How do we do that?
Ideas so far have been to integrate a super lightweight survey mechanism into VSCode or github, and a system for search and replace of the ast to show the programmers in-line how their code will change. But other ideas are welcome here too.
codehag
commented
1 month ago
One of the problems TC39 has is soliticiting feedback on new features. Not all developers are aware of our process, and those who participate are self-selecting. The JavaScript developer population is large. We also have a lot of features in the pipeline which are not being validated in a rigourous way.
The goal of this feature is to explore how to make the feedback cycle seamless, and how to make the data that we get back from it reflect the reality of JavaScript programmers. We need mechanisms for identifying characteristics of users and their usecases (see "who are javascript developers") and we need to be able to ask them questions about features that may be of interest to them. How do we do that?
Ideas so far have been to integrate a super lightweight survey mechanism into VSCode or github, and a system for search and replace of the ast to show the programmers in-line how their code will change. But other ideas are welcome here too.