You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 2, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 2, 2023. It is now read-only.
Surveys: Members formally taking ownership (leadership) is the next step #209
I few months back I tried to revive @MylesBorins idea from #85 hoping to hit a good target by this past summit. Not hitting the goal was not an issue in itself, it was a very optimistic goal which I aimed for to try to pick up momentum on this important outreach venue within our patient and (imho) very eager to be heard community.
The questions are not the issue, we all know what people might be interested in expressing, and it is the requirement of a consumer survey (ie our community at large) to afford every user the opportunity to know that priorities that are important to everyone (based on numbers) are important to this group's end game. My sole intent was to bring forward some process and drive interest within the group so that a few champions would take collective ownership of different sections and maybe produce a single targeted form (with optional sections based on interest indicated).
I hope that my efforts can now be leveraged by everyone in the group to begin the actual efforts after this warm up phase.
If people want to take leadership roles, we can deliver a survey, until then, the current efforts will need to be suspended.
My recommendation is to use Google Forms hand-in-hand with dedicated meetings. Even with the learning curve and lack of versioning, it may be the most superior option available. This and other insights is something I am very willing to talk about and assist anyone with. My input is simply as recommendations, but it is up to those who want to take leadership to determine how together, and what role they would like me to take to move forward.
Your previous feedback has been captured in this sheet
Proposed leadership breakdown:
General
Scope (the results of this survey will … as a group)
Purpose (the objective of this survey … from the community)
Tooling (for editorial and distribution)
Content
Overall Flow & Presentation
Wording (harmonized terminology)
Representation (what you need answered + what they want asked)
This is important for members who maintain tools used by the community and need to determine migration path
Technical
Node.js
Modules
Workflows
Back-end
Front-end
If we ask and deliver, or justify accordingly because we asked, is not the same as asking but avoid to specifically ask, is not the same as not asking at all, where one's efforts to justify is at best an excuse that does not satisfy.
@MylesBorins please feel free to close this thread at your discretion. Thank you so much for bring up the idea initially and thanks to everyone involved in this effort so far. Please don't hesitate to involve myself and others that are visibly active on threads labelled "survey" should there be future relating efforts.
We’ve been discussing surveys in the smaller groups tasked with working on the Phase 2 proposals. For now I’ve been taking the approach of research into “in the wild” ESM packages as a substitute for a survey, looking at things like what package.json field people use, etc. (See analysis here.) Survey data would be a welcome complement to this, though, but it needs to cut straight to the controversial issues: would it be an issue for people to use .mjs? How often do people import CommonJS files that aren’t in a package? And so on. Just as NPM package data can help break impasses by providing real-world data about actual user behavior, survey data can do the same by providing data of real user preferences. I feel like most, if not all, of our big use cases will be handled by the final implementation, so the question will come down to what the defaults should be: should importing .js files into ESM be parsed as CommonJS by default or parsed as ESM by default? And so on. Survey data can help decide those questions.
I think once we get all the Phase 2 proposals debated and perhaps even implemented, that would be a great time to revisit using surveys to help settle open questions we may still have about how an implementation should behave or what default behaviors should be.
@GeoffreyBooth I am always happy to make myself available and work on survey questions that people feel they need addressed. Please let me know when, what, and how to move forward on those aspects.
Activity
SMotaal commentedon Nov 8, 2018
@MylesBorins please feel free to close this thread at your discretion. Thank you so much for bring up the idea initially and thanks to everyone involved in this effort so far. Please don't hesitate to involve myself and others that are visibly active on threads labelled "survey" should there be future relating efforts.
MylesBorins commentedon Nov 21, 2018
@SMotaal as there have been no responses are you open to removing from the agenda?
GeoffreyBooth commentedon Nov 21, 2018
We’ve been discussing surveys in the smaller groups tasked with working on the Phase 2 proposals. For now I’ve been taking the approach of research into “in the wild” ESM packages as a substitute for a survey, looking at things like what
package.jsonfield people use, etc. (See analysis here.) Survey data would be a welcome complement to this, though, but it needs to cut straight to the controversial issues: would it be an issue for people to use.mjs? How often do people import CommonJS files that aren’t in a package? And so on. Just as NPM package data can help break impasses by providing real-world data about actual user behavior, survey data can do the same by providing data of real user preferences. I feel like most, if not all, of our big use cases will be handled by the final implementation, so the question will come down to what the defaults should be: should importing.jsfiles into ESM be parsed as CommonJS by default or parsed as ESM by default? And so on. Survey data can help decide those questions.I think once we get all the Phase 2 proposals debated and perhaps even implemented, that would be a great time to revisit using surveys to help settle open questions we may still have about how an implementation should behave or what default behaviors should be.
SMotaal commentedon Nov 21, 2018
Oh... Sorry, I missed this one 👼
SMotaal commentedon Nov 22, 2018
@GeoffreyBooth I am always happy to make myself available and work on survey questions that people feel they need addressed. Please let me know when, what, and how to move forward on those aspects.
SMotaal commentedon Nov 30, 2018
@GeoffreyBooth can we close this and maybe open a new issue once the questions are ready?
GeoffreyBooth commentedon Nov 30, 2018
Sure.