├── .github └── ISSUE_TEMPLATE │ ├── 1-user-feedback-survey.md │ ├── 2-user-feedback-session.md │ └── 99-custom-issue.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── README.md ├── data └── 2018-02-benchmarking-wg-survey │ ├── 2017 Benchmarking Working Group Survey.xlsx │ ├── Perf_Bench_Survey_Supplemental.pdf │ ├── Perf_Benchmark_Survey_Summary_Report.pdf │ └── README.md ├── groups └── tooling │ └── README.md └── meetings ├── 2017-12-01.md ├── 2017-12-15.md ├── 2017-12-29.md ├── 2018-01-12.md ├── 2018-01-26.md ├── 2018-02-16.md ├── 2018-02-20.md ├── 2018-03-02.md ├── 2018-03-16.md ├── 2018-03-30.md ├── 2018-04-13.md ├── 2018-04-27.md ├── 2018-05-11.md ├── 2018-05-25.md ├── 2018-06-08.md ├── 2018-06-22.md ├── 2018-07-06.md ├── 2018-07-30.md ├── 2018-08-16.md ├── 2018-09-14.md ├── 2018-10-26.md ├── 2018-11-09.md ├── 2018-12-07.md ├── 2019-01-18.md ├── 2019-02-01.md ├── 2019-03-01.md ├── 2019-03-15.md ├── 2019-03-29.md └── 2019-04-25.md /.github/ISSUE_TEMPLATE/1-user-feedback-survey.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "\U0001F64B User-Feedback Survey" 3 | about: Want to initiate a user-feedback survey on a specific topic? Great! Use this issue template to gather all necessary details to get the ball rolling. 4 | --- 5 | 6 | 12 | 13 | **Survey title** 14 | ${topic} survey (ex. Migration challenges survey) 15 | 16 | **Survey owner(s)** 17 | Who will be responsible for details and ensuring questions are adequately formed 18 | 19 | **Survey timeframe** 20 | Ideally, how soon should this be completed (typically x months) and please provide any relevant context 21 | 22 | **Survey goals summary** 23 | What would you like to achieve in gathering these survey responses (ex. finding pain points in migration path to better serve community in future updates) 24 | 25 | **Survey questions** 26 | This may be best captured in a google doc or Pull request 27 | 28 | **Survey development google doc link** 29 | (if applicable) 30 | 31 | **Survey pull request** 32 | (adding directory and necessary documents) 33 | 34 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/2-user-feedback-session.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "\U0001F3E2 User-Feedback Session" 3 | about: Want to run a user-feedback session on a specific topic at your meetup or event? Great! Use this issue template to gather all necessary details to get the ball rolling. 4 | --- 5 | 6 | 17 | 18 | 19 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/99-custom-issue.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "\U0001F47E All other issues" 3 | about: If your issue doesn't fit the other templates, please open a custom issue 4 | --- 5 | 6 | 11 | 12 | 13 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | Code of Conduct 2 | 3 | The Community Committee and its initiatives are committed to upholding the Node.js Code of Conduct. 4 | 5 | The Node.js Code of Conduct document can be found at 6 | https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md 7 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | This is an adapted version from Contributing.md file used by Community-Committee https://github.com/nodejs/community-committee/blob/master/CONTRIBUTING.md 2 | 3 | ## Vocabulary 4 | 5 | * A **Contributor** is any individual gathering data, performing outreach, feedback collection, organizing meetings, organizing events, taking notes or providing written feedback. As much as possible, we try to capture attribution of these actions with an [issue](https://github.com/nodejs/user-feedback/issues) or a [pull request](https://github.com/nodejs/user-feedback/pulls). 6 | * A **Collaborator** is a **_Contributor_** who has been given write access to the repository. 7 | * A **Member** is a **_Collaborator_** with voting rights who has met the requirements of participation to be considered for acceptance, and subsequently voted in using the Node.js CommComm voting process. 8 | 9 | -You may start to take a look at any issues (https://github.com/nodejs/user-feedback/issues). 10 | 11 | # Contributions 12 | 13 | Any change to resources in this repository must be through pull requests. This applies to all changes 14 | to documentation, code, binary files, etc. 15 | No pull request can be merged without being reviewed. 16 | 17 | The default for each contribution is that it is accepted once no collaborator has an objection. 18 | During review collaborators may also request that a specific contributor who is most versed in a 19 | particular area gives a "LGTM" before the PR can be merged. There is no additional "sign off" 20 | process for contributions to land. Once all issues brought by collaborators are addressed it can 21 | be landed by any collaborator. 22 | 23 | In the case of an objection being raised in a pull request by another collaborator, all involved 24 | collaborators should seek to arrive at a consensus by way of addressing concerns being expressed 25 | by discussion, compromise on the proposed change, or withdrawal of the proposed change. 26 | 27 | # Becoming a Member and Collaborator 28 | 29 | We are still working to better define the ladder to becoming a full member. The work of User Feedback is primarily non-technical in nature. Given the norms of the Node.js project we still attribute that work through GitHub issues and pull requests. 30 | 31 | We would love your contribution and will help you become a collaborator and member. 32 | Start by joining our bi-weekly meetings. Please [post an issue](https://github.com/nodejs/user-feedback/issues) introducing yourself. 33 | 34 | After attending 3 Node.js End User Feedback (NEUF) meetings and contributing to the teams efforts, you will be recognized as as **Contributor**. 35 | 36 | After 3 months in good standing as a **Contributor**, you will be eligible to become a **Collaborator**. 37 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Node.js End User Feedback Initiative 2 | 3 | We are in the formative steps of building out infrastructure, process and collaborators to bring large-scale feedback to the Node.js project under the charter of the [Node.js Community Committee (CommComm)](https://github.com/nodejs/community-committee). Thank you for your interest and support. We are actively looking for new members. Please [create an issue](https://github.com/nodejs/user-feedback/issues) in this repo if you are interested in dedicating 5+ hours a month to during the formation process. We expect the formation process to run through Q2 2018. The primary skillset for this initiative is largely non-technical: social sciences, product and project management and organizational. 4 | 5 | ## What does the Node.js End User Feedback team do? 6 | The Node.js End User Feedback team works with Node.js end users to provide a bi-directional feedback channel for the Node.js project through surveys, meetings and outreach. 7 | 8 | ### Projects 9 | * In-person and online end user feedback sessions. [We want to hear from you!](https://github.com/nodejs/user-feedback#end-user-feedback---looking-for-participants) 10 | * Support the annual Node.js User Survey launched every year at Node.js Interactive (usually in October) by the Node.js Foundation. We provide input on questions and intend to publish copies of the data for analysis. 11 | * Support [CommComm](https://github.com/nodejs/community-committee) and [TSC](https://github.com/nodejs/TSC) end user feedback and outreach needs. 12 | - We are currently preparing the [2017 Benchmarking WG Survey](https://github.com/nodejs/user-feedback/issues/22) for the [Benchmarking WG](https://github.com/nodejs/benchmarking). 13 | * Manage the [Enterprise Advisory Group](https://github.com/nodejs/user-feedback/issues/18) to the TSC. 14 | 15 | ### Governance and Contributing 16 | The Node.js End User Feedback team has adopted the core governance and contribution policies of the Node.js project. 17 | 18 | The Node.js End User Feedback team is chartered under the [Node.js Community Committee (CommComm)](https://github.com/nodejs/community-committee) and follows [CommComm Governance policy](https://github.com/nodejs/community-committee/blob/master/GOVERNANCE.md). 19 | 20 | #### Contributing Guide 21 | 22 | [CONTRIBUTING.md](./CONTRIBUTING.md) 23 | 24 | We are actively seeking technical and non-technical contributors to help gather Node.js End User Feedback. Contributions are rewarded with attribution. Our [Contribution Guide](./CONTRIBUTING.md) details the steps to becoming a Contributor, Collaborator and Member of the Node.js End User Feedback (NEUF) team. 25 | 26 | ### Node.js End User Feedback Team Members 27 | 28 | * [ahmadnassri](https://github.com/ahmadnassri) - **Ahmad Nassri** <ahmad@ahmadnassri.com> - [Enterprise User Focus Lead](https://github.com/nodejs/user-feedback/issues?q=label%3Auser-feedback-enterprise) 29 | * [boneskull](https://github.com/boneskull) - **Christopher Hiller** - <boneskull@boneskull.com> - [Tooling User Focus Lead](https://github.com/nodejs/user-feedback/issues?q=label%3Auser-feedback-tooling) 30 | * [bnb](https://github.com/bnb) - **Tierney Cyren** <hello@bnb.im> 31 | * [codeekage](https://github.com/codeekage) - **Abraham Jr. Agiri** <agiriabrahamjunior@nodejs.africa 32 | * [dshaw](https://github.com/dshaw) - **Dan Shaw** <dshaw@dshaw.com> 33 | * [joesepi](https://github.com/joesepi) - **Joe Sepi** <joesepi@gmail.com> 34 | * [hackygolucky](https://github.com/hackygolucky) - **Tracy Hinds** <tracyhinds@gmail.com> - Advisor 35 | * [mhdawson](https://github.com/mhdawson) - **Michael Dawson** <michael_dawson@ca.ibm.com> - Community Committee Liaison 36 | * [mihaiep](https://github.com/mihaiep) - **Mihai Ene-Pietrosanu** <mihai.enepietrosanu@gmail.com> - Project Manager and Scribe 37 | * [mikehostetler](https://github.com/mikehostetler) - **Mike Hostetler** - <mike.hostetler@gmail.com> 38 | * [williamkapke](https://github.com/williamkapke) - **William Kapke** <will@kap.co> 39 | 40 | 41 | 42 | ### Archives 43 | * [Meeting recordings on YouTube](https://www.youtube.com/playlist?list=PLfMzBWSH11xY08hahRrbpvccelFSa6rUQ) 44 | * [Meeting Index](https://github.com/nodejs/user-feedback/tree/master/meetings) 45 | 46 | ## End User Feedback - Looking for Participants :tada: 47 | 48 | The Node.js end user feedback team (NEUF) will be working to gather feedback from end users through a number of different channels. 49 | 50 | One of those channels will be live discussion either in person or on-line. We are starting to put together a list of businesses who: 51 | 52 | * are using Node.js for their production systems 53 | * use Node.js as part of their tooling 54 | * are evaluating Node.js as a potential technology 55 | * have recently chosen Node.js and are just getting started 56 | * would like to use Node.js but face obstacles in being able to do so 57 | 58 | If you would like to get involved and participate regularly (currently thinking is every 2 months or quarterly) 59 | please email user-feedback@nodejs.org. 60 | 61 | ## Current User Feedback Initiative timeline 62 | 63 | * 2/22 - User feedback session blog posts complete 64 | * 2/22 - Have 6-8 meetups confirmed to do the session 65 | * 3/10 - Reach out to meetups to make sure things are scheduled and have guidelines 66 | * 3/25 - Publishing enterprise user group and put it in a .md 67 | * 3/25 - Get the blog post or guidelines up on a .md file 68 | * 4/10 - Reach back out to meetups to make sure they are prepared 69 | * 4/25 - Meeting enterprise user group 70 | * 5/15 - We have done user feedback session 71 | * 6/15 - Conduct feedback and update the user feedback updates & measure results of what we were able to get again 72 | * 7/15 - Out of “beta” 73 | * 8/15 - Adding the user feedback to “get involved” 74 | 75 | ## Additional Context 76 | 77 | The organization and formation of this initiative was kicked off by [hackygolucky](https://github.com/hackygolucky), [mhdawson](https://github.com/mhdawson) and [bnb](https://github.com/bnb). We are grateful for their leadership. 78 | 79 | * [#community-committee/96](https://github.com/nodejs/community-committee/issues/96) Node.js User Feedback initiative 80 | * [#community-committee/112](https://github.com/nodejs/community-committee/issues/112) Node.js User Feedback project planning 81 | * [#community-committee/162](https://github.com/nodejs/community-committee/issues/162) User Feedback Project group formation 82 | -------------------------------------------------------------------------------- /data/2018-02-benchmarking-wg-survey/2017 Benchmarking Working Group Survey.xlsx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nodejs/user-feedback/0fb8bf1780c555efe346c92d9f0027448f5b08cb/data/2018-02-benchmarking-wg-survey/2017 Benchmarking Working Group Survey.xlsx -------------------------------------------------------------------------------- /data/2018-02-benchmarking-wg-survey/Perf_Bench_Survey_Supplemental.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nodejs/user-feedback/0fb8bf1780c555efe346c92d9f0027448f5b08cb/data/2018-02-benchmarking-wg-survey/Perf_Bench_Survey_Supplemental.pdf -------------------------------------------------------------------------------- /data/2018-02-benchmarking-wg-survey/Perf_Benchmark_Survey_Summary_Report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nodejs/user-feedback/0fb8bf1780c555efe346c92d9f0027448f5b08cb/data/2018-02-benchmarking-wg-survey/Perf_Benchmark_Survey_Summary_Report.pdf -------------------------------------------------------------------------------- /data/2018-02-benchmarking-wg-survey/README.md: -------------------------------------------------------------------------------- 1 | 2017 Benchmarking WG Survey 2 | -------------------------------------------------------------------------------- /groups/tooling/README.md: -------------------------------------------------------------------------------- 1 | # Tooling Group Initiatives 2 | 3 | > This "living document" outlines the initiatives that have come out of User Feedback Sessions for the Tooling group. 4 | 5 | 6 | 7 | - [Add Common Filesystem Operations to Core](#add-common-filesystem-operations-to-core) 8 | - [Summary](#summary) 9 | - [Motivation](#motivation) 10 | - [Example 1: The Bundler](#example-1-the-bundler) 11 | - [Example 2: The Test Case](#example-2-the-test-case) 12 | - [Notes](#notes) 13 | 14 | 15 | 16 | ## Add Common Filesystem Operations to Core 17 | 18 | ### Summary 19 | 20 | Two (2) filesystem operations should be added to Node.js Core: 21 | 22 | 1. Recursively create a directory (e.g., `mkdir -p foo/bar`) 23 | 2. Recursively remove a directory (e.g., `rm -rf foo`) 24 | 25 | The popular userland modules [mkdirp](https://npm.im/mkdirp) and [rimraf](https://npm.im/rimraf) respectively provide this functionality. 26 | 27 | ### Motivation 28 | 29 | Keeping Node.js' core API small is a commendable goal. Additions to Node.js' core API should not be taken lightly! Yet over time, Node.js' users have found some functionality that truly seems "missing". **These two operations are frequently-cited examples of userland modules which should be built-in to Node.js core.** 30 | 31 | Use cases are *extremely common*, especially amongst Node.js CLI applications. From bundlers to scaffolding tools to package managers; many need to recursively create and destroy directory structures. It's inconvenient for users, as many new to Node.js expect this functionality to be part of the "standard library". New and experienced Node.js users are incredulous that external modules must be installed to do these common tasks. 32 | 33 | ### Example 1: The Bundler 34 | 35 | It's 2018, and developer P.J. needs to bundle a web application. P.J. has written a bundling tool, `wabpeck`, written in Node.js. `wabpeck` allows the user to configure an "output" directory using the command-line option, `--output `. 36 | 37 | P.J. chooses the output directory, and runs `wabpeck input.js --output /var/www/sites/pj/staging/alpha/static/dist`. `wabpeck` fails: 38 | 39 | ```plain 40 | fs.js:143 41 | throw err; 42 | ^ 43 | 44 | Error: ENOENT: no such file or directory, mkdir '/var/www/sites/pj/staging/alpha/static/dist' 45 | at Object.fs.mkdirSync (fs.js:872:3) 46 | ``` 47 | 48 | P.J. is confused. P.J. thinks, "Of course it doesn't exist--why do you think I'm trying to create it?!" P.J. investigates further, and by random chance, chooses to list the contents of `/var/www/sites/pj/staging/alpha`: 49 | 50 | ```plain 51 | total 16 52 | -rw-r--r-- 1 pj wheel 5979 Jun 8 11:01 anarchist_cookbook.txt 53 | ``` 54 | 55 | P.J. (somehow) realizes that `/var/www/sites/pj/staging/alpha/static` doesn't exist, so `fs.mkdirSync` can't create `/var/www/sites/pj/staging/alpha/static/dist`. 56 | 57 | Because `fs` contains no functionality to do this, P.J. now has two choices: modify `wabpeck` to use [mkdirp](https://npm.im/mkdirp), or re-invent a wheel. 58 | 59 | ### Example 2: The Test Case 60 | 61 | P.J. has made the change to use [mkdirp](https://npm.im/mkdirp), but wants to ensure it's correct. Like a good developer, P.J. writes an integration test, careful to clean up afterwards: 62 | 63 | ```js 64 | const {tmpdir} = require('os'); 65 | const {join} = require('path'); 66 | const {existsSync, rmdirSync} = require('fs'); 67 | const assert = require('assert'); 68 | 69 | describe('--output', function() { 70 | it('should create a directory recursively', function() { 71 | const recursive1dir = join(tmpdir(), 'recursive-1'); 72 | const recursive2dir = join(recursive1dir, 'recursive-2'); 73 | // minified dummy output bundle 74 | const expected = join(recursive2dir, 'input-fixture.min.js'); 75 | const w = wabpeck({ 76 | input: join(__dirname, 'input-fixture.js') // dummy input file 77 | output: recursive2dir 78 | }); 79 | try { 80 | w.bundle(); 81 | assert.ok(existsSync(expected)); 82 | } finally { 83 | rmdirSync(recursive1dir); 84 | } 85 | }); 86 | }); 87 | ``` 88 | 89 | Accidentally practicing TDD, P.J. runs the test and notes it's throwing an exception on the call to `rmdirSync`. 90 | 91 | P.J. realizes `rmdirSync` fails for a similar reason; `recursive1dir` isn't empty. Again, P.J. has two choices: modify the tests to use [rimraf](https://npm.im/rimraf), or re-invent another wheel. 92 | 93 | ### Notes 94 | 95 | Assuming methods would be added to `fs`, this would not (as far as the author knows) require breaking changes which would violate the `fs` module's "Stable" stability status. 96 | 97 | There is precedent for these out-of-the-box in other languages, such as Python (`os.makedirs()` and `shutil.rmtree()`). 98 | -------------------------------------------------------------------------------- /meetings/2017-12-01.md: -------------------------------------------------------------------------------- 1 | # Node.js End User Feedback (NEUF) Meeting 2017-12-01 2 | 3 | ## Links 4 | 5 | * **Recording**: https://www.youtube.com/watch?v=WrOXMIlcvoQ 6 | * **GitHub Issue:** https://github.com/nodejs/user-feedback/issues/6 7 | * **Minutes Google Doc:** https://docs.google.com/document/d/1oLUDZXxzldphOZKPwINW_SnsViwW51JE6ad-rKwF618/edit 8 | * **Previous Minutes Google Doc:** N/A 9 | 10 | ## Present 11 | 12 | - Dan Shaw (@dshaw - CommComm observer) 13 | - Mike Hostetler (@mikehostetler) 14 | - William Kapke (@williamkapke - CommComm, Individual Member Director) 15 | - Mihai Ene-Pietrosanu (@mihaiep) 16 | - Michael Dawson (@mhdawson - CommComm, TSC Chair) 17 | - Tierney Cyren (@bnb - CommComm Co-Chair) 18 | 19 | ## Agenda 20 | 21 | Extracted from [neuf-agenda](https://github.com/nodejs/user-feedback/labels/neuf-agenda) labelled issues and pull requests from the [user-feedback](https://github.com/nodejs/user-feedback) repo prior to the meeting. 22 | - User Feedback Meeting Cadence (ref: #2) 23 | - Friday 17:00 UTC / noon ET / 11am CT / 9am PT every 2 weeks starting 2017-12-01 24 | - Add CoC, CONTRIBUTING.md, and Repo Accountability (ref: #4) 25 | - Supporting the Node.js 2018 User Survey (ref: #8 ) 26 | - Bench-marking team request for survey (ref: nodejs/community-committee#153) 27 | - Initial Users for feedback meetings (ref: #12) 28 | 29 | ## Notes 30 | 31 | **Supporting the Node.js 2018 User Survey (ref: #8 )** 32 | - [MikeH] Request previous year's data from the Foundation to be able to explore trend data. 33 | - [MikeH] Issue created around getting survey results (ref: #14) 34 | - [Dawson] We should make supporting the Annual Node.js Foundation survey a mandate of NEUF. 35 | - [Tierney] The Annual Node.js User Survey is announced and launched each year at Node.js Interactive. The next Node.js User Survey will be launched at JS Interactive in October 2018. 36 | - [dshaw] Let's reach out to Greg Wallace and invite him to attend the next meeting (on 2017-12-15). 37 | 38 | **Bench-marking team request for survey (ref: nodejs/community-committee#153)** 39 | - [dshaw] We should see if Greg Wallace could help to create a survey for Benchmarking using Foundation infrastructure (esp. Survey Monkey account). 40 | - [Tierney] We should include Zibby Keaton as well. 41 | - [dshaw] Let's invite both Greg Wallace and Zibby Keaton to the next NEUF meeting. 42 | - [MikeH] As we create online surveys, let's keep in mind our goals to be able to do face-to-face outreach and support data collection from face-to-face sessions. 43 | - [MDawson] It would be nice to get the survey input process started in 2017. Can we launch before the end of the year 44 | - [dshaw] I'm happy to to meet with Greg prior to the next meeting to accelerate the process. Dawson and Tierney to join. 45 | 46 | **Initial Users for feedback meetings (ref: #12)** 47 | - [Dawson] I'd like to invite some local companies from Toronto to provide feedback. Are we ready to kick off sessions? 48 | - [dshaw] To be respectful of everyone's time, what if we alternate organizational meetings with public outreach sessions during the bi-weekly cadence of the user-feedback meetings. 49 | - [Dawson] We don't have to do it too frequently. Perhaps b-monthly. 50 | - [dshaw] Let's target February 9th for the initial session. 51 | - [Dawson] I'll create an issue to track this and point folks to. 52 | 53 | **Closing Thoughts** 54 | - [Kapke] Is this initiative interested in supporting feedback and outreach to Node.js users/companies who are evaluating Node.js? 55 | - [dshaw] Very much interested in supporting potential Node.js adopters. In fact, I was just in France helping a major insurance provider kick off their selection and adoption of Node.js. I'm sure I could invite folks from that organization to share about that journey. 56 | - [dshaw] We could invite folks to discuss this at the January 12th meeting. 57 | 58 | ## Upcoming Meetings 59 | 60 | * The next meeting is scheduled for Friday, 2017-12-15 at 17:00 UTC / noon ET / 11am CT / 9am PT. 61 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 62 | - Click `+GoogleCalendar` at the bottom right to add to your own calendar. 63 | 64 | -------------------------------------------------------------------------------- /meetings/2017-12-15.md: -------------------------------------------------------------------------------- 1 | ## Node.js End User Feedback (NEUF) Meeting 2017-12-15 2 | 3 | ## Links 4 | 5 | * **Recording**: previous 2017-12-01 https://www.youtube.com/watch?v=WrOXMIlcvoQ 6 | * **GitHub Issue:** https://github.com/nodejs/user-feedback/issues/17 7 | * **Minutes Google Doc:** https://docs.google.com/document/d/1CMKB5-Jp62I0eWk-8Zw4_Ka3lma5frHZEFax9bx-YNw/edit 8 | * **Previous Minutes Google Doc:** https://docs.google.com/document/d/1oLUDZXxzldphOZKPwINW_SnsViwW51JE6ad-rKwF618/edit 9 | 10 | ## Present 11 | 12 | - Dan Shaw (@dshaw - CommComm observer, NEUF organizer) 13 | - Mihai Ene-Pietrosanu (@mihaiep) 14 | - Tierney Cyren (@bnb -CommComm Co-Chair) 15 | - Greg Wallace (@gtewallace) 16 | - Ahmad Nassri (@ahmadnassri) 17 | - Kevin Allen (https://twitter.com/KevJosephAllen) 18 | - Diego ZoracKy (@DiegoZoracKy) 19 | 20 | ## Agenda 21 | 22 | Extracted from [neuf-agenda](https://github.com/nodejs/user-feedback/labels/neuf-agenda) labelled issues and pull requests from the [user-feedback](https://github.com/nodejs/user-feedback) repo prior to the meeting. 23 | - Supporting the Node.js 2018 User Survey (ref: #8) 24 | - Discussion and overview of the annual Node.js User Survey with @gtewallace 25 | - Initial Users for feedback meetings (ref: #12) 26 | - Next NEUF Meeting is scheduled for Friday, December 29th during holiday "dead week". Going to cancel unless there are objections? Will need help removing the event from a Calendar Maintainer. 27 | 28 | **TOPIC** 29 | 30 | ## Notes 31 | * We have a list of folks engaged in providing feedback data with help from Foundation team 32 | * We have user-feedback@nodejs.org. email setup.**Thank you, Michael** 33 | * With the Benchmarking team survey still on, we will keep the meeting on 12.29.2017 34 | **Thank you Tierney** for helping us setting the meeting) 35 | * Highlights from Greg Wallace, **many thanks Greg**: 36 | * Right now, we are doing the third annual user survey run by the Foundation useful 37 | for community too (beginning with 2015- around 700 responses, 2016 around 1400 responses 38 | and now the third one still running, more than 1500 responses at this time). 39 | Statistically significant as a sample. 40 | * The survey is completely anonymous with the option that if you willing to be contacted by the Foundation, 41 | you may provide email address. We have a good number after each survey with good technical detail; from end-users 42 | 43 | * For the surveys closed (2015 and 2016) we need information from the responses. 44 | 45 | * Issue: in open-ended questions when we have open /free text it’s hard to identify trends, 46 | unless you are a very good in analyzing data. Polly, the researcher, recommended that wherever possible that may 47 | change into “closed questions” -that means a list a series of options to pick from. 48 | It’s very possible that a percentage will respond in a way that isn’t provided among the list we come up with, 49 | so you always must have another category. If we know the subject, 50 | you usually get 95-98% of respondents who find the options in the multiple-choice list that you provide. 51 | 52 | * If you want a handful of highly targeted responses, then this it should be into our promotional strategy 53 | 54 | Comment: (need a list/email that Greg will provide to us). 55 | 56 | Question(Mihai): Why is the survey bilingual? 57 | Answer(Greg): The users from China significantly increase responses and we offered the questions in Chinese. Running different surveys in several languages in Survey Monkey currently results in multiple data sets. We got great help from China translating the questions. 58 | 59 | Question (Diego) Can we have data results to run our own analysis? 60 | Answer (Dan) Yes, Greg will provide us the data and we’re going to posted in user-feedback repo 61 | 62 | Question(Tierney) How the company name would be anonymized? Do we think, including company name, matters or not? 63 | 64 | (Dan)In January 12, 2018 we will have an initial feedback session with the output that companies who’ve recently choose Node.js or evaluating 65 | 66 | 67 | **Closing Thoughts** 68 | - [Tierney] Expressed concerns about how the Enterprise Advisory Group has been added to the responsibilities of the Node.js End User Feedback Initiative and therefore the CommComm without notifying the CommComm of its purpose and that actions were being taken. 69 | 70 | ## Upcoming Meetings 71 | 72 | * The next meeting is scheduled for Friday, 2017-12-29 at 17:00 UTC / noon ET / 11am CT / 9am PT. 73 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 74 | - Click `+GoogleCalendar` at the bottom right to add to your own calendar. 75 | 76 | 77 | 78 | -------------------------------------------------------------------------------- /meetings/2017-12-29.md: -------------------------------------------------------------------------------- 1 | ## Node.js End User Feedback (NEUF) Meeting 2017-12-29 2 | 3 | ## Links 4 | 5 | * **Recording**: https://www.youtube.com/watch?v=PmNHnVslzps&t=43s 6 | * **Minutes Google Doc:** https://docs.google.com/document/d/1CMKB5-Jp62I0eWk-8Zw4_Ka3lma5frHZEFax9bx-YNw/edit 7 | * **Previous Minutes Google Doc:** https://docs.google.com/document/d/1CMKB5-Jp62I0eWk-8Zw4_Ka3lma5frHZEFax9bx-YNw/edit 8 | 9 | ## Present 10 | 11 | - Dan Shaw (@dshaw - CommComm observer) 12 | - Tierney Cyren (@bnb - CommComm Co-Chair) 13 | 14 | ## Agenda 15 | 16 | Extracted from [neuf-agenda](https://github.com/nodejs/user-feedback/labels/neuf-agenda) labelled issues and pull requests from the [user-feedback](https://github.com/nodejs/user-feedback) repo prior to the meeting. 17 | - Light meeting to promote and share progress around the Benchmarking Working Group survey (ref: #22) 18 | 19 | ## Notes 20 | 21 | **TOPIC** 22 | - Benchmarking Working Group survey 23 | 24 | Benchmarking WG requested survey in October. 25 | Live now at https://www.surveymonkey.com/r/NodeBenchmarking 26 | Data is hosted by the Node.js Foundation (NF) with the help of Greg Wallace. NEUF team will request data from NF. 27 | 28 | 29 | **Closing Thoughts** 30 | - Next meeting is slated for 2017-01-12 and was going to be the first public, recorded End User Feedback session. Kapke wanted to organize a session with "New Node.js Users, plus Users Choosing Node.js now", but will be unable to attend. We'll hold a regular meeting and continue survey data collection, then hold the first public feedback session in February. 31 | 32 | ## Upcoming Meetings 33 | 34 | * The next meeting is scheduled for Friday, 2018-01-12 at 17:00 UTC / noon ET / 11am CT / 9am PT. 35 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 36 | - Click `+GoogleCalendar` at the bottom right to add to your own calendar. 37 | 38 | 39 | -------------------------------------------------------------------------------- /meetings/2018-01-12.md: -------------------------------------------------------------------------------- 1 | ## Node.js End User Feedback (NEUF) Meeting 2018-01-12 2 | 3 | ## Links 4 | 5 | * **Recording**: https://www.youtube.com/watch?v=QXdnB3c6wT0&feature=youtu.be 6 | 7 | * **GitHub Issue:** https://github.com/nodejs/user-feedback/issues/6 8 | * **Previous Minutes Google Doc:** https://docs.google.com/document/d/1CMKB5-Jp62I0eWk-8Zw4_Ka3lma5frHZEFax9bx-YNw/edit 9 | 10 | ## Present 11 | 12 | - Dan Shaw (@dshaw - CommComm observer) 13 | - Mihai Ene-Pietrosanu (@mihaiep) 14 | - Tierney Cyren (@bnb - CommComm Co-Chair) 15 | - Michael Dawson (@mhdawson - CommComm) 16 | - Greg Wallace (@gtewallace - Linux Foundation) 17 | 18 | 19 | ## Agenda 20 | 21 | Extracted from [neuf-agenda](https://github.com/nodejs/user-feedback/labels/neuf-agenda) labelled issues and pull requests from the [user-feedback](https://github.com/nodejs/user-feedback) repo prior to the meeting. 22 | 23 | * Intro / Attendance 24 | * [Key Initiatives](https://github.com/nodejs/user-feedback/labels/key-initiative) 25 | * 2017 Benchmarking WG Survey (ref: https://github.com/nodejs/user-feedback/issues/22) 26 | * Big shout out to Greg in helping with get the survey out. 27 | * Some feedback that we can reword to make sure we clarify scope a 28 | Bit. 29 | * Plan to wrap up and the end of the month. So let's keep 30 | Publicising until then. We have >140 responses already. 31 | * One main thing we still need to do is figure out how/what can 32 | be public. Dan, create issue and invite Tracy to help (Tierney 33 | Suggested that she would know what we need to do on that front). 34 | * End User Feedback - Looking for Participants (ref: https://github.com/nodejs/user-feedback/issues/20) 35 | * Sent responses to first batch just after Christmas. 36 | * Need to send responses to second set soon. 37 | * Probably in the order or 10 responses. 38 | * Enterprise Advisory Group Team (ref: https://github.com/nodejs/user-feedback/issues/18) 39 | * Lots of discussion, happy with support from CommComm 40 | yesterday that people are agreement with concept. 41 | * People are comfortable with user feedback group to continue 42 | moving this forward. 43 | * Setup meeting discuss any remaining concerns/issues. 44 | 45 | * Enterprise Advisory Group Charter, expectations and responsibilities (ref: https://github.com/nodejs/enterprise-advisory-group/pull/5) 46 | 47 | * Request for membership by @jchip, WalmartLabs (ref: https://github.com/nodejs/enterprise-advisory-group/issues/7) 48 | 49 | * 2018-02-09 Public User Feedback Meeting - Enterprise User Feedback (ref: https://github.com/nodejs/user-feedback/issues/27) 50 | 51 | 52 | * Public user feedback meeting 53 | * Some discussion about focus. Michael pitched first as a meet/get 54 | to know the participants and then use content for the benchmarking 55 | survey as concrete discussion. 56 | * Dan asked about need to let people know that it is public. Agreed 57 | we should have text to remind people, out of that we should also 58 | highlight that its also under the Node.js code of conduct. 59 | * Dan will follow up with second set of volunteers, will bash agenda 60 | and work on invite. 61 | 62 | **TOPIC** 63 | ## Notes 64 | * Intro 65 | 66 | * We had discussion around Enterprise Advisory group, Dan (@dshaw) labeled these here 67 | https://github.com/nodejs/user-feedback/labels/key-initiative 68 | * We need to step in and plan 2018-02-09 Public User Feedback Meeting - Enterprise User Feedback (ref: #27), 69 | the expectations for this first meeting to be primary brainstorming. 70 | * The Benchmarking WG survey (big thanks for Foundation and Greg Wallace- for setting everything up and being present during the Holidays) . 71 | 72 | (Michael D) Differences between be in who is representing 50 people for example (a reasonable team) and who is representing big teams (350,000) 73 | 74 | (Tierney C)The people who are answering are going to be relevant 75 | But also we’ll need to know the input from other (not only representative group or team) 76 | 77 | (Dan S) There are a couple of actions to be done for context at present, we are planning on wrapping up the input from the survey at the end of the month, we need additional promotion from CommComm and Evangelism WG 78 | * We have around 140 answers on Bench survey. Will close EOM (end of month) 79 | 80 | (Dan S) What is a good number for responses?-statistical relevance/ 100 definitely is an inflection point, 81 | for the data collected (meaning we’re going well) 82 | 83 | (Michael D) The main thing it is what we can make public? 84 | 85 | (Tierney C) Tracy may have the imput to do this appropriately 86 | * Need to create an issue for this (what can we make public…) and invite Tracy (next meeting) 1.26.2018 87 | 88 | * User feedback looking for participants issue opened by Michael D https://github.com/nodejs/user-feedback/issues/20 89 | 90 | (Michael D) We have a good number to get started (it will be nice more people. 10 to 20 responded. 91 | This will be our first feedback public session (limiting for enterprise users will be too constraining, we’ll need a broader audience) 92 | 93 | * Enterprise Advisory Group Charter, expectations and responsibilities (ref: nodejs/enterprise-advisory-group#5) 94 | https://github.com/nodejs/enterprise-advisory-group 95 | * Observations/comments from CommComm co-chairs are not representing position of the Community, unless are specified. Also establish expectations from members: it’s not just you come to the meeting and that’s it, we need members who potentially do outside stuff of the sessions. 96 | * Last 20 minutes of the meeting were dedicated for the Public User Feedback (February, 9) 97 | 98 | (Michael D) We can use the Benchmarking survey that something to discuss as a concrete and see what kind of a feedback we are getting. 99 | We need to open an issue for an open sesion and have Benchmarking survey as a baseline (or having the model in mind) 100 | 101 | (Greg W) We need to be tell to the people that we are public and conversation are broadcast, where people can bring their perspective and contribute their thoughts to improve the technology, and because is an open source technology these conversations will be open as well) 102 | 103 | (Dan S) Do we need the moderation team? 104 | 105 | (Michael D) It’s our responsibility as members that things don’t go off rails. Reminder that this is public and you don’t want to say anything that you don’t want to be seen in public (link to code of conduct?) 106 | 107 | (Mihai E-P) We need to close the non-active issues, with all the meetings going on we will have new issues coming and we need to close the old ones. 108 | 109 | 110 | 111 | **Closing Thoughts** 112 | 113 | 114 | ## Upcoming Meetings 1.26.2018 https://github.com/nodejs/user-feedback/issues/28 115 | 116 | * The next meeting is scheduled for Friday, 2018-01-26 at 17:00 UTC / noon ET / 11am CT / 9am PT. 117 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 118 | - Click `+GoogleCalendar` at the bottom right to add to your own calendar. 119 | 120 | 121 | 122 | -------------------------------------------------------------------------------- /meetings/2018-01-26.md: -------------------------------------------------------------------------------- 1 | # Node.js End User Feedback (NEUF) Meeting 2018-01-26 2 | 3 | ## Links 4 | 5 | * **Recording**: https://www.youtube.com/watch?v=ytj9uAsozDw 6 | * **GitHub Issue:** https://github.com/nodejs/user-feedback/issues/28 7 | * **Previous Minutes:** https://docs.google.com/document/d/1igMLOTd0TJHf0hbXqcLIl-tXmj9vlK9G3h1W2d9TQFo 8 | 9 | ## Present 10 | 11 | - Dan Shaw (@dshaw - CommComm observer) 12 | - Mihai Ene-Pietrosanu (@mihaiep- User Feedback member) 13 | - Tierney Cyren (@bnb - CommComm Co-Chair) 14 | - Joel Chen (@jchip WalmartLabs) 15 | 16 | # Agenda 17 | * Extracted from neuf-agenda labelled issues and pull requests from the user-feedback repo prior to the meeting. 18 | * Intro / Attendance 19 | * Key Initiatives 20 | * 2017 Benchmarking WG Survey (ref: #22) 21 | * End User Feedback - Looking for Participants (ref: #20) 22 | * Enterprise Advisory Group (ref: #18) 23 | * Welcome @mihaiep as User Feedback Member (ref: #30) 24 | * Add meeting template (ref: #28 (comment)) 25 | * Participation and Node.js Community session at Index 2018 (ref: #29 and nodejs/admin#44) 26 | * 2018-02-09 Public User Feedback Meeting - Node.js Benchmarking (ref: #27) 27 | 28 | # Invited 29 | * Dan Shaw (@dshaw - User Feedback Champion, CommComm observer) 30 | * Mike Hostetler (@mikehostetler - User Feedback member) 31 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback member) 32 | * William Kapke (@williamkapke - CommComm, User Feedback member) 33 | * Michael Dawson (@mhdawson, TSC Chair, CommComm, User Feedback member) 34 | * Tierney Cyren (@bnb - CommComm Co-Chair) 35 | * Tracy Hinds (@hackygolucky - CommComm) 36 | * Greg Wallace (@gtewallace - Node.js Foundation) 37 | * Bradley Farias (@bmeck - end user representative from GoDaddy) 38 | 39 | **TOPIC** 40 | # Notes 41 | We are approaching 150-160 Benchmarking survey answers. Will be great if by the end of January (end of survey submission) 42 | will have around 200 (Tierney tweeded, thank you). Pushed on media to get more answers. 43 | **Thank you Joel** for joining this meeting. 44 | 45 | * One of the challenges is not everyone can be on github and for some users we do not have a real time 46 | channel of communication and may be reflected on how to be engaged in Node.js 47 | * (Joel) Tweeter and Github are working well for the people interested in Node.Js 48 | * Join Node.js Slack: http://nodeslackers.com 49 | * Enterprise Advisory Group- we are looking at quarterly cadence with a proposal in mind for an on-site meeting, 50 | to learn how our large installs of Node.js are being used and provide direct feedback from those individuals. 51 | At this point probably it will be beginning of March. 52 | * Add meeting template (ref: #28 (comment)) 53 | * (Tierney)-create the issue for the next meeting automatically : there are 4 different types of files. 54 | Mihai will create a PR and will work on this 55 | * Index 2018 Moscone West, San Francisco 56 | * 2018-02-09 Public User Feedback Meeting: since the Benchmarking WG will not have time 57 | to digest the results of the survey, focus on why to questions were asked and what 58 | the WG will try to accomplish and the potential direction we are looking for. 59 | 60 | *Closing Thoughts* 61 | 62 | * **Upcoming Meetings 2.9.2018** https://github.com/nodejs/user-feedback/issues/27 63 | * The next meeting is scheduled for Friday, 2018-02-09 at 17:00 UTC / noon ET / 11am CT / 9am PT. 64 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 65 | - Click `+GoogleCalendar` at the bottom right to add to your own calendar. 66 | 67 | -------------------------------------------------------------------------------- /meetings/2018-02-16.md: -------------------------------------------------------------------------------- 1 | # 2018-02-16 Public User Feedback Meeting - Node.js Benchmarking 2 | 3 | ## Links 4 | 5 | * **Recording**: https://www.youtube.com/watch?v=BTiBmW83FMY 6 | * **GitHub Issue:** https://github.com/nodejs/user-feedback/issues/27 7 | * **Previous Minutes:** https://docs.google.com/document/d/13kjBLpK3huHgCebxROpBNuUQLNyyOafaI5lOKi129Co/edit 8 | 9 | ## Present 10 | 11 | - Dan Shaw (@dshaw - User Feedback lead, CommComm member) 12 | - Mihai Ene-Pietrosanu (@mihaiep- User Feedback member) 13 | - Tierney Cyren (@bnb - CommComm Co-Chair) 14 | - Michael Dawson (@mhdawson - CommComm member, TSC Chair) 15 | – Tracy Hinds (@hackygolucky – CommComm member, Leadership Subcommittee Chair) 16 | 17 | * End users 18 | - Joel Chen (@jchip WalmartLabs) 19 | - Bradley Farias (@bmeck GoDaddy) 20 | - Aaron Bartell (Krengel Tech) 21 | - Matvienko Nikolay (Grid Dynamics) 22 | - Tierney Cyren (NodeSource) 23 | ## Agenda 24 | 25 | * Extracted from neuf-agenda labelled issues and pull requests from the user-feedback repo prior to the meeting. 26 | * Introduction to the Benchmarking Working Group (WG) with @mhdawson 27 | * Presentation of the Benchmarking Survey Results 28 | * Detailed feedback from select attending representatives 29 | * Open feedback forum 30 | * Invited 31 | User Feedback team members 32 | * Dan Shaw (@dshaw - User Feedback, CommComm observer) 33 | * Mike Hostetler (@mikehostetler) 34 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback) 35 | * William Kapke (@williamkapke - CommComm, Individual Member Director) 36 | * Michael Dawson (@mhdawson - User Feedback, CommComm, TSC Chair) 37 | * Tierney Cyren (@bnb - User Feedback, CommComm Co-Chair) 38 | * Tracy Hinds (@hackygolucky - CommComm) 39 | * Greg Wallace (@gtewallace - Node.js Foundation) 40 | 41 | End User Representatives 42 | * Bradley Farias (@bmeck - GoDaddy) 43 | * Mohammad Khan 44 | * Tierney Cyren (Node Source) 45 | * Amanda Blackburn (Profound Logic) 46 | * Mittra, Partha (whisolutions) 47 | * Heckmann, Aaron (Paypal) 48 | * Aaron Bartell (Krengel Tech) 49 | * Matvienko Nikolay (Grid Dynamics) 50 | * Jeremy Meyer (Jack Henry) 51 | * Bradley Meck (GoDaddy) 52 | 53 | **TOPIC** 54 | * **Thanks** to our guests Bradley, Joel, Aaron, Nikolay, Tierney and thanks all for participation 55 | in first Public User Feedback-Node.js Benchmarking. 56 | * Intro 57 | * **Michael Dawson: Introduction to the Benchmarking WG.** 58 | * What the Benchmarking Group is? 59 | * Repo here: https://github.com/nodejs/benchmarking 60 | The focus: we want to track and evangelize performance gains 61 | between releases and avoid performance regressions. 62 | Make sure Node is running efficiently. 63 | 1. Define Use cases: https://github.com/nodejs/benchmarking/blob/master/docs/use_cases.md 64 | 65 | If you have a user case that doesn’t fit into one of these here is important for you to let us know, 66 | so we can factor in additional use cases into the work we do here. 67 | 68 | 2. Key runtime attributes 69 | https://github.com/nodejs/benchmarking/blob/master/docs/runtime_attributes.md 70 | 71 | 3. Case coverage (coverage of use cases and key attributes)-to track performance 72 | https://github.com/nodejs/benchmarking/blob/master/docs/case_coverage.md. 73 | The benches running every night https://benchmarking.nodejs.org/. 74 | We have a dedicated number of machines running (donated by Intel and IBM); hardware machines vs virtual machines. 75 | We will have a session at Community day @Index 2018, Feb 20/ free registration for that. 76 | 77 | * **Dan Shaw: Benchmarking survey details** 78 | * Next meeting, we will have a debrief for survey, improvements, upgrades. 79 | * **Survey Q#2:** What version of Node.js do you currently use for production? 80 | 81 | * Answered 294: 82 | * 9.x Current 25% 83 | * 8.x LTS 74% 84 | * 6.x LTS 38% 85 | * 4.x LTS 12% 86 | * Pre 4.x 2% 87 | 88 | * Bradley&Joel: we have 2 months lag time on LTS 89 | * Joel: Start testing on applications internally after is promoted to LTS. 90 | We have half, half 6 and 8 versions. 91 | * Bradley: Start testing before LTS 92 | * Tierney: In your production environment how do you handle upgrades, 93 | security updates, patches? 94 | * Joel: we are going with the entire update pull request, 95 | QA sign off and then deploy 96 | * Bradley: pretty much the same 97 | * Aaron: got recently 8.x, most of the platforms 6.x 98 | * Nikolay: we have 8 version in production; using TurboFan Ignition boosted our performance 99 | * Tierney: Is anyone actually using yarn either for dev or production? 100 | * Joel: Has some issues that our build generally doesn’t work well. 101 | In my testing with our real-word applications from 6 version to 8 version, 102 | we saw a 60% improvement in performance 103 | * **Survey Q#4:** What is your primary use case for Node? 104 | * **Answered 294:** 105 | * back-end API services 43% 106 | * service oriented 3% 107 | * microservice-based 19% 108 | * generating serving dynamic 8% 109 | * SPA applications 9% 110 | * Agents and Data Collectors 2% 111 | * Web Developer Tooling 9% 112 | * Small scripts 1% 113 | * Joel: we would like to see more on this case: 114 | how to use Node direct connect to back -end databases, 115 | because now our apps when they need to connect DB they go through service that’s reading Java. 116 | * Bradley: we don’t auto scale our build services, 117 | we have service-oriented architecture with immutable builds 118 | 119 | * **Survey Q#6:** Do you have infrastructure in place for tracking performance on your applications? 120 | Answered 288: Yes 38%, Work in progress 30%, No 32% 121 | * Joel: we have a logging to Splunk for general application: 122 | less about performance but more about the application health and monitoring 123 | usage on our website. APM infrastructure based on Kafka. 124 | * Bradley: APMs running; need to be turned off in some cases 125 | in production due to leaking memory, essentially while they try to track events. 126 | Reccomendation: include node report in all green applications 127 | (get some reports started last month). 128 | * Nikolay: Splunk for logging, using New Relic as monitoring systems and to be ready for Black Fridays. 129 | Monitoring systems are big impact on performance 130 | 131 | **Survey Q#9:** What type of optimization passes do you run on your JavaScript you deploy it to Node.Js? 132 | Answered 211: Minification 68%, Bundling 60%, Obfuscation 20%, Other 22% 133 | 134 | **Survey Q#16:** Do you have use cases where you cannot use Node.js because it is single threaded? 135 | Answered 282: Yes 22%, No 78% 136 | * Nikolay: anything that need to use cpu that’s a bottleneck 137 | * Joel: a single threat definitely is something that we’re constantly trying to have to work around it, because we do e-commerce and the server can general do one to two requests per second 138 | 139 | ## Questions, remarks: 140 | * Aaron: We can help with scripts for IBM I platforms/ running on same benchmark. 141 | * Tierney: Should we provide a way to go in benchmark for like user land? 142 | * Michael: Is something that users can contribute to in order to increase coverage in our matrix, 143 | or something differently we can run and evaluate? 144 | * Joel: Happy to look in service-oriented architecture, 145 | most of our applications, majority work they do is making its service 146 | cost to the back-end microservices. 147 | 148 | Useful link: https://github.com/v8/web-tooling-benchmark 149 | 150 | * Joel: We have a lot of trouble in terms of performance, 151 | stylus compounding, internally we use SAAS try our CSS and then 152 | we have the compiled massive piles and some of the deeply nested trees, 153 | they take huge amount of time (nested structure). 154 | * Michael: Comments that you might like SAAS compiler in the web tool? 155 | * Bradley: There is one comment Go Daddy has had about this web tooling 156 | benchmark if you go and look how it runs all these benchmarks are requiring 157 | that whatever they run be synchronous so that’s the reason webpack is not here, 158 | so we’ve got our own stuff going separate of this. We have some build farms we run web pack. 159 | * Bradley: another big part has been memory uses, when we have everything cached 160 | at every node of our service-oriented architecture. 161 | * Michael: Sounds like 2 areas: maybe you’ll be able to contribute additional 162 | benchmark we might want to be running for the web tooling side, 163 | then also if you have some specific things around memory in terms of measuring 164 | it might be a good addition use case. 165 | * Dan: when we talk about caching what are the bounds that you would look for there? 166 | * Bradley: We have multi-tiered caches, so garbage collection 167 | can become a problem once we get into several gigabytes in size 168 | for our caches some of them are running at 8 gigs for their cache size. 169 | * Dan: It is a great way to begin exploring benchmarking usage. 170 | * Michael: If you have benchmarks and you want to pursue the discussion 171 | with the Benchmarking WG you can may open an issue in the Benchmarking WG. 172 | 173 | **Closing Thoughts** 174 | * Dan: for questions or others Index 2018 is an opportunity to talk direct to people. 175 | https://developer.ibm.com/indexconf/?cm_mmc=dw-_-social1711-_-redirect-_-indexconf 176 | * Tierney: something we could improve on for the future correlating with 177 | size of company because a smaller company isn’t going to have more 178 | than a hundred applications in production. 179 | * Dan: flag the discussion around diagnostic that touched pooling; 180 | if pooling and pooling mechanism that are pain point computationally intensive. 181 | * Tierney: Monitoring systems are big impact on performance+security. 182 | * Michael: start a thread, because some users have concrete use cases, 183 | follow-up and get actually documented. 184 | 185 | ## Upcoming Meetings 2018-02-23 186 | * The next meeting is scheduled for Friday, 2018-03-02 at 17:00 UTC / noon ET / 11am CT / 9am PT. 187 | * https://github.com/nodejs/user-feedback/issues/32 188 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 189 | - Click `+GoogleCalendar` at the bottom right to add to your own calendar. 190 | 191 | -------------------------------------------------------------------------------- /meetings/2018-02-20.md: -------------------------------------------------------------------------------- 1 | ## 2018-02-20 Index2018 User Feedback Conference 2 | 3 | * **Useful links:** 4 | * http://oneops.com/ 5 | * http://www.electrode.io/ 6 | * http://www.electrode.io/docs/what_is_electrode.html 7 | 8 | ## Node.Js: 9 | * Mark Hinkle, Michael Dawson, Tierney Cyren, Dan Shaw, Mihai Ene-Pietrosanu 10 | ## Walmart Labs engineer team: 11 | * Joel Chen and Shen 12 | 13 | ## Intro-by Dan Shaw 14 | * We want to create a bidirectional channel for the project and the best way to do that is in person, 15 | we will get immediate feedback. 16 | **Thanks to Joel and his engineers team from Walmart Labs for their feedback.** 17 | * Dan: Could you describe how Node.Js is use at Walmart? 18 | * Joel: Walmart Labs has a long history from 2012 with a development with Happy.js and Walmart Labs 19 | has a flourishing Node.Js community who continuously use Node.js to develop their applications. 20 | About 2 years ago Walmart decided to introduce a back-end based on Node.Js. Many teams used Node.Js 21 | but everyone wrote their own scripts (for monitoring cloud, build, logging) 22 | Walmart Labs has its own cloud infrastructure called OneOps , trying to offer Node.Js as a first-class 23 | citizen on the platform, but initially they did not have enough knowledge on Node.Js, 24 | they were based on Java and Ruby developers. 25 | * The pilot team developed a non-critical app on Node.Js/React.Js and ultimately 26 | every team decided to migrate all apps from Java to Node.Js 27 | (security, monitoring, education, stability, on boarding). 28 | * Walmart spent significant resources in training Node.Js developers. 29 | They use Redoc and server -side rendering 30 | Today on Walmart.com everything is running on Node.Js. 31 | 32 | * Dan: Can you described what you encapsulate in the Electrode project to help engineers at Walmart to be successful? 33 | * Joel: Electrode has started as exploratory project at Walmart Labs when they were looking 34 | to migrate the existing Walmart UI. Node.Js came as a natural transition. 35 | The problem observed was the internal fragmented effort of every team. 36 | Electrode provides a unified all-in-one solution for Walmart Labs developers for development, 37 | unit testing, deployment CI/CD. The part that is open source from Electrode is collection of modules, 38 | web packs configs and scripts that developers can take and create their own React.Js apps. 39 | * Dan: Thanks for the high-level overview. Any technical questions? 40 | * Michael: That’s a really great success story. How do we make that happen more often? 41 | What are the things that the TSC can do on the community and foundation side, 42 | that would have helped you in this? 43 | * Joel: First thing: the talent pool to reach a critical mass. Next have someone passionate about Node.Js 44 | (Joel has a more then 15 years of Java script and embraced Node.Js from the beginning). 45 | Last but not least support from the executive team. Walmart had all these 3 together. 46 | * Michael: On the talent pool, one of the things that the community started to push forward 47 | is a initiative called Node.js people everywhere, the reason behind that is there are companies 48 | who want to get involved in Node.Js but they want to know that there are enough developers to hire. 49 | And there are people who want to work in Node.Js, but there is not necessarily a match between these two. 50 | These has been raised in Comm-Comm . Interested companies could provide a profile. Similarly, for developers. 51 | This will bring people together. Would be this of interest? 52 | * Joel: There is plenty of resources in Node.Js. 53 | (Joel wrote a blog saying that Node.Js is the number 1 developer platform, soon to exceed Java) 54 | * Walmart took a significant risk putting a large part of the infrastructure on Node.Js. 55 | This deployment is not just for Walmart Labs, it is for all Walmart.com. 56 | Walmart is such a large company, the largest employer in the US. 57 | * Beyond Walmart Labs there are other technology groups @Walmart using this infrastructure. 58 | * Tierney: Are they using Electrode as well? 59 | * Joel: Some of them are transitioning to Electrode others are building internal tools. 60 | Walmart itself has a gazillion of internal tools. There are teams using Java, Angular.Js 61 | and more and more want to migrate to Electrode. 62 | One of the first vison for Electrode was to provide shareable and reusable components. When Walmart.com 63 | was on Java we had a dozen teams building different parts of the website, building their own UI components. This was a problem for us to solve. When an internal team comes to ask for help with migrating to Electrode, we have to tell them that Electrode has 500+ React modules, all geared towards e-commerce. First characteristic of internal tools is they have to be plotting graphs. This is one challenge for internal teams. 64 | * Tierney: How can the Foundation help getting more developers move to Node? 65 | * Joel: What is already there is awesome. Motivation to developers is to build skills that are reusable. 66 | We picked Node.Js /React.Js because large companies like Google are investing big in it. 67 | Due to this from version 6 to 8 we are seeing 60% performance improvement. 68 | It’s about the community, bringing people together, spreading the word. 69 | I like the fact the core team is going out there and attracting more contributors, 70 | from 1500 last year to 1900, make people fill part of the community. In turn it will be easier for companies to hire. 71 | 72 | * Mark: Do you provide training internally or is there other place to get the expertise? 73 | * Joel: We mainly train in Javascript and Walmart Labs infrastructure/Electrode. 74 | We look for computer science graduates who already have the fundamental OS knowledge. 75 | * Dan: From the opposite direction where and why can I use Node today? 76 | * Joel: The hardest thing about Node for Java developers is that it is single-threaded. 77 | All the architecture designs evolve around the single-threaded of the JavaScript ecosystem. 78 | Some of the things we do with the CPU intensive stuff, we outsource to a separate process and use 79 | IPC and deal with them this way, allowing the Node.js process to continue servicing incoming requests. 80 | As we gain success with Node.js at Walmart Labs we got people from mid-tier service 81 | coming and asking to write their service in Node.js with Electrode. 82 | * I have to give them a mixed-response as it depends on the nature of their service. 83 | If the service needs to talk to a back-end database (like a Redis, Oracle) there can be challenges. 84 | * When people want to connect to OracleDB and they use the Oracle client they have to increase 85 | the libUV pool size from 4 to a larger number because when we say that Node is Asynchronous single-threaded, 86 | people misunderstand that. If you use any Async operation that involves that thread pool you are going 87 | to run into limits. Those are the kind of problems that we run into. 88 | * We have a lot of success in using Node as a web server in dealing with websites 89 | but as a Mid-Tier service we are still experimenting on that. 90 | * Dan: How do you do logging? What would you like to see more information about the ability to do logging today? 91 | * Joel: Logging…is my nightmare. We have this thing called “transaction logging”. 92 | When a request comes in, we log “Begin transaction”. This is not like a database transaction. 93 | Everything log from this point on, every log in between, should be enclosed within certain context. 94 | Because our web server acts as a proxy only. So, all the browser requests come into the web server 95 | which only fires an Async request to our back-end which is a database. 96 | If something happens in production we need to see the user transaction ID and everything 97 | that happened for this transaction ID, to trace all from starting the webserver to mid-tier 98 | servers to the database. This transaction logging is easier to do in Java than in Node.js. 99 | * We talked to Java developers and they said, “it’s important, we must have this”. 100 | And against my better judgement, we went for something called “continuous local storage”. 101 | * Tierney: What are you doing for monitoring? 102 | * Joel: We have internal a project called Medusa, using Apache Kafka back-end which allows us 103 | to send metrics to it and then collect them and plot them in graphics. 104 | For Electrode the internal part we use a metrics library, 105 | we collect events from the app and every minute we calculate a digest (hash) of this event and we send it to Kafka. 106 | * The way it works is that I have a separate Node process that does most of the legwork 107 | of collecting metrics and aggregating them and sending to Kafka. Every time some event happens, 108 | it is being sent to this app/process. This is the main part of the application performance monitoring framework. 109 | * Most of the app teams, when roll out a new build, they will look at this dashboard of metrics and graphs. 110 | The events we collect from the app: event loop latency, memory usage, CPU usage, 111 | no of incoming requests, time to respond, etc. 112 | 113 | * Question from the room for Shen: What is a hurdle or a challenge that you encountered? 114 | * Shen: I was working on a part that Joel referred to as Electrode archetype. I was working on an archetype that centralized manages all the configuration for the applications and the components. A challenge was the migration for the newer version, e.g. for React from 15 to 16. We see some issues and we need to apply those changes to each of the teams in Walmart. Plus, from Node6 to Node 8 there are some issues. 115 | * Dan: inside of Electrode you have Node, React, Webpack, what are the other major platforms? 116 | * Shen: We have Babel, Redux 117 | * Dan: which one is the hardest to migrate? 118 | * Shen&Joel: Webpack 119 | * Mihai: In terms of regressions, when you find a bug in Node.js, how do you go about reporting it? 120 | * Shen: We distinguish if it’s a Walmart internal issue or if it’s in Node. 121 | If we are sure it’s in Node, I will do a google research to see if people have 122 | similar questions and if they found a solution already. If I still cannot find anything, 123 | I will file an issue on the github and ask people who is the owner of that. 124 | * Mihai: Even if it’s a problem that someone else found and solved it, 125 | would still be good to report it to Node.js project to understand which version is affected. 126 | * Question from room: about continuous local storage. Have you tried async … as an alternative to that? 127 | * Joel: We ran into similar problems. 128 | That is the kind of feedback that we would like. 129 | It is still experimental but if it’s something where it’s not actually solving the problem 130 | would be good to know now because once it’s out of experimental it will be harder to change the APIs. 131 | * Dan: When do things fall off the visibility when you go through your locks? 132 | * Joel: As far as locks, other than the continuous local storage and transactions stuff, 133 | our locks are standard. 134 | We use Bunyan as transport and our locks go to Splunk. We use Bunyan to write our logs as JSON text onto file or disc. 135 | * Question from the room: For any performance issues, how do find out which part is affected? 136 | * Joel: We monitor a couple of basic metrics, like latency, incoming requests, the time it take 137 | to respond to incoming requests and we also log service calls. This is where the transaction 138 | comes in as you make a service call. 139 | * How do you act if it’s above the threshold? 140 | * Joel: to determine that it’s a problem with the SLA, when our site is continuously running, 141 | we always have a list of stacks that we know when we are operating in parameters. 142 | We continuously look at that day over day, hour over hour graphs. We plot our graphs continuously 143 | in our NOC (Network Operating Center), we look like NASA. Any time the graph shows what is the nominal 144 | value and you get called, at 3am. Everyone gets called, everyone gets together and tries to find what’s going on. 145 | * We try to figure out what is causing the graph to go up, which service is not performing well. 146 | Typically, more than half of the time the back-end is having an issue. 147 | Sometimes our cloud infra may have problems. And if we find anyone of those, we fix them. 148 | It is rare that it is caused by a bug in Node.js. Typically, it happens after a new deployment. 149 | * Dan: We’ve asked you a bunch of questions. Now turning the tables, do you have questions of the Node.js project? 150 | * Joel: Walmart Labs is using a lot of open source and is on Node.js for a few years. 151 | Is there a process that Walmart Lab can look into contributing back? 152 | * Tierney: Having people from the Node.js foundation or from larger companies, 153 | like IBM, who have done that may be helpful for us to get together as a group 154 | under the Comm-Comm and discuss. 155 | * Michael: from my perspective, that is a good idea because IBM is a big company 156 | and I've often helped people look across the projects and helped them figure out where to get started. 157 | * Tierney: there are a lot of companies contributing to Node, for example a lot of my time 158 | is dedicated to contributing to Node in addition to my work role. Having this as a resource 159 | for people is important. Doing something like “How I got into Node” series with companies 160 | who contribute a lot and sharing that would be another way to approach that. 161 | * Joel: We want to reciprocate and contribute back to Node. 162 | * Michael: Look at the strategic initiatives and see if there is an area that is of interest for you. 163 | * Joel: I am fairly up to date with what is happening in Node, like AsyncIO, HTTP2, 164 | and the continuous improvement with V8, what is one feature that is important to you. 165 | * Michael: Personally, I am working on N-API and I think that is exciting. 166 | Modules is one that’s going to be important. 167 | A lot of people who have interest but on the day-to-day people who are contributing code, 168 | I believe there is room for more involvement. Diagnostics would be my 3rd top. 169 | If you look at the summary that will come out from the Diagnostics summit, 170 | you will see there is a lot of work. 171 | * Tierney: for me Modules is going to be very important in the long run for us. 172 | One of my passions is in docs. So many things in our docs that can be improved. 173 | * Mark: Mine is not nearly as technical but is certification. 174 | There is such a demand for Node.js developer but there is no bar, other than asking 175 | Java questions code into their JavaScript code. If they went through and pass a certification 176 | it would make your hiring process much smoother. And it would make a lot of good developers 177 | to have credentials which will help them move to better and better jobs. 178 | * Dan: In the Node ecosystem we’ve become this proving ground for the JavaScript. 179 | A lot of standards work that happens. And the first environment 180 | where you get deep usage impact is in the Node platform. HTTP2 is embedded 181 | into the browser and you have the ability to use it on the client-side, 182 | data coming at you and the browser can optimize a few things for you. 183 | * With the introduction of HTTP2 we have for the first time in developer’s help 184 | a client for HTTP2 to do whether they need. Application developers will be able 185 | to do things with flow control and data as it’s coming across the stream. 186 | 187 | **Thanks to the Walmart Labs team for this great session.** 188 | 189 | -------------------------------------------------------------------------------- /meetings/2018-03-02.md: -------------------------------------------------------------------------------- 1 | ## 2018-03-02 User Feedback Team Meeting 2 | 3 | * Time Friday, 2018-03-02 at 17:00 UTC / noon ET / 11am CT / 9am PT 4 | ### Links 5 | * Minutes Doc: https://docs.google.com/document/d/1EHbxCOy-tlFAvVqO7r4n8Tu_4c6TnztfO1_dsjMrCRg/edit# 6 | * Previous Minutes Doc: https://docs.google.com/document/d/1RoPPTUxR9xtZ_3NS4Z5P8mXHZrKyGz3jwGPnD9hpjlA/edit# 7 | * Recording:https://www.youtube.com/watch?v=UwIk56lzytQ 8 | * https://github.com/nodejs/user-feedback/tree/master/data/2018-02-benchmarking-wg-survey 9 | ## Agenda 10 | * Extracted from neuf-agenda labelled issues and pull requests from the user-feedback repo prior to the meeting. 11 | * Intro / Attendance 12 | * Key Initiatives 13 | * 2017 Benchmarking WG Survey (ref: #22) 14 | * End User Feedback - Looking for Participants (ref: #20) 15 | * Enterprise Advisory Group (ref: #18) 16 | * Benchmarking WG Survey - landing data (ref: #22) 17 | * Diagnostics WG survey? 18 | * Node.js Tooling User Feedback 19 | * Closing Thoughts 20 | ### Invited 21 | * Dan Shaw (@dshaw - User Feedback Champion, CommComm observer) 22 | * Mike Hostetler (@mikehostetler - User Feedback member) 23 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback member) 24 | * William Kapke (@williamkapke - CommComm, User Feedback member) 25 | * Michael Dawson (@mhdawson, TSC Chair, CommComm, User Feedback member) 26 | * Tierney Cyren (@bnb - CommComm Co-Chair) 27 | * Greg Wallace (@gtewallace - Node.js Foundation) 28 | ### Present 29 | * Dan Shaw (@dshaw - User Feedback Champion, CommComm observer) 30 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback member) 31 | * Christopher Hiller (@boneskull IBM Developer Advocate) 32 | * Michael Dawson (@mhdawson, TSC Chair, CommComm, User Feedback member) 33 | * Tierney Cyren (@bnb - CommComm Co-Chair) 34 | * Greg Wallace (@gtewallace - Node.js Foundation) 35 | 36 | **Topic** 37 | * Thanks to Greg for sharing the survey data. 38 | * Thanks to Christopher to come with tooling initiative. 39 | * Dan Shaw: Intro- primary objective is to see if we can get to landing the data in github. 40 | We want to make the data that we collect for user feedback and for other workingroups 41 | inside the Node.Js project available for everyone to do some analysis to be able to evaluate 42 | trends and for decision making. 43 | * Greg Wallace: We used Survey Monkey which is good, is somewhere between Google forms 44 | and some really sophisticated software . 45 | We worked as a group to ensure that the way we were asking the questions would make 46 | the analysis of the results as easy as possible. 47 | Initially there were a lot of open-ended questions which have required us to read 48 | a sentence or a paragraph, we close those up. There was a list of options 49 | that the respondents can pick from. 50 | We cranked out a PDF report out of the Survey Monkey that basically have just those 51 | answers represented as bar charts. 52 | There were 4 or 5 questions left as open ended, Survey Monkey doesn’t know what to do with that data, 53 | but they have a built-in analyzers so for those ones it was created a PowerPoint 54 | It’s a simple way for viewing the data that summarize in a hopeful manner. 55 | * **Results xls&PDF [here](https://github.com/nodejs/user-feedback/tree/master/data/2018-02-benchmarking-wg-survey)** 56 | 57 | * From a summary perspective this combination between PDF and PowerPoint 58 | will provide a good level of visibility of the data. 59 | * For more analysys we have an Excel spreadsheet/data file and we’ve ensured 60 | there’s no PII (nothing that can be traced to any individual respondent), 61 | meaning we can put this on a public domain and there is no way for anybody 62 | to be identified right by the answers. 63 | The survey has 3 Outputs- the PDFs and the PowerPoint, the PDF has majority but for questions 64 | like where Survey Monkey does not visualize it we provide a summary swithing over PowerPoint 65 | * Tierney The PDF and Excel files will be available? 66 | * Greg Yes, all of it. For top level results PDF and PowerPoint and for more analysing Excel data files. 67 | There will be people who will take that and contribute in the insights that they produce back/that might 68 | be a task and the community might find interesting slicing and dicing the data. 69 | * Dan: What I like to propose, as kind of a point of process and as attempted to model how we take responsibility, 70 | how we allow the foundation to take responsibility of managing this data and responsibilities 71 | of certifying in a way we’ve prepared the data that is ready for public consumption would you 72 | try to initiate the PR here and just have a little bit of a data trail and some attribution? 73 | * Michael: We should agree where it should go in the repo; do we want a survey directory under user feedback, 74 | a directory which is the name for benchmarking survey 2017,2018 and then 3 documents under there? 75 | * Dan: A **[folder](https://github.com/nodejs/user-feedback/tree/master/data/2018-02-benchmarking-wg-survey)** 76 | was created to drop the data. 77 | * Mihai: How happy are we with the number of answers, under 300? 78 | * Tierney: I was hoping we would hit 100 goal,I’m very happy to get that high (around 290 answers) 79 | and I think definitely will hit higher in the future. 80 | * Michael: Greg told us that number is statistically significant. 81 | * Greg: There is a tool that I find on the web that will allow you to determine the confidence percentage 82 | that you can have based on the population size and sample size. 83 | * Dan: Chris has a major contribution to the open source ecosystem, he’s a maintainer for Mocha and will be 84 | wonderful a tooling builder to get together, collaborate with other tooling maintainers and developers and get 85 | some user feedback, so what I like to propose to allocate our next public meeting user feedback around tooling 86 | and invite some tooling folks, Chris, I know you reached some folks/another tooling providers, 87 | who else do you think potentially could join that session? 88 | * Christopher: Everybody I asked said is a good idea. 89 | * Michael: Is good to have a public call/ not self selecting the people? 90 | * Tierney: One of the goals is not just end users necessarily, but the mid user who is creating 91 | the tooling end users are using and also focusing on that mid user. 92 | * Michael: At some point we want to end up here are the different types of end users we have, 93 | like we have people to deploy node in production, people generating tools will be another type of user 94 | and if we form a group that go to around each of those. 95 | * Dan: Given what we need for call for participation, I propose to start by the end of March begin to invite folks 96 | to that sessions and allocate that as a public session. 97 | * Michael: We talked about Benchmarking diagnostic survey as are we going to do the next survey, 98 | we have to go back to diagnostic team and talk how to put together a survey. 99 | * Tierney: I’m wondering if the website group initiative would be interested in something as well, 100 | specifically how people use the Node.Js website? What are our users? How do we define them or whether 101 | the gals were trying to serve? To define if they have a specific kind of set of questions to go and reach out with. 102 | * Christopher: I was answering the survey and I did mention that I worked in online surveys for eight years 103 | (I’m not a marketer) but I have some knowledge, basically the things not to do, 104 | and I will be happy to look what we’re ready to send out and I might have some really good feedback 105 | there (eg: this question type is not what we want to use) , I would like to volunteer with that. 106 | * Michael:We want to capture some external reviewers, once we get a set of questions from a particular group, 107 | we’ll review them in these meetings. 108 | * Tierney: We need a section in Readme (in Comm-Comm we have 3 separate lists, one of the members, 109 | one of the individual members and one of the emeritus we can create the same structure, 110 | PR people and we will get more and more. I’ll do that and Christopher I’ll add your name. 111 | * Chris: Sure, add me as a reviewer. 112 | * Michael: We want to continue to ask for more participants, more tweets? Or more links? 113 | Standard explanation for user feedback: is like anybody who’s interested who use Node or not 114 | using Node.Js because they’re having problems we’re interested for anybody who will give us feedback on Node.Js. 115 | The Enterprise Advisory group is cast as a group of large enterprises who have large deployment of Node.js. 116 | If we have changes that will be the group that could go and say can you try these changes 117 | in advance and because they have large deployments they should be able to do that for us. 118 | We want to get a bunch of different constituents. 119 | * We should set up a meeting to sort these specifically. (send tweets, promote). 120 | * Action: Set up a meeting for sorting out Enterprise Advisory group to define, how to move forward 121 | 122 | **Next meeting and agenda: [2018-03-16](https://github.com/nodejs/user-feedback/issues/39)** 123 | 124 | 125 | -------------------------------------------------------------------------------- /meetings/2018-03-16.md: -------------------------------------------------------------------------------- 1 | # 2018-03-16 User Feedback Team Meeting 2 | 3 | ## Links 4 | 5 | * **Recording**: https://www.youtube.com/watch?v=wXqKXiWCtrg 6 | * **GitHub Issue:** https://github.com/nodejs/user-feedback/issues/28 7 | * **Previous Minutes:** https://docs.google.com/document/d/1EHbxCOy-tlFAvVqO7r4n8Tu_4c6TnztfO1_dsjMrCRg/edit#heading=h.iwg4uzfxnbok 8 | * [Delivery Channel](https://github.com/orgs/nodejs/teams/delivery-channels/members) 9 | * [Public meeting](https://github.com/nodejs/user-feedback/issues/38) 10 | 11 | ## Agenda 12 | * Extracted from neuf-agenda labelled issues and pull requests from the user-feedback repo prior to the meeting. 13 | * Intro / Attendance 14 | * Key Initiatives 15 | * TBD 16 | * Closing Thoughts 17 | ## Invited 18 | * Dan Shaw (@dshaw - User Feedback Champion, CommComm observer) 19 | * Mike Hostetler (@mikehostetler - User Feedback member) 20 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback member) 21 | * William Kapke (@williamkapke - CommComm, User Feedback member) 22 | * Michael Dawson (@mhdawson, TSC Chair, CommComm, User Feedback member) 23 | * Tierney Cyren (@bnb - CommComm Co-Chair) 24 | ## Present 25 | * Dan Shaw (@dshaw - User Feedback Champion, CommComm observer) 26 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback member) 27 | * Michael Dawson (@mhdawson, TSC Chair, CommComm, User Feedback member) 28 | * Tierney Cyren (@bnb - CommComm Co-Chair) 29 | * Chris Hiller(@boneskull.com) 30 | 31 | 32 | **TOPIC** 33 | ## Notes 34 | * Excellent brainstorm meeting. Thanks all for attending! 35 | * Dan Shaw: Intro, regular user feedback meeting. We want to prepare for tooling session. 36 | * Chris: the two people that I’ve worked so far are interested, not just a one-time deal, they want to work with user feedback group 37 | * Michael: We want to be as inclusive as we can, so anybody who shows up and self-select as representative of that group is 38 | welcome to come and participate. 39 | * Tierney: Is there a specific issue I can point people? 40 | * Michael: There is an issue that I tweeted out earlier in this repo. 41 | * Dan: Maybe Diagnostics may be interested to engage, who’s leading that effort? 42 | * Michael: I’m looking for the person who’s going to help pull it into core. I’ll take an action to figure out who can 43 | get on that side. 44 | * Chris: I’ll follow up with them to make sure they are available. 45 | * Dan: I’m interested in this session to bring a little bit more representation from TSC. The context is how does tooling, 46 | like we’ve seen with modules engage with the technical project in the long term. 47 | This is a dialogue opener and we don’t know the path.If we don’t have technical folks at the table then we should we go from there? 48 | * Michael: Maybe after we have the initial discussion and understand better we could go back and look who might be interested 49 | and ping them say if we can do on regular basis. 50 | * Dan: couple of individuals to sort of potentially reach out to invite, Myles as one of the leads of the modules WG and maybe someone 51 | like Jordan Harbor who’s one of the participants. 52 | * Michael: Chris how closely aligned you think the people working on modules are to the kind of tooling issues and stuff 53 | you were thinking, the sort of kind of things you want to address by this bringing this group together? 54 | * Chris: I’m not familiar with submodules group. 55 | * Michael: they’re focused on ES6 support in Node (Tierney: specifically, around the modules implementation), 56 | how that ES6 support will be implemented. I guess the interaction could be, is that some of that may affect what 57 | some tooling can do and what some modules built on top can do. How do you test ES6 modules that might affect Mocha? 58 | * Chris: There’s some overlap, but I wouldn’t say necessarily any more overlap that any other. 59 | * Michael: Unless you think that’s a good fit I think we might want to be a bit cautious on. I’d like Chris to bring the group 60 | that he was thinking of together plus whoever else selects as being like in the tooling area and see what the concerns are, 61 | and then figure out who to bring as opposed to trying to pre-figure that out. 62 | * Tierney: The thing I’d be most concerned about with pre-figuring that out is optimizing for the people who have already given feedback pretty extensively, like Myles and Jordan (involved in the project for quite a while), and I just be concerned that continuing to build like an echo chamber kind to ourselves and the feedback that we’ve already gotten, I’m elevating those voices over something with people who at least I’ve considered I had conversations with say feel like we’re kind of very much in echo chamber in a very exclusive environment, it’s hard to break into so I think we really to optimize for the ecosystem tooling people who haven’t really interacted with the node project. 63 | * Michael: I’ll like to have people come in tell us, what they’re thinking help us understand a bit better concerns 64 | and where they might want see things going and from that we can figure out who else to try and pull in. 65 | * Tierney: I already reached out to a few people, I’ll point people in that direction. 66 | * Dan: My concern is: we are creating space for this discussion and then where is it go? Is not clear if is Comm-Comm, 67 | user feedback is not an incubation space for initiatives… 68 | * Michael: I don’t think it need to go anywhere, our focus is to keep regular contacts with these groups and then once the contacts 69 | takes place, if there’s concrete actions that need to happen out of those, like for example here’s a real pain point, 70 | our actions to figure out how to pull in the other people who can discuss that specific pain point have 71 | a specific meanings around that. The alternative is to spin up a team or strategic initiative, 72 | I could see that is useful in some cases, but I think it’s equally perfectly reasonable if every 3 months we the group together. 73 | It doesn’t have to graduate into something else,I think working groups to have like a close relationship 74 | too core. 75 | * Chris: We have these user feedback session an maybe an intuitive coming out, well there needs to be some sort of champion in core 76 | to get much of anything done, I think we should be going(this is not going to happen overnight ) is that we need more people 77 | who come from this world basically just involved in core and so if eventually that would form a group great, 78 | but I do fear if we get a bunch of feedback and it’s clear there’s some actionable items whose really suitable to be a champion there. 79 | I’m sure it’s somebody on working groups that works more with command-line tools and others maybe a good person to reach out, 80 | I’m trying to get more involved in core myself. I’m sure there will be some things that come out of this. 81 | * Michael: I agree 100% with theory that group needs to get more involved, because it’s not going 82 | to be like “here’s a bunch of requirements, somebody else goes off and does it”; 83 | but I can easily say it’s like: “here it’s a bunch of things we’d like to see happen and we’re willing to invest some time in core 84 | to make it happen but we’re not as plugged in so we need some help and that some other people say, yeah we’ll support you doing that”. The first step is just coming to an understanding what those might be and what they look like and how much work they take, and once, if this group comes up with : well here’s the document now everybody understands it better that’s the next step for figuring out how you might actually make it happen. 85 | * Chris: Part of the reason that I thought I’m going to propose this idea was that myself and some others who come from this world 86 | have kind of felt like when they proposed an idea to core it’s received as something completely out of left field and 87 | that sort of make sense if the people in core mainly aren’t working in that world, so it’s my hope that we can kind of bridge 88 | the gap and come to a better understanding of each other needs. 89 | * Michael: If we can use this to bridge the gap, better understands each other and figure out how to work together on the things 90 | that are important. If you just open the PR and there’s no context and no discussion it’s easy for that just not to go the right way; 91 | if you had a discussion beforehand, we’ve identified some people who are interested in the area, 92 | there’s already been a discussion then you open a PR and immediately some people can sort of jump in saying “this is a good idea”. 93 | We get together we hahe this discussion, if you get to the point where there’s enough people in the tooling committee, 94 | like actively working, then easily see it forming an internal WG or something like that. 95 | * Dan: We identified Myles as being the echo chamber who else could be a good fit? 96 | * Michael: I’m happy to say this is going to be, anybody else interested come along. I certainly don’t want to say to anybody don’t come. 97 | just in terms of actively going to find additional attendees, for me would be better to understand a bit more what 98 | the interest is and what kind of discussion are gonna have happen, because that’ll help me figure out who the right people are. 99 | * Tierney: I don’t think we should exclude people who have been participating in this kind of discussion in the best, 100 | I just want to make sure we’re not only including them, like they’re not our central people that we’re having in this discussion 101 | and that we’re actually going and getting people that are users that haven’t participated in addition to those people 102 | who have already participate it to these discussions. 103 | * Dan: What about Comm-Comm? Outside of this group are their perspectives, internationalization? 104 | * Michael: If will be the case like supporting multiple languages then, probably we will have somebody. 105 | * Tierney: I know the electron folks that are involved, I can ping few of them and see if they’re interested in coming. 106 | * Michael: We created a team called delivery channel, group who take node and either bundle it into their product and deliver 107 | it that way or they repackage some of the installers, or they help you install, so that team whenever we do something 108 | around that we notify them an electrons part of that, that will be another end-user group. At some point we want to reach out 109 | to them as a group and say should we have user feedback session with them, to hear what’s going on and make sure 110 | that isn’t same thing where there they’re in echo chamber that we’re not hearing, just sort of bring the groups closer together. 111 | Chris do you have example of other modules that you’re getting people to come in for? 112 | * Chris: Webpack and npm, maybe typescript. 113 | * Tierney: I reached out someone from Babel. 114 | * Michael: That’ll be quite interesting to hear what the overlap is in terms of concern and what concerns are? Feedback from that group 115 | in terms of the things we’re doing. 116 | * Dan: There is an Node issue 19079 which is runtime deprecation of buffer constructor, I’m wondering if that particular issue, 117 | particular concept, it’s too deep in specific? 118 | * Michael: I would leave it to the end; my suggestions: everybody introduce themselves and then give it a sort of open-floor 119 | to Chris and the rest of the people to kind of say well what are kind of things you’d like to talk about and then at the end 120 | we can say one thing we know from Node community side that we are interested in feedback on is that particular one; 121 | we’ve taken a decision it will affect module owners in general, but we can get feedback from this particular group. 122 | Chris does this sound reasonable? 123 | * Chris: I was thinking going back to the few people reached out to and say do you want to bounce a few ideas around, 124 | these are main challenges, and this is kind of what we want to talk about. 125 | Do you have any specific questions that you want to ask? On the buffer thing I don’t feel like is any important than anything else 126 | necessarily. 127 | * Michael: We could come up with some generic questions: if the project makes your life more difficult; LTS release cycle help/hurt 128 | the releases that you need to support; any PII for people who have native modules. Are there any pain points that we should be aware, 129 | so we have enough knowledge to understand how we might affect that end user group and be aware? 130 | * Chris: …Node Sass 131 | * Tierney: I’d like to ask if after we’re done here we’re not crossing streams because we’re talking about similar groups of people 132 | to reach out to, so I just want to make sure I’m not creating extra turn on inviting people in. 133 | * Michael: The other thing would be like are there things that you think the project or even the foundation because we can be a channel 134 | into the foundation as well should be doing to support modules and tooling in a way that isn’t being done today. 135 | We could write some of those down in the agenda if we want. If you come with a set that they want to discuss that will give us some 136 | more concrete things to talk about in the meeting. How often to get together? Are there burning issues or not? 137 | (Capturing the high level ones as a way to figure it out what next steps might be on) 138 | * Chris: Would be helpful to have maybe somebody who is involved with modules. 139 | * Dan: Do you think would be constructive to have a broad sort of opener with tooling folks just to get a baseline, 140 | describe how your tolling leverages Node.Js, but not sure how will be its context in the broader group? 141 | * Michael: It’s kind of hard to understand each other if we don’t understand what the modules doing. Some of them like probably 142 | NPM we understand well, but others may not be as obvious to people what the relationship is an innovation dependence, 143 | all that kind of stuff. 144 | * Dan: there is npm a new tooling that npm is building like npx. 145 | * Michael: Every meeting maybe could benefit from a what’s new in terms of our other modules planning something new that they think 146 | might affect Node and vice-versa; NPM is introducing something new, hearing about that upfront and it won’t just be the people 147 | in the meeting it’s whoever else wants to watch the meeting afterwards and there’s something particularly interesting that comes 148 | out of that that we point the people to the recording to go listen; it’s another way to sort of bring the two way communication. 149 | * Chris:another questions is why do you use Node.Js to write your tools? Traditionally Javascript has not been a scripting language, 150 | people are gonna reach for Python or else, why using javascript and node when you could have this with a shell script. 151 | * Tierney: It will be probably helpful, should we reached out to Chris, Borchers from Node.Js foundation. 152 | * Dan: I’m taking notes on [issue#38](https://github.com/nodejs/user-feedback/issues/38) as relates to agenda topics. 153 | 154 | * **Enterprise Advisory group: one month from now.** 155 | * **Chris is reaching out to people to attend the meeting next week.** 156 | 157 | 158 | **Closing Thoughts** 159 | - 160 | 161 | ## Upcoming Meetings 162 | * The next meeting is scheduled for Friday, 2018-03-30 at 17:00 UTC / noon ET / 11am CT / 9am PT. 163 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 164 | - Click `+GoogleCalendar` at the bottom right to add to your own calendar. 165 | -------------------------------------------------------------------------------- /meetings/2018-03-30.md: -------------------------------------------------------------------------------- 1 | # 2018-03-30 Public User Feedback Meeting - Node.js Tooling 2 | 3 | ## Links 4 | 5 | * **Recording**: https://www.youtube.com/watch?v=g5efRv1Wat0 6 | * **GitHub Issue:** https://github.com/nodejs/user-feedback/issues/45 7 | * **Previous Minutes:** https://docs.google.com/document/d/1NXH7qzaLGJcgNaswAcHVfwqluwaZPjp7iXtyRa4JZZA/edit 8 | * https://github.com/orgs/nodejs/teams/user-feedback/members 9 | * Issue [#45](https://github.com/nodejs/user-feedback/issues/45) in User feedback repo 10 | * [2 files](https://gist.github.com/bnb/ff9d8e95876737f88f8874e36169df6b) captured in Gist-by Tierney 11 | 12 | ## Agenda 13 | Extracted from neuf-agenda labelled issues and pull requests from the user-feedback repo prior to the meeting. 14 | * Introduction to the Node.js Tooling with @boneskull 15 | * Topics (ref: #38): 16 | - Describe how your Tooling leverages Node.js. 17 | - Why do you use Node.js for Tooling? 18 | - What's working in the Node.js tooling ecosystem? 19 | - What isn't working in the Node.js tooling ecosystem? 20 | - What's new that could impact Node.js? 21 | * Open feedback forum 22 | * Present 23 | * Dan Shaw (@dshaw - User Feedback Champion, Mentorship, CommComm) 24 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback) 25 | * Michael Dawson (@mhdawson - User Feedback, CommComm, TSC Chair) 26 | * Tierney Cyren (@bnb - User Feedback, CommComm Chair) 27 | * Chris Hiller(@boneskull.com) 28 | * Rebecca Turner (@iarna) 29 | * Gleb Bahmutov (@bahmutov - Cypress.io) 30 | * Uttam Pawar (@uttampawar - Intel) 31 | * Ben Newman (@benjamn - Meteor) 32 | * Kent C. Dodds (@kentcdodds - PayPal) 33 | * Sean Larkin 34 | * John David-Dalton (@jdalton) 35 | * Gus Caplan (@devsnek) 36 | * Kelly Selden (@kellyselden - @ember-cli) 37 | 38 | **TOPIC** 39 | ## Notes 40 | **Thank you all for participating.** 41 | * Introduction to the Node.js Tooling with @boneskull 42 | * Developers of tooling have different needs from those active in core, for example user 43 | experience may be more important than performance. 44 | * Good to have more discussion/connection so that we can keep the needs of tooling 45 | developers in mind. 46 | * Topics (ref: #38): 47 | - Describe how your Tooling leverages Node.js. 48 | * Rebecca 49 | * npm perspective are that most users are tooling users as opposed to server users. 50 | * most command line tooling writing in Node.js (previously perl) as it is most familiar. 51 | * Kent 52 | * Almost all tooling is in node and used to build websites 53 | * Also tooling to build/deploy up web servers (Java used to package manifests) 54 | * As Rebecca mentioned, even though may not be ideal scripting language, we like node because everyone can contribute easily. 55 | * Also use for servers and deploying servers. 56 | * Dan, used to build legacy Java?, Kent not as far as I’m aware. But Java is used to package build archives of node services. 57 | * Gleb 58 | * Everything they do now runs on node, all shell js, don’t want to install anything else 59 | * Biggest challenge is slight differences in how child process/streams across platforms (ex linux, 60 | windows etc) 61 | 62 | * Uttam (Intel) 63 | * don’t have tooling leveraging Node.js. Focus on performance for node.js. Have Vtune tool for 64 | Performance measurement 65 | * Contributed node-dc-eis which uses a number of the tooling 66 | * What is the hook from VTune to Node.js. There is support in V8 and that is the link. Run 67 | Vtune from command line and it captures hardware data and gives micr 68 | * Ben (Meteor) 69 | * Fully embrace npm even though they have their own package system 70 | * They ship a specific version of Node.js in each release 71 | * Very nice as they don’t have to test a matrix of versions. Also means that they can ship 72 | new Node.js versions and count on them being there with the new features. 73 | * Michael what version do you use? Ben on 0.10.X way to long, then jumped to version 4.X, latest 74 | Version jumped to Node 8.x, plan to keep up to date. 75 | * Tierney, what is transition path, what have the blockers beein. Ben, despite 76 | moving in large jumps has been relatively smooth. Have not had to hold too 77 | many peoples hands for upgrades either. 78 | * Dan, do Meteor users consider themselves Node.js users? Ben -> yes. Expectation is that they 79 | can drop large portion of Node app into Meteor. 80 | 81 | 82 | 83 | - Why do you use Node.js for Tooling? 84 | * Christopher (Moca) 85 | * Testing framework for JavaScript. Node.js launcher for testing Node.js, can also be used in the 86 | Browser. 87 | * John David Dalton (lodash) 88 | * used node and node more and more over time to generate various builds of Node.js 89 | * also works on module loader which is all node, adds es syntax to Node.js 90 | * Kelly Selden (work on ember CLI) 91 | * build tool for ember projects 92 | * They have an LTS system which is tied to the Node.js LTS versions. Try to avoid transpiler so 93 | end up writing code for older versions for which a while. 94 | * Community is interested in whole monorepo 95 | * Ember.js runtime (6 or 8 week lifetime), build current release supports LTS releases. They 96 | support the LTS versions as opposed to having LTS for their modules. 97 | * Gus Caplan (from node modules group, participating to see what the module owners are doing) 98 | - What's working in the Node.js tooling ecosystem? 99 | - What isn't working in the Node.js tooling ecosystem? 100 | - What's new that could impact Node.js? 101 | * Open feedback forum 102 | * What is not working 103 | * John David Dalton 104 | * Try to work across different versions(6 and 8). Need to juggle when 105 | new APIs are added to newer versions 106 | * Some handy features which are not public, but if you ask 107 | tendency is to try to remove/lock down so hesitant to ask. 108 | * Attitude in node core that userland is less than. Sometimes 109 | will see userland option as not viable. 110 | * ex Node fetch, Node should be more open to pulling in 111 | external packages (bundle more as opposed to integrate) 112 | 113 | * Rebecca (npm) 114 | * libuv does a relatively good job of hiding platforms, except 115 | for error codes where it just forwards on OS error. You don’t 116 | even have doc on what error codes you might get. 117 | * Historically have had some stdio juggling, but that is solid 118 | now 119 | * Tierney Question for everybody 120 | * please respond in the issue -> What would you like out of this 121 | Meeting 122 | * Kelly - no additional issues beyond what was mentioned earlier 123 | * Chris(Moca) - frustrations from technical standpoint are cross 124 | platform issues (for example fs.watch). Why are there things 125 | like cross-env, graceful-fs. Cross platform gotcha’s. Much more 126 | Of a problem for tooling/tooling modules as they tend to run 127 | across more platforms. Deployment is more likely just linux 128 | * Kent - concur that biggest problem are cross-platform issues. If 129 | we could make it so fs-extra,rimraf etc does not need to exist. 130 | Good thing that they do exist though as it makes things much 131 | easier than it used to be and 132 | * debugging could still use more work. Inspector is good, what 133 | is needed is education story as well as people understanding 134 | That node-modules just contains a bunch of JavaScript. 135 | * Gleb - linux - terminal support and progress bars are a problem 136 | for them. Would like to see better support in node core. We already used wrappers around progress bars, but there is great amount of how it works and how it looks like from Windows to Linux (docker). 137 | 138 | * Ben - v8 has intimate relationship with Node.js. Source of 139 | bugs is backporting process for bringing changes into Node.js 140 | Segmentation faults due to partial gc backport. Wonders if 141 | Node.js being more up to date with v8 versions would help. They 142 | use fibers which. The one thing that keeps him up at night 143 | is what they have to do in order to support threading. Dan 144 | suggestion to look at N-API and share what you still need that 145 | is not there. 146 | 147 | **Closing Thoughts** 148 | 149 | * potential topics for later session. 150 | * How to handle LTS for modules and relationship 151 | to Node.js LTS cycles. 152 | * Benchmarking to provide coverage for tooling concerns, does this 153 | Matter? 154 | 155 | 156 | ## Upcoming Meetings 157 | * The next meeting is scheduled for Friday, 2018-04-13 at 17:00 UTC / noon ET / 11am CT / 9am PT. 158 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 159 | - Click `+GoogleCalendar` at the bottom right to add to your own calendar. 160 | -------------------------------------------------------------------------------- /meetings/2018-04-13.md: -------------------------------------------------------------------------------- 1 | ## 2018-04-13 User Feedback Team Meeting 2 | 3 | ## Time 4 | Friday, 2018-04-13 at 17:00 UTC / noon ET / 11am CT / 9am PT 5 | ## Links 6 | * Minutes Doc: https://docs.google.com/document/d/1909UvdMuMJqFb0ONmbCGGjEcyfdpx8Vx7g-L9Aedq4Y/edit#heading=h.1j34aho53zzc 7 | * Previous Minutes Doc: https://github.com/nodejs/user-feedback/blob/master/meetings/2018-03-30.md (public session) 8 | * **Recording:** https://www.youtube.com/watch?v=cdRfgNs313Q&t=46s 9 | * Issue [#46](https://github.com/nodejs/user-feedback/issues/46) in User Feedback repo 10 | * **Calling for next meeting:** [Public Enterprise Use Case](https://github.com/nodejs/user-feedback/issues/52) 11 | * **Capture the public user process** [#53](https://github.com/nodejs/user-feedback/issues/53) 12 | 13 | ## Agenda 14 | * Extracted from neuf-agenda labelled issues and pull requests from the user-feedback repo prior to the meeting. 15 | * Intro / Attendance 16 | * Plan Enterprise User Feedback session 17 | * Decide on next steps for Enterprise Advisory Group (ref: #18) 18 | * TBD 19 | * Closing Thoughts 20 | 21 | ## Invited 22 | * Dan Shaw (@dshaw - User Feedback Champion, Mentorship Member, CommComm Member) 23 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback Member) 24 | * Michael Dawson (@mhdawson, TSC Chair, CommComm, User Feedback Member) 25 | * Tierney Cyren (@bnb - CommComm Chair, User Feedback Member) 26 | * Christopher Hiller (@boneskull - Mocha Maintainer, User Feedback Reviewer) 27 | * Mike Hostetler (@mikehostetler - User Feedback) 28 | * William Kapke (@williamkapke - Individual Membership Director, CommComm, User Feedback) 29 | * Shawn Preissner (@shawnpreissner - Node.js Foundation / Linux Foundation) 30 | ## Present 31 | * Dan Shaw (@dshaw - User Feedback Champion, Mentorship Member, CommComm Member) 32 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback Member) 33 | * Michael Dawson (@mhdawson, TSC Chair, CommComm, User Feedback Member) 34 | * Tierney Cyren (@bnb - CommComm Chair, User Feedback Member) 35 | * Christopher Hiller (@boneskull - Mocha Maintainer, User Feedback Reviewer) 36 | 37 | ## Notes: 38 | * Got the next 50 meetings until Feb 2020 into Zoom. Thank you, Tierney. 39 | * Intro by Dan Shaw: enterprise users: we are scheduled to have a public feedback forum. 40 | * Tierney: Is this going to be a user feedback initiative or enterprise advisory thing? 41 | * Dan: My intention is to invite everybody in the enterprise advisory group to participate in an end-user session. 42 | The reason being is this model is working (user feedback initiative), and enterprise advisory group hasn’t had the 43 | name of championing and the right forum. 44 | * Michael: I think it clarifies our story too, if we have the user feedback program and a number of different groups 45 | under the same program, it’s easier to explain to other people what’s going on. The core user feedback team doesn’t 46 | always have to facilitate and enable the groups where we’re getting feedback; I could still see those teams, 47 | the tooling group is a good example, if they form their own group and direction, in fact they have somebody who’s leading 48 | they form a different group, they’ll become self-sustaining if we’re successful. 49 | * Tierney: I see as a successful approach for multiple type of groups. I would like to ask how we go about 50 | enterprise advisory working group repo and the proposal from there? 51 | * Michael: I think that shouldn’t be one of the goals of this upcoming meeting is to say does that just get closed because 52 | it’s replaced with this effort or not. Does it make sense Dan? 53 | * Dan: It does, this leads to potentially our first private session item – we may want to ask folks that are attending 54 | in the enterprise advisory group to stay on for another half an hour or so to drive this to a decision/build consensus? 55 | * Mihai: Because we landed here we need to be aware of the time. As organizers from the beginning, if the people in 56 | the meeting are more than 10, we need to tell the people we need an extension of the meeting. 57 | * Dan: I’ve have a proposal to try to keep our discussion questions that we go through as limited as possible. 58 | We got feedback in our last session where they’re happy about the session, but they were frustrated that we didn’t get 59 | all of the topics, so one way to solve that is to aggressively reduce the topics. 60 | * Tierney: Timeboxing and having people let themselves rather than going through everyone, it’s probably a good way to do that. 61 | Just because having self-selection, people might be more have more to say on one thing/one specific topic than another 62 | and those we want definitely make sure we’re hearing the people have something that they really want to passionately, 63 | or a little bit of comment … like people feel obligated to say something, when we’re going to everyone. 64 | My impression several people felt obligated to have some statement and they didn’t necessarily have one 65 | that they were passionate about, but they felt obligated to fill that time. 66 | My concern is making sure we cover all the subjects and making sure we get the people and hear everyone’s opinions 67 | on the things they’re passionate about the things they care about most. 68 | * Dan: The counterpoint to that journey is you often will get the most aggressive voices and my worry is folks may not 69 | be familiar, we’ve raising hands we got a couple of things that we could model; we need to hear the under heard 70 | voices that you’ll really kick off some of the most interesting discussions. 71 | * Tierney: Having a big group there are a lot of people of strong opinions and if it’s a very technical issue and the way 72 | Miles has been driving is through the raised hand functionality and seem to be effective because it allow people to kind 73 | of raise hand while passively and they can choose whether they want to speak or not when they’re selected the hard part 74 | seems to be moderating it mediating it rather and making sure you’re hitting all. 75 | * Michael: If we don’t have actual enough time to hear from everybody we’re not going to hear from some people so we could 76 | ask people to raise hands and if that works out, great, if it doesn’t it’s reasonable for Dan to try and pull out 77 | some of the people who aren’t talking, the flipside might be we just don’t plan to go through everybody so for one you 78 | pull out a few people and on the next question you fill out you pull out a few of the other people who haven’t talked. 79 | * Dan: How do folks feel about me combining that everybody introduced themselves together with “you describe your use case”? 80 | only one time 81 | * Michael: It makes sense, the use case is part of the context of while they’re participating. 82 | * Tierney: I think this is something like we should codify into a document even if it’s just a few bullet points like 83 | start as bare-bones minimal as possible just to have this down something as we can point to I can probably pull this together 84 | from Mihai’s notes , but codifying something into document so we can have this as a reference, 85 | for the next one and the future group. 86 | * Mihai: Sound like we need to update the readme file then. 87 | * Tierney: Have a different file and we can link it from Readme 88 | * Michael: I figure it should be in a different document somewhere under docs I the repo. 89 | * Dan: Plus, one, agree. We can link off our readme for folks that are interested in the workings. 90 | One thing we haven’t done yet in any of our sessions is sort of communicate back having some Comm-Comm or TSC messaging, 91 | there is an interesting opportunity and something that this group could be interesting in hearing if we think we can 92 | fit in terms of time, the work of Diagnostics WG in the diagnostic summit and the prioritization of those efforts are points 93 | of interest for enterprise users, do we want to fit in some feedback back out into the session or should we reserve t 94 | hat for a subsequent follow-up? 95 | * Michael: I’d love to get that feedback, I don’t know if it’ll fit in. By the time you go around by the table with 96 | the first part you’re already going to ask people that stick around afterwards as well; I think what we need to do we’ve got 97 | to start scheduling the next meetings for each of these groups so I could say “ok, maybe we don’t have enough time in 98 | this first one but let’s schedule the next one 3-4 weeks out and that’s the focus of that one. 99 | We’ve met what are the concrete actions and I think having gotten through the first meeting where they’re sort of 100 | getting to know each other, the second one would be “what do we want to try and accomplish, let’s make some concrete things”, 101 | and in the enterprise one of the suggestions could be well let’s look at the diagnostic side and we believe that’s something 102 | important to the enterprise use case, we would like to validate that, get some feedback. 103 | * Dan: One of the outputs should be: when we could potentially reconvene that group. Calling for participating https://github.com/nodejs/user-feedback/issues/52 , I’m generally inclined to not limit numbers just to make 104 | the invite as broad as possible and adapt from there. 105 | * Dan: Tooling and general User feedback. 106 | * Michael: We had a great first meeting (tooling) and what is the most important thing to move forward on and we can 107 | identify a couple together and then try and assign actions to different people to take the next steps are? 108 | * Tierney: Those next steps are good way for us to prioritize what other working groups and teams need to get involved? 109 | Like Diagnostics important to the enterprise or modules. 110 | * Dan: How do we keep that context over months, unless we go to a more frequent schedule, do we need to begin to capture 111 | some of those interest areas for these groups into document where we’re keeping a public record and beginning to navigate 112 | some of those key points? 113 | * Michael: Good idea, if we can make a concrete enough that says here is an issue which is like these are the 114 | next actions or next important things for this group. Something outside the issue for the meeting starts build for each group 115 | a set of one or more issues that are here the things that we’re trying to push forward. 116 | * Tierney: We had a tool a running minutes talk, where every week we would just add more things to it so it effectively be like 117 | a living log. 118 | * Dan: An ongoing log where we over captured what questions we got, what actions we came out of and followed the log and what 119 | we wanted next. That would go a long way not only facilitating what we’re playing in the future but being good record 120 | of what we’ve accomplished-currently lives in issues and minutes but doesn’t have a real path to living history. 121 | * Tierney: I think we could do that in a directory in the repo, have something we can point people to. 122 | * Michael: Have like a groups directory and have an entry for each of the groups. 123 | * Tierney: Having a naming structure like tooling log. Md file enterprise log.md file, a description on top and link 124 | from Readme.md 125 | * Michael: wiki features in github repo so we can potentially use? 126 | * Dan: In terms of permanence and editing empowering a markdown file is probably the most permanent, most accessible thing 127 | that I can think of (issue#53 https://github.com/nodejs/user-feedback/issues/53) 128 | * Tooling: Michael: We should have a tooling session after enterprise ,general meet (May 11)and then tooling meeting (May 25) 129 | * Distribution: Michael: Distributions is broader than what I was trying to form this group, I’ve been working 130 | with @yhwang on support for shared libraries within node and I feel that being able to embed node into your applications 131 | is an important use case, people like Electron we’re getting to the point where we’ll have that in the CIS at least to 132 | a limit extent where is just testing like the core node tests and the next major thing is to really start testing the 133 | use cases where you’ve done the embedding and they’re a little bit different because you want those that core 134 | functionality to work but there’s also tests there’s also use cases that are specific to having embedded it 135 | how to start scripts, how do you communicate between the rest of your application and the node runtime. 136 | It will be great if we get some people interested and involved in defining what those use cases are. 137 | So what I’m hoping is find interest in a group of people who or who want to come together to sort of document 138 | those use cases and use that to drive requirements. 139 | * Chris: Create issue/PR regarding second tooling session (Dan will help) 140 | 141 | ## Upcoming Meetings 142 | * The next meeting is scheduled for Friday, 2018-04-27 at 17:00 UTC / noon ET / 11am CT / 9am PT. 143 | * Node.js Foundation Calendar: https://nodejs.org/calendar 144 | * Click +GoogleCalendar at the bottom right to add to your own calendar. 145 | 146 | 147 | -------------------------------------------------------------------------------- /meetings/2018-05-11.md: -------------------------------------------------------------------------------- 1 | ## 2018-05-11 User Feedback Team Meeting 2 | ## Links 3 | 4 | * **Recording**: https://www.youtube.com/watch?v=eiN0gnAJNeU&t=10s 5 | * **GitHub Issue**: https://github.com/nodejs/user-feedback/issues/58 6 | * **Minutes Google Doc**: https://docs.google.com/document/d/1kswsnzh5ziblp3mcrKS8S3_UPGo7EK5MLybIoDCqxDM/ 7 | * **Survey for typing** issue [#61](https://github.com/nodejs/user-feedback/issues/61) 8 | * Next meeting: issue [#64](https://github.com/nodejs/user-feedback/issues/64) 9 | 10 | ## Present 11 | 12 | * Tierney Cyren (@bnb) 13 | * Michael Dawson (@mhdawson) 14 | * Dan Shaw (@dshaw) 15 | * Aaron Bartell 16 | * Agiri Abraham 17 | * Nikolay Matvienko (@nmatvienjko) 18 | * Aaron Heckmann (@aheckmann) 19 | 20 | 21 | ## Agenda 22 | 23 | ## Announcements 24 | 25 | *Extracted from **neuf-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. 26 | 27 | ### nodejs/user-feedback 28 | 29 | * Public User Feedback request - European General User Feedback at WorkerConf [#56](https://github.com/nodejs/user-feedback/issues/56) 30 | * Invite Node.js tooling ecosystem folks to discuss user feedback [#37](https://github.com/nodejs/user-feedback/issues/37) 31 | 32 | # Discussions 33 | * Gathering use cases to help technical discussions in threading 34 | * Building an educational discussion around folks who wants to get started 35 | * Survey on typescript 36 | 37 | * **Intro by Dan Shaw** 38 | * Aaron entered a set of topics for discussion. 39 | * **Thanks Aaron Bartell, Aaron Heckmann, Nikolay Matvienko for participating!** 40 | * Aaron Bartell: the challenge that we have and it’s on github issue is that IBM i, is traditionally used by a lot of 41 | insurance companies, auto manufactures, banks-medium to large companies that are looking what’s my modernization path, 42 | they are reviewing Node.Js, but are struggling through all the things that they’re reading online, so here’s is the big issue. 43 | Some of them were true in time, some are no longer true, some are still true, so it’s just trying to find a more exhaustive 44 | and authoritative series of articles, that I can point them at, so what to bring up probably the threading and the typing 45 | some of the biggest ones. 46 | * Dan: Threading: that is a discussion, in general, we’ve had around node, interesting phenomenon happening where rather 47 | than getting bigger our computing environments are often getting smaller; there is this competing force where so much of 48 | the growth that we experienced when Moore’s Law was exponentiating, but unfortunately power has constrained that and how 49 | we scale things has shifted from monolithic applications to orchestrated applications; so in those orchestrated applications 50 | we now have frequently thin pods of execution environment that are being scheduled and orchestrated as a part of 51 | a larger reality, so if you look at the sort of macro technology changes that have happened around Node, many of the 52 | operating environments have been optimized down to single threaded event model as being the more efficient way to compute 53 | in today’s operating environment, so my best answer for why Node, in this new operating context, is has nothing to do with Node, 54 | it just the world is moving around us into a model that really optimizes for Node.Js and it’s a better fit for the kinds 55 | of applications that were writing today, scaling single monoliths has been proven by many companies to be incompatible 56 | with the development life cycles they need delivering on today.. 57 | * Aaron B: So you say that changing your authoring and deployment strategies is probably the biggest thing? So if somebody’s 58 | coming from a Java servlet container background, it’s changing that concept and moving to a new one that’s microservices, 59 | are you leaning more towards that way or are you talking just modularizing your business? 60 | * Dan: Modularizing, yes, and I’m not the only voice chiming on this, but I do think that the pattern that I’ve seen over 61 | the past decade for successful software development, has shifted from we're gonna spend a bunch of time trying to figure it 62 | out the right way to we’re gonna put something into production as fast as we can so we can validate it in front of 63 | our end-users, and that just changes the way you want to deploy and therefore you’re forced to consider new strategies 64 | and that’s why I see things like serverless being a great first step for companies that are looking how they evolve 65 | their technology story, so you can just set up a function and route to it and explore new functionality that way and 66 | farm away from some of the your back-end services while evolving your practices. Aaron Heckmann is one of 67 | the infrastructure leads at PayPal and they’ve gone through this journey so I started collaborating with them back in 2013, 68 | and they went through a C++ to Java journey, and then...kind of tipping point for PayPal was at this moment where 69 | they were trying to make a single line of text change in their deployment and it took eight months for that to flow through 70 | to production so the front-end team was like:”this has got to change because we can’t deliver the front-end experiences that 71 | we need with that sort of lifecycle , so they started with that as the challenge point and work from there. 72 | * Aaron Heckmann: That transition happened before I started at PayPal (a year and a half ago) , but since this change 73 | definitely has been very positive for PayPal as Dan mentioned, release cycles were insanely slow, people were very 74 | frustrated, something need to be done Node.Js was selected primarily for that reason , and along with that choice of tech, 75 | it wasn’t just the technology, was also the mindset behind it, how to use this technology, it enables teams to move 76 | more quickly; you don’t need to have bulletproof plans , you have an idea what you think is gonna work, you get a pretty 77 | good version out the door, and then iterate on that , you just can’t do it with multi-month release cycles, so it was 78 | a lot of education that came with it. What came with that was Node.Js -enables of being a little move more quickly, 79 | so I think it’s been successful as far as that goes at PayPal, and now we’re facing different kind of problems, 80 | we’re like how do we want to take it to the next level. It is politics involved, somebody from the top decide it to change. 81 | * Dan: the digital transformation that I’ve seen been successful, all had buy-in and trust, you need a little bit of both, 82 | you need yes we’re in this but also we’re gonna let those folks take and run with it. Nikolay do you have any thoughts 83 | that you wanted to dive in here and touch on threading? 84 | * Nikolay Matvienko: We’re working on digital transformation for large ecommerce companies such as Macy’s, Toys’R Us, 85 | and also we decompose our applications to smaller apps, but within each request we do work for CPU , empty collection, 86 | logging, SSR server-side rendering, garbage collection, all those execution in the request and box event loop and block 87 | servers our web server, so the solutions that we use is to process or move execution to other child processes so we use 88 | stream server-side rendering to do not block event local; there is a thread pool in v8 and it helped a lot, and for APM, 89 | matrix collection we also use external process so we just send them and around and collect those in matrix and passed to serious 90 | time zeros database. I’m interesting in an ability of any work your API, our application becomes work slowly. 91 | * Michael: There’s been some initial work on worker APIs and support that kind of stuff, the one thing I don’t see 92 | that’s come out of that yet, it’s like a real concrete use case that’s says: here’s one where you do this today but 93 | we think it would be more efficient if we had in process worker threats and if you can help sort of capture that, 94 | that’s one of the ways that I think it would be more useful. Here’s an area where it’s defined use case basically we can use 95 | to test out things and stuff like that and make the case for worker threads that would be very useful. 96 | * Dan: there is a good example right now and react with async rendering stuff that’s being developed mostly for a front 97 | end context, the ability to break up the complex rendering of a page and basically fulfill as needed and then flush 98 | to the server is one example. 99 | * Michael: So it’s sort of capturing a bunch of those where you could then experiment with, or we could do that today like 100 | with the cluster modules; you can say Ok, but then here’s some bottlenecks and then are already NPM packages that will 101 | let you use worker threads and stuff we could compare those, just sort of help in terms of the process of making the case 102 | for why you need them and why they’re important. 103 | * Dan: One thing happening today in front-end Javascript is we’ve introduced in the front-end platform a service worker, 104 | and that is an off main thread , and that begins to introduce a whole possibility of compute model for the platform and 105 | it’s not quite multithreading, it’s kind of background workers , message passing, it’s a model that is working very effectively 106 | in front end and I think there’s a base argument for Node just in we’re going to enable parity for the rest of platform, 107 | and then in terms of that you apply that execution model , I think we would look first to how it’s being applied on 108 | those environments and then you’ll also see how we can leverage that model for doing more heavy compute, NLP, 109 | AI managing infrastructure, the ability to plug those in and not have to design around compute. 110 | * Michael: When I think the concrete outcome, is if we can get this group to help with some of the work, if we have from 111 | our users or end users like solid and documented use cases that say either we can’t do it today so we’re using something 112 | else or we can do it today but it’s suboptimal because we’re using these other things; that’s kind of the piece that’s 113 | been missing from the technical discussion. There’s some people: this is a good thing we should have threads and then there's 114 | some people well no , does very well without threads , you can already do it with things like a cluster module and so forth, 115 | so I think bringing to the table the end user experience to make the case is one of the thing that would help push that forward. 116 | This sound like if it’s a concern for the people Aaron’s working with. 117 | * Aaron B: I just share a deck slide where it shows an example of communicating with that RPG business logic so it’s same machine, 118 | a different runtime environment same operating system so it’s two different processes so are spanning processes in 119 | this scenario, but that could be the case for maybe a use case and this is a frequent use case that’s gonna happen on IBM i. 120 | So I don’t know if that would work, it sound like there’s two different things: are we talking about web workers 121 | as separate threads within the same process but then also web workers also can be a separate process ? 122 | * Michael: You can implement them as threads or processes so there’s advantage pluses and minuses that way there’s the kind 123 | of APIs that you need , so today you could use the cluster module or child processes to kick off things that would 124 | work on their own. Most people are looking that kind of model where it’s message passing and you have another 125 | sort of environment, but even this one you could probably look and say well can we act, could you actually do that with 126 | the cluster module by farming it off and then when it’s done: hey here’s the answer and if you could then there’s still 127 | the dimension that well is the ergonomics of that bad enough it’s worth having a new API that lets you do it much 128 | more easily, because it’s a common and important use case in which case like the workers may let you do it a lot more 129 | easily without having to have a s much knowledge as so forth , but it’s difficult, it’s like one of the areas where 130 | people figure it out but there’s not a good How TO Guide , or here are the cases that we can’t do and I would have 131 | moved over to node except I couldn't do this and that’s that having those captured somewhere so we can have as input, 132 | I think is where I could see you guys getting in people, getting involved and maybe we can put something together on that front. 133 | * Aaron Bartell: you shouldn't store any business logic in Javascript and I’m wondering if you have a comment on that 134 | based upon your experience with PaypPal. 135 | * Aaron Heckmann:Lots of business logic is in node apps , but I think the majority is still in the Java services layer, 136 | so I mean that’s like a historical thing; PayPal has gone through many different evolution and technology stacks, 137 | primarily it was C++ and then Java node. For me personally, I was surprised that there wasn’t a lot in Node, 138 | just based on the companies I’ve been working in. Some of the teams are curently considering moving from Java to Node 139 | for the API service layer, which is a pretty big commitment, but we are not there yet. 140 | * Aaron B: One of the things I’ve been doing it, kind of further justify this line of thought is put together a list of existing 141 | open-source, full ERP or what have you applications that are larger that have done the business logic thing, 142 | but if anybody else had additional open source repositories to add to that are full-fledged business apps, 143 | please let me know so I can forward those to these different IBM i companies because I’m constanly facing a littered 144 | legitimization of was it is just of fisher price mode, there’s Node.Js thing can it really be used for these types of things. 145 | * Tierney: Node.Js foundation has actually done a few case studies with major users of Node, I can FW those. 146 | * Aaron B: Those cases aren’t going that deep, so t’s great for CEO, because PayPal went before him and JP Morgan went before him, 147 | but once it get down to the geeks, the Java coders that love their environment today they want to see that justification; 148 | so a testimonial of an existing Java coder who gives examples of here’s how I succeeded in my career and helped my business, 149 | moving to Node.Js there’s things like that, that could be put on a legitimate site Nodejs.org would mean a lot. 150 | * Michael: If you could capture that list, as a group we could come up with answers. I’m sure once we do that we can get those 151 | to Node.Js web sites , because the Foundation is very interested in helping to push those kind of things as well. 152 | * Tierney: If you’re interested in machine learning and Node.Js there’s now no tensorflow that was announced at Google. 153 | * Dan: I hosted an event up in Toronto and we had Cuhady the CTO of Condenast, come and share some of the ways they're adopted, 154 | to modernize the business across the board moved to the platform of the Node to embrace the agility of the platform; 155 | they are now incorporating blockchain and AI and other compute-intensive projects into their ecosystem , and rather 156 | than force all of the machine learning folks to adopt node the approach they use around AI is: we’re going hire 157 | talented machine learning developers and let them work in the native language they are proficient in, and then 158 | everything they deliver to the apps is exposed via API, and most of that’s written with Node. 159 | * Debugging Node: Tierney: We need to fully implement source maps. That will help us get debug ability back for those 160 | transplant languages. 161 | * Michael: I wonder about a survey. What do we need to do to support typing since we now think it’s important and prioritize 162 | some of the things that would make that. Kind of questions that tease out that, people want types, but they’re not really 163 | gonna use it seriously until it’s part of the language or is running an extra tool that helps you use them acceptable or not, 164 | because it will help us decide where we should advocate; if it’s a project though type is important for the success 165 | of Node maybe we should be pushing a TC39. 166 | * Dan: Nikolay are you seeing folks adopting typescripts and if so why? 167 | * Nikolay: I like a freedom of weak type or streak type in Javascript and in Russia we have a lot of companies that for 168 | example use a closure to Node.Js, because they have a closure developers or types, or Jetbrains. 169 | * Michael: With the group here can we come up with a set of question? see [#61](https://github.com/nodejs/user-feedback/issues/61) 170 | 171 | 172 | 173 | ## Upcoming Meetings 174 | https://github.com/nodejs/user-feedback/issues/64 175 | 176 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 177 | 178 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 179 | -------------------------------------------------------------------------------- /meetings/2018-05-25.md: -------------------------------------------------------------------------------- 1 | ## Links 2 | 3 | * **Recording**:https://www.youtube.com/watch?v=zpPq9USuZvk 4 | * **GitHub Issue**: [#64](https://github.com/nodejs/user-feedback/issues/64) 5 | * **Minutes Google Doc**: [Doc](https://docs.google.com/document/d/19vcsnk6Fiyfc-PmvezowTAuviKnQh4nrjQYAdE_Fbms/ ) 6 | * **Next meeting: Public User Feedback focused on tooling 06.08.2018- [#59](https://github.com/nodejs/user-feedback/issues/59)** 7 | 8 | 9 | ## Present 10 | 11 | * Michael Dawson (@mhdawson) 12 | * Dan Shaw (@dshaw) 13 | * Tierney Cyren (@bnb) 14 | * Mihai Ene-Pietrosanu (@mihaiep) 15 | 16 | ## Agenda 17 | 18 | ## Announcements 19 | 20 | * Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 21 | 22 | ### nodejs/user-feedback 23 | 24 | * Public User Feedback request - European General User Feedback at WorkerConf [#56](https://github.com/nodejs/user-feedback/issues/56) 25 | 26 | * Invite Node.js tooling ecosystem folks to discuss user feedback [#37](https://github.com/nodejs/user-feedback/issues/37) 27 | 28 | ### Notes: Intro by Dan 29 | * Get ready for Node.Js collaborator summit Europe edition next week and we will have a Public User Session in Austria, 30 | hosted by Benedikt from Google from v8 team lead. We will need to document some things. 31 | * Share thoughts from Dan: invite folks to put questions; have a brainstorming for next tooling meeting; 32 | * Michael: If you hear the people asking particular things post them into that issue. 33 | * @yhwang and Michael are coordinating the group formed nodejs/embedding team 34 | * We would like to have Chris to have a cadence with tooling. Action: Michael will reach Chris and talk about this. If he’s got the 35 | cyles to kind of sort of drive the organization part that would be good. 36 | * Next meeting on 06.08.2018 we are hosting public tooling 37 | * Enterprise: still on going. Coming with a propose for the next session. Most of the communication is by email 38 | and the repo. (Tierney: we have an email list like from about 7 months ago, at least we should dig after that). 39 | Once the next week it’s over (summit) we will think more about this. Reach out to @ahmadnassri, hand out the list of 40 | contacts and to set up the next meeting? Issue [#66](https://github.com/nodejs/user-feedback/issues/66) 41 | 42 | ## Q&A, Other 43 | 44 | ## Upcoming Meetings 45 | 46 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 47 | 48 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 49 | -------------------------------------------------------------------------------- /meetings/2018-06-08.md: -------------------------------------------------------------------------------- 1 | # Node.js Foundation User Feedback Meeting 2018-06-08: Tooling Feedback Session 2 | 3 | ## Links 4 | 5 | * **Recording**:https://www.youtube.com/watch?v=8NCutuQx5Qk 6 | * **GitHub Issue**: [#68](https://github.com/nodejs/user-feedback/issues/68) 7 | * **Minutes Google Doc**: https://docs.google.com/document/d/1bP7fdN-mf47SJcNEfWm_F2EbcpSgDEEyw4tIhRMDpPg 8 | * **Discussion focused on tooling** [59](https://github.com/nodejs/user-feedback/issues/59) 9 | 10 | ## Time 11 | * Friday, June 8th 2018 16:00 UTC 12 | * Attendees 13 | * Michael Dawson (@mhdawson) 14 | * Dan Shaw (@dshaw) 15 | * Christopher Hiller (@boneskull) 16 | * Agiri Abraham Jr (@codeekage) 17 | * Mihai Ene-PIetrosanu (@mihaiep) 18 | * Chris Barber 19 | * Gus Caplan 20 | 21 | ## Notes 22 | * We will gather user feedback from Tooling group. For this session, I've selected a few "hot-button" issues from #59 23 | which we will discuss: 24 | Cross-platform problems (fs, child_process) 25 | * Chris H ->fs.watch does not work like it expects, may only work on linux. Userland modules have sprung up to fix some 26 | of these problems. 27 | * Chris B -> need recursive file watching, but linux does not support it, they have to maintain code to manage watching. 28 | Need to be able to watch files that don’t exist, broken symlinks, those that have permission changes. Wrote library 29 | that does it the hard way, only watch directories to keep numbers of messages down. Widows emits 3 events, 30 | linux/osx only 2. Tested 27 file system watches, and none could watch files that did not exist. 31 | * Chris H, looking at how python handles this, does not have an equivalent. Some third party tools like watchdog, 32 | or facebooks watchman. Sounds like a difficult problem to get right and consistent behaviour across platforms. 33 | May be difficult, don’t care if it’s hard, need it to be fixed. Struggle with shipping native code, requirement 34 | for compiler is too much. 35 | * Tierney, Chris H can you provide some context. Work on Titanium mobile sdk at “accelerator something”. 36 | Built service that runs in the background (similar to adb), need to watch if install new xcode, connect device to machine etc. 37 | They listen for changes and broadcast changes to listeners. 38 | * Chris B, are you shipping Node. Before no but now yes. Daemonized process runs using version of Node that they 39 | downloaded (or installed as part of their offering). They use node-pre-gyp. Started by building native addons 40 | and building into with their package. They actually strip out just the Node binary (minus npm, etc.) 41 | * Chris H, seems like issues are beyond just fs watch, difficulty with native modules , Chris B you also mentioned 42 | some more cross platform issue (os.arch) 43 | * Chris B, if you run 32 bit on 64 bit machines it returns 32 bit as opposed to the architecture of the machine itself. 44 | (Michael 32 bit dropped in 10.x). 45 | fs is missing some key operations (rimraf, mkdirp, fs-extra, etc.) 46 | * Chris H, a number of modules that do very common file system operations. Many people report that these should be in core. 47 | Also graceful-fs which has a lot of history. Claims to improve cross platform compatibility with windows and some other things. 48 | Why do these exist to fix problems in core? Why fix in userland, does anybody have the history. 49 | * Dan, fs module largely exposes posix API, rimraf/mkdirp are convenience on top, argument was that you can go and create 50 | them independently in userland. 51 | * Michael, point in time decision? Do we have more info how? 52 | * Dan, effort to avoid dead code library (ie unused code), at some point thought APIs would be done but, 53 | no longer view that we are going to be done at some specific release. Quite likely just that it is the way it was and just 54 | there has not be anybody to advocate for since. 55 | * Chris H, agree with small core philosophy, but seems to have become obvious that rimra, mkdirp should be part of fs. 56 | Should be focus of what this group can start by championing? 57 | * Dan, we should likely start by focussing on a smaller subset. 58 | * Dan, graceful fs, does not use native code, but does use internals which has been one of the things driving the project 59 | from letting userland do whatever to being to protect core apis (ie clarify contract). 60 | * Dan, not sure what graceful fs does that could not be achieved in core. 61 | * Chris H, cross spawn, why can’t I use spaw on windows and have it work as expected. 62 | * Chris B, have not needed graceful-fs or cross spawn, do use rimraf, mkdirp, fs-extra. 63 | * Dan, can’t speak to apis, can can speak to why it was developed. Core maintainer of npm 64 | build graceful-fs to smooth over some of the challenges he was having building npm. 65 | 66 | * VM module 67 | * want to create sandbox, give it to the user and make sure they don’t escape 68 | * vm2 module tries to do that, but has to do all sorts of terrible things. 69 | * Chris H, as somebody working on test, would like to be able to create pool and let test run in isolation,so that can re-use 70 | * Chirs B, when needing to assemble configuration using a number of modules but would be nice if code running was limited in what they could mess up. Their app allows plugins, want to prevent things like calling exit and would like plugins to be prevented from doing that. They recently solved by running in a sub-process. 71 | 72 | * **From Live Chat:** 73 | * from Christopher Hiller to All Panelists: in python: os is low-level fs stuff, shutil is high-level 74 | * from Gus Caplan to Everyone: so being able to have a complete isolation between you and the 75 | “untrusted” code; I was about to mention that process.exit will just kill the thread instead of the process 76 | i’ve heard that come up before, iirc it was a limitation with v8, it seems like its worth opening an issue 77 | for though v8 expects you to collect entire isolates not individual contexts; 78 | thats been such an issue that tc39 is trying to think of some new type apis for it 79 | as realms come up. 80 | * also improving communication; vm was never intended to be a security mechanism, 81 | and its pretty apparent how many people get confused about it. 82 | * it’s that word "sandbox" maybe the language shoudl be changed or there should be qualifiers in the docs. 83 | 84 | * **Upcoming Meetings** 85 | * User Feedback team meeting on 06.22.2018 86 | * Node.js Foundation Calendar: https://nodejs.org/calendar 87 | * Click +GoogleCalendar at the bottom right to add to your own Google calendar. 88 | 89 | -------------------------------------------------------------------------------- /meetings/2018-06-22.md: -------------------------------------------------------------------------------- 1 | ## User Feedback Team Meeting 06-22-2018 2 | ## Links 3 | 4 | * **Recording**:https://www.youtube.com/watch?v=YbH3k1-Vo6w 5 | * **GitHub Issue**: #72 6 | * **Minutes Google Doc** https://docs.google.com/document/d/1v9iX6RyCjINL6gbes1bSOVN93-vbxuVvAwzsF83kchI 7 | * **[General Public Meeting 07.16.2018, 9AM Pacific time](https://github.com/nodejs/user-feedback/issues/74)** 8 | 9 | ## Present 10 | 11 | * Michael Dawson (@mhdawson) 12 | * Dan Shaw (@dshaw) 13 | * Mihai Ene-Pietrosanu (@mihaiep) 14 | * Tierney Cyren(@bnb) 15 | 16 | ## Agenda 17 | * Public User Feedback request - European General User Feedback at WorkerConf #56 18 | * Invite Node.js tooling ecosystem folks to discuss user feedback #37 19 | 20 | ## Announcements 21 | 22 | * Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 23 | 24 | ### nodejs/user-feedback 25 | 26 | * Public User Feedback request - European General User Feedback at WorkerConf [#56](https://github.com/nodejs/user-feedback/issues/56) 27 | 28 | * Doing session similar to one at IBM Index Conf 29 | * If you have any suggestions of people in Europe, Tierney -> Dan Kahn 30 | * Dan -> still some management issues in adopting Node.js in Europe, good chance 31 | that will be part of the discussion. 32 | * Tierney made a few other suggestions based on the attendee list. 33 | 34 | * Mihai, will it be streamed live? If possible would be great. Dan will try to record and setup 35 | zoom stream. 36 | 37 | * Invite Node.js tooling ecosystem folks to discuss user feedback [#37](https://github.com/nodejs/user-feedback/issues/37) 38 | 39 | * Nothing to talk about on this front, just remove label. 40 | * Happy with progress that Chris is making 41 | 42 | * Pull in threads from collab summit. 43 | 44 | * 3-5 people mention, we would like to do sessions, encourage people to create issues but I don’t think they have shown up. 45 | * Main one that Dan remembers is promises. 46 | * Tierney suggested that we create issue. 47 | 48 | * Next user-feedback session ? 49 | 50 | * Better metrics around real-world usage 51 | * need to figure out good way to get data 52 | * go to 3 major cloud vendors who are members to get data? 53 | * share anonymously, only publish as a total. 54 | 55 | 56 | ## Q&A, Other 57 | ## Meeting Notes: 58 | * Dan: I am a week away from worker conf; I will be doing a public session feedback similar with the one at Index 2018. 59 | Calling for contacts in Austria, Eastern Europe side, to get some connections set up ahead of time. 60 | * Tierney: What about Dan Kahn? 61 | * Michael: Are you going to focus on tooling, enterprise or general? 62 | * Dan: General and European challenges from the discussion I’ve had with other members there; there are still sort of 63 | management tensions that folks are dealing with, getting to use the technology, folks are still a little bit more comfortable 64 | with Java and some other technologies. 65 | * Tierney: There is an individual from Bloomberg, Oracle. 66 | * Mihai: It will be great if we can have this live on Youtube or have the recording audio files and then 67 | I will extract some notes. 68 | * Dan: There were some discussions on Berlin summit they did not get in GitHub. I had encouraged people 69 | (had discussions in Berlin) to open issues, but the reality there are not issues with them the only one I remember top of mind 70 | was Promises. Are there any other sessions that folks remember we need to capture? 71 | * Tierney: One thing that I’ll suggest, and this is just from helping bootstrap stuff is take away as much of the big like 72 | that starting work as you can from other people and let them carry on with it because pulling the trigger on creating 73 | an issue it theoretically very simple it’s the largest barrier to entry. So, once you get start doing that and introduce 74 | that to people it’ll become easier over time. 75 | * Dan: To clarify this your suggestion is to go and create the issue for folks or don’t create the issue and let them basic issue? 76 | * Tierney: Create issue for folks and then make sure they come in and engage with it and you can help manage that a little 77 | bit or do whatever we need to do but talking and creating the issue is very helpful to get things going, because people 78 | often don’t feel like they are familiar enough so having someone who is perceive is familiar enough, breaks that barrier. 79 | * Michael: On the Promises front the other groups we have are kind of focused around groups in the ecosystem and I could see 80 | Promises being a topic that anyone of those groups would look at, I’m looking what would the promises of User Feedback 81 | group will be? There were a lot of discussion in the previous sessions around use cases, that was almost led as: let’s understand 82 | the technical requirements and then define requirements and then push that forward. 83 | * Tierney: I think this can be less like ecosystem things that we’ve been doing and more like the first one we did with 84 | the benchmarking group, so we kind of do have two approaches, have precedent we’ve just been leaning on the latter approach 85 | a lot more recently, but that doesn’t mean that we can have a lot more input from different individuals who are in the 86 | ecosystem now so we can go do those things more strongly now, those original approaches. 87 | * Michael: And sort of like the benchmark we supported an effort that they came up with and I think similarly I can easily 88 | see that being the case that there’s bunch of places where actually we have discussions about creating surveys and 89 | I’m involved in a couple of those where it’s like as soon as we come with those questions we’ll bring them over to user 90 | feedback group to help the community, get that feedback and one of them is around debugging, sort of sub workgroup being 91 | created in the diagnostic workgroup, I think they were talking about one , modules we’re also talking about one. 92 | What in the end do we come out with, that’s the thing we’ve achieved. 93 | * Dan: So my understanding from the sessions, we have very active proponents that have engaged with Promises ecosystem and 94 | they feel like the broader community doesn’t have a clear understanding of the scenarios where promises are used and the 95 | challenges around that and they’d like to build understanding and get feedback around promise usage and if I put words in 96 | their mouth I would think that their end game would be to see if they could influence the project more to encourage more 97 | platform level adoption and support for Promises. 98 | * Dan: Speaking of that we need to do at least one session, we’re going to teach you how to fish an then please run more 99 | of those sessions so you can get more feedback we will continue to amplify and support, encouraging either companies 100 | that are actively using promises or companies that are struggling or unhappy with promises, to come and engage in those 101 | sessions and by having those sessions captured and the feedback discussions, that will provide the baseline inputs that 102 | the project needs to be able to get more feedback and then from there maybe a survey would be a good tool, but I think 103 | there’s probably some steps before a survey, some consensus building before a survey to be most effective. 104 | * Michael: In that context make sense, we can only take on so many regular meetings we’ve got the tooling one 105 | is going off on its own cadence which is good the other two we still need to do put some work into to actually get some 106 | critical mass, we should grab benchmarking and say ”what do you think this will help get this off the ground the best and 107 | help get those first few initial meetings”? 108 | * Tierney: And on top of that we shouldn’t say just we’ve done one meeting with you and go continue with these meetings 109 | because it’s very helpful someone who can answer questions like how things work so one of the member of the group will always 110 | be attending, we don’t have to commit to attending one but raising our hand if we can, that would be helpful and beneficial. 111 | One of the other things would be useful for feedback, is documentation and this is coming from that redesign in my experience, 112 | we are beginning to look at how we can continuously improve the documentation, improve guides and there’s amount 113 | of issues that are going to be created or have been created to create new guides to address that content and we’re at the 114 | point where we are beginning to content create simultaneously with the design happening, so being able to get feedback on 115 | the current state of the documentation , but just going to have a survey and I will bring the issue for this. 116 | Begin to collect the questions in the website redesign repo. 117 | * Michael: Dan do you think there’s any other TSC members that we identified as particularly interested on that front? 118 | * Dan: V8 team is interested and I think we get them to engage there. 119 | * Michael: Check with Anna or Francesca to check with Google. If you are going to open the issue I can help with that. 120 | * Dan: Action item for me create the promise outrage and reach out to both; let’s get Ben also bring additional 121 | members from TSC of some different perspectives? 122 | * Michael: We should schedule a general or enterprise meeting. 123 | * Dan: June 16th General meeting will work. 124 | * Michael: Dan did you have chance to catch up with Ahmad yet? 125 | * Dan: I’ll be happy to have him push forward and organize the next Enterprise session. 126 | * Tierney: One of the things I brought up in the node foundation marketing committee meeting: try to figure it out how 127 | we can get better metrics around real world usage of node. How we can do? We need to figure it out some approach, 128 | one of approach to do it is go to the major cloud providers, because we have three of them as members go to each member 129 | that is cloud provider ask them to share their metrics anonymously and as a group as a batch, so not publish each 130 | cloud providers metrics. If we can publish the bash of metrics that will be helpful for us to understand real-world usage. 131 | * Michael: It will be interesting, I can see some reluctance, even if just the total numbers published that potentially 132 | leaks information. What sort of the major winning from that data? 133 | * Tierney: We have a number that is npm users, historically said that is node.js instances, that is not accurate. 134 | * Michael: What’s the problem that it solves? 135 | * Tierney: The problem it solves is we don’t have any understanding of how node is used, we understand the places it’s used, 136 | we don’t understand at what scale. 137 | * Michael: I think once you go beyond some high-level numbers you then get into even more trickiness in terms of like can 138 | the cloud providers even collect that data? There is a lot of discussions around it, but you can’t just go and collect 139 | their data, you got to respect their privacy and what they’re doing. There are a lot of challenges… 140 | * Tierney: Grossly underreporting right now, with 2 data sets we are at the lower end like the nine million number is the 141 | lower end of the possible range, so my estimate it’s 18 million. 142 | We cannot just rely on this data set as the single source truth because even the people who are talking aboutthat single 143 | source of truth, have their own data sets so we need to be able to co-relate that a bit. 144 | * Michael: Dockers is a good one. The downloads, the Docker distros are the other major sources. Are any other ones beyond that? 145 | * Tierney: Public sources, no. 146 | * Michael: Deployments are quite different. 147 | * Tierney: Docker is a closer representation of deployments than downloads because it’s a pull and it’s effectively 148 | one person using it, there is zero way to tell if it’s a development deployment or development usage or a CI/CD usage 149 | or a production usage. 150 | * Michael: If you want like instances deployed like Kubernetes would probably be very once at the very beginning. 151 | * Tierney: You are deploying once and then things are happening, I don’t know if that should be counted as multiple deployments 152 | because you are deploying it and it’s doing that saying. 153 | * Michael: You could think that a cloud provider may pull a docker image once and how is caching. 154 | * Tierney: We do have to begin to try to correlate the data that we have or that data can get and begin to understand 155 | it and know that are these caveats because that is how we build this platform and that is totally fine. 156 | It’s going to be a challenge. 157 | 158 | ## Upcoming Meetings: 159 | * **[2018-07-06 User feedback meeting: Guests: Ben and Ahmad](https://github.com/nodejs/user-feedback/issues/73)** 160 | * **[2018-07-16 Public User Feedback meeting](https://github.com/nodejs/user-feedback/issues/74)** 161 | 162 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 163 | 164 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 165 | 166 | -------------------------------------------------------------------------------- /meetings/2018-07-06.md: -------------------------------------------------------------------------------- 1 | # Node.js Foundation User Feedback Meeting 2018-07-06 2 | ## Links 3 | 4 | * **Recording**: https://www.youtube.com/watch?v=ehTHsDTGbRM 5 | * **GitHub Issue**: #76 6 | * **Minutes Google Doc**: Doc 7 | * **[Promises Github Issue](https://github.com/nodejs/user-feedback/issues/77)** 8 | 9 | ## Present 10 | * Dan Shaw - @dshaw 11 | * Benjamin Gruenbaum - @benjamingr 12 | * Ahmad Nassri - @AhmadNassri 13 | * Mihai Ene-Pietrosanu - @mihaiep 14 | * Michael Dawson - @mhdawson 15 | * Tierney Cyren - @bnb 16 | * Jordan Harband - @ljharb 17 | 18 | * User Feedback Members: @nodejs/user-feedback 19 | 20 | ## Agenda 21 | 22 | ## Announcements 23 | 24 | * Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 25 | 26 | ### nodejs/user-feedback 27 | 28 | * Public User Feedback request - European General User Feedback at WorkerConf [#56](https://github.com/nodejs/user-feedback/issues/56) 29 | 30 | ## Q&A, Other 31 | 32 | ## Notes 33 | * **Many thanks to our guests today Benjamin, Ahmad and Jordan.** 34 | * Intro by Dan Shaw 35 | * Dan: Promises: at the Berlin summit, bunch of folks introduced to user feedback initiative and we invited to come and participate, 36 | one of the most active and organized groups it was the group that Benjamin had around Promises, we are trying to understand 37 | where we are with Promises and what the desired outcome, Benjamin and some others would like to achieve and get feedback on. 38 | * Benjamin: At the moment there are a bunch of usability issues and debugging experience isn’t exactly where we wanted to be; 39 | one of the things I have done before the meeting was to survey like some people try to get a better understanding of how 40 | the community has been using Promises and another thing that we have done is that we got a bunch of people together 41 | who have different viewpoints around what our APIs, and what we should do; one of the next steps we want to take is to try 42 | and survey the community to understand like we have several technical options and we have discussed like the implications 43 | of implementing them and I think at this stage you want some feedback from the community to better understand what users 44 | are expecting in certain patterns like namely what should and rejections do and like what default behavior should be and 45 | also like what sort of patterns people are using, what befalls they’re running into, because we have some interesting 46 | conclusions from the research we’ve done so far and at this point we want to validate it against larger Node.js community. 47 | * Dan: Jordan do you want to add anything in there? I almost immediately rates for: “yes we could standardized APIs 48 | but are there any sort of Promises standardization workflows happening in standard space” maybe you could fill us in on that. 49 | * Jordan: I don’t know any standards workflow currently being done that would impact the debug ability story around Promises. 50 | What I usually hear is, from folks in node core primarily and almost exclusively is that debugging Promises is terrible 51 | and has always been, and that was a large part of the reason for the pushback against promise based things, but I don’t 52 | think anyone outside of core have really shared that opinion and I don’t think there is a huge debug ability problem with 53 | Promises this comes up a lot around unhandled rejections for example like desire to exit the process when there’s unhandled 54 | rejection things like that so I don’t think anyone would argue with “let’s make debugging anything better” and async code 55 | inherently is harder to debug than sync code; there’s always something that needs to be improved there and any work that 56 | we can do to improve it, should be considered. There’s a often a painted picture that things are on fire. 57 | * Tierney: Having talked to my co-workers to go on site to large enterprises and deal with people using Promises, 58 | it’s not necessarily user code its third-party code and you don’t know when you’re pulling in a bunch of modules you can’t 59 | guarantee that they’re handling Promises appropriately so that makes a hard story. 60 | * Jordan: Certainly if you’re pulling modules that are using code that are writing subpar code then your experience is going 61 | to be impacted, but I feel there’s a pretty big leap from there to say that like as it relates to unhandled projection 62 | and exiting the process even though we’re not; I don’t think anyone’s proposing that happened immediately anymore, 63 | but like there, I think there’s a big gap between other people’s code can misbehave and let’s violate what I argue is the 64 | intent of the spec so like kill the process immediately when there’s an unhandled rejection, and so I feel like I’ve in 65 | general have been reacting what I see is that large gap between here’s a problem and then someone folks assume that this 66 | is a solution, but the solution is burning more bridges than it’s saving. 67 | * Dan: I seen that and adding to what Tierney said, it’s often the practitioners that are tasked to sort of get code on 68 | messed up and Promises code tends to exacerbate that situation, the immovable point that I’ve seen around Promises have 69 | come from teams that have gotten to a point of getting enough observe in their systems, through callback wrapping and 70 | various other techniques. 71 | * Benjamin: Another big part is that the V8 team has been very cooperative and pretty grating like taking feedback we give 72 | them seriously and improving things in the engine like async stack traces in production and then the ability to inspect 73 | the stock in production, I think a big improvement; now while things are getting better and there are already a lot better 74 | than they were with callbacks at least for the big crowds. I still try to like monitor the Promises tagged in stack 75 | overflow so there are things I still it are getting brought up a lot and we’re asking the V8 team for their time in implementing 76 | stuff and they started like implementing different warnings and like things occur often for us which is very of them 77 | to dedicate that time, but I want to make sure that we’re not wasting time and things that like my intuition or like 78 | a not personal intuition which is why I think it’s really important that Jordan is here. 79 | The next step is try to figure it out good questions to ask and we would love your guidance; get the survey out so we can bring 80 | it up in the meetings we have with the V8 team. 81 | * Dan: Ahmad is representing enterprise and has large deployment of node, is our guard Promises a problem, start with this 82 | kind of the broadest question. 83 | * Ahmad: I don’t really hear too much complaints or see kind of situations where like our deployment or our application 84 | development is affected by that, but I think it only becomes a problem in the context of inconsistencies and debugging 85 | as we said, it’s not great, but I would echo the point it’s not a burning problem; the nicest thing a developer has to do 86 | in terms of debugging issues when they have to deal with code that’s mixed between Promises and non Promises especially 87 | when it comes down to the native node APIs. 88 | * Dan: Michael what the current approach TSC is having to dealing with them promised APIs? 89 | * Michael: At this point its in an experimental state where we’re different people are adding a some API as experiemental 90 | and we are using those to work through to get a feel for what works and what doesn’t as prelude to making a more 91 | organized effort to cover the broader surface area of the discussion around the debug ability is that 92 | the challenge is, before Promises if you had an unhandled exception it was easy to track that down because 93 | you could set it up so you got an exception. When that happens in the case of Promises because the way rejection handlers 94 | can be added at any time that's more difficult, so if people tasked with tracking down say intermittent or production 95 | problems we’re used to that tool which they had that was that they found effective,getting core out and being able to look 96 | at the stack and then going back the developers, not having that is a challenge for them. I also agree that breaking the spec 97 | it’s not the obvious choice either, so it’s trying to figure it out what will let people debug and identify the location of those 98 | problems while maintaining how about we were needed. 99 | * Benjamin: One of the things that I’ve been seeing it’s that very few people like when I asked the question which is easier 100 | for you to debug like Promises the same functions or like Promises without us think about a single weight or callbacks, 101 | like almost everyone in the crowd said I can pull the data but almost everyone in the crowd said that a sync functions 102 | are easier to debug than callbacks and then Promises were about as hard for the people that I question, this is like 103 | another thing that we can ask, because very few people it’s very predominant in core but I don’t feel that this is the 104 | case for user base. 105 | * Michael: We need to make sure we have questions when we go out to capture who we’re talking to, because I’ve seen quite 106 | in a lot of cases it sounded like the developer who writes the code is not necessarily the one pulled in to debug those 107 | issues in production, so we may talk to a large portion of the users and it’s like well it’s no different because 108 | they’re not actually the ones who debug those kind of problems in production. It’s just a matter of understanding, 109 | it’s that it’s not an issue but I think we need to get the right people answering as opposed to but it or to be confident 110 | that we’re asking the right people before we decide it’s not. 111 | * Dan: Benjamin what are the things that you know distract from a meaningful discussion around Promises? 112 | * Benjamin: I think there’s a bunch of interesting discussion around Promises right now, Netflix are like have committed 113 | to spend effort on getting like the postmodern debugging story better and having meetings on that and we like thing are moving 114 | not very quickly, but they’re moving, so that part is working well and then we want to get to a point where we are comfortable 115 | with the debugging experience people have now, that isn’t to say like debugging Promises is easy or hard but it’s what 116 | people are using like pharmacists are effect at this point and we need to improve; there was so much resistance over 117 | so much time to Promises in core a part of that reflected them that we haven’t spent traditionally a lot of time as a 118 | project discussing what the debugging experience should be; there have been certain individuals that have spent a lot 119 | of time on that, but we haven’t done the discussion as a project so we’re starting to get some discussion going and just 120 | the fact that three people here have very different experiences that are all valid about how people are using/debug 121 | Promises is just a strong indication that the data would be very useful. 122 | * Dan: I guess the thing that I’m probing for is establishing signal around Promises do we need to avoid or embrace async/await? 123 | * Benjamin: I think we need to embrace async await, this is my opinion. 124 | * Jordan: I think async/await is Promises but is not even all Promises it’s like async function is awesome because it’s a 125 | static way to guarantee that a per function returns a promise and never throws but await I find to be actually terrible 126 | in practice it’s only used easily, very tempting to accidently create a serialized second set of async actions when most 127 | of them could be parallelized in other words, the advice I give people is don’t ever change your Promises make each promise 128 | be a separate variable and then when you are done you can combine chains if it makes sense everything that’s a chain you can 129 | write in terms of a weight; in my experience if you followed that order where you don’t type a weight ever until the very last 130 | step then you end up with maximally parallelizable or concurrent code and avoid accidently chaining things that don’t need to 131 | be changed; I don’t understand how you would be able to optimize async/await both at the same time. 132 | * Async/await is promises you await Promises like async reductions waiting for return promises and it’s like always the 133 | same native promise, now this gives if I understand correctly, an easier path towards providing useful debugging experience 134 | about the promises, so I’m not like saying our API should be a single bit focused, and definitely agree that 135 | people are experiencing through- take credit that running them concurrently is a problem it’s like something that’s happening, 136 | but like when V8 asks us where they should spend their time when improving developer lives in debugging Promises like we want 137 | to optimize the common case like what we think most of our users are doing. 138 | * Jordan: If you are only dealing with async functions and the call into other async functions , but many promise APIs 139 | are not implemented in terms of async functions and a weight is just promise start resolved around the thing you’re awaiting; 140 | if you don’t provide the way to a way to debug async stacks with regular Promises, then people who are trying to debug their 141 | async functions are going to find that a magical and undeterminable subset of their async operations can be stepped through 142 | in the debugger and the rest cannot. Regular promise chains and async await are so inextricably coupled that if you provide 143 | a debugging experience for one and not the other it’s going to be subpar because I agree most developers are typing async await 144 | at this point. 145 | * Benjamin: Is the limitations severe enough to not spend twenty percent of the time on like eighty percent of the game. 146 | * Showing the benchmarking survey data 147 | * Dan & Ahmad: enterprise users around Promises? 148 | * **Ahmad to reach Michael to talk and sync up next session (list of attendees)** 149 | 150 | 151 | ## Upcoming Meetings [#74](https://github.com/nodejs/user-feedback/issues/74) 152 | 153 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 154 | 155 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 156 | 157 | 158 | -------------------------------------------------------------------------------- /meetings/2018-07-30.md: -------------------------------------------------------------------------------- 1 | # Node.js Foundation User Feedback Meeting 2018-07-30 2 | ## Links 3 | 4 | * **Recording**:https://www.youtube.com/watch?v=w3Pwees_Lrw&t=62s 5 | * **GitHub Issue**: [#80](https://github.com/nodejs/user-feedback/issues/80) 6 | * **Minutes Google Doc**: [Minutes](https://docs.google.com/document/d/15uNtsP2apyU7Jza_tksp2UcXI7Ed06i90YdjVNG6xDw) 7 | * **2018-08-16 End User Feedback Meeting - Enterprise Use Case [#81](https://github.com/nodejs/user-feedback/issues/81)** 8 | 9 | ## Present 10 | 11 | * User Feedback Members: @nodejs/user-feedback 12 | * Dan Shaw @dshaw 13 | * Michael Dawson @mhdawson 14 | * Mihai Ene-Pietrosanu @mihaiep 15 | 16 | ## Agenda 17 | 18 | Public User Feedback request - [#77](https://github.com/nodejs/user-feedback/issues/77) 19 | 20 | 21 | ## Announcements 22 | 23 | *Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 24 | 25 | ### nodejs/user-feedback 26 | 27 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 28 | 29 | 30 | 31 | ## Q&A, Other 32 | ### Notes 33 | * Intro by Dan: follow up on Promises #77, https://github.com/nodejs/user-feedback/issues/77 34 | * Discussion around the thread/questions from the issue #77 updated, comments had been made. We have 10 participants into this discussion initiated by Benjamin, more comments are welcome. Probably this discussion will be moved to a Google doc, easier to comment and participate. 35 | * there is a baseline of technical questions, with the survey we want to make sure we will capture quantifiable answers. 36 | * We should not have status on readme file. Action item modify readme and add tooling and enterprise. 37 | * The first virtual meetup: issue created #82 https://github.com/nodejs/user-feedback/issues/82 -Michael proposal: mid to late September. 38 | 39 | 40 | ## Upcoming Meetings 41 | * Thursday,2018-08-16 End User Feedback Meeting - Enterprise Use Case 2018-08-16 at 17:00 UTC / noon ET / 11am CT / 9am PT 42 | * Issue [#81](https://github.com/nodejs/user-feedback/issues/81) 43 | 44 | 45 | 46 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 47 | 48 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 49 | -------------------------------------------------------------------------------- /meetings/2018-08-16.md: -------------------------------------------------------------------------------- 1 | ## 2018-08-16 End User Feedback Meeting - Enterprise Use Case 2 | ## Time 3 | Thursday, 2018-08-16 at 17:00 UTC / noon ET / 11am CT / 9am PT 4 | ## Links 5 | * Youtube recording https://www.youtube.com/watch?v=mDE6G6I180w 6 | ## Agenda 7 | * This is a public User Feedback meeting with invited participants focused on a specific topic, the Enterprise Use Case 8 | or Node.js. Please feel free to propose items for discussion to be added to the agenda below. 9 | * Topics: 10 | * Round table Introductions: 11 | * Who are you? 12 | * Where do you work? 13 | * What do you do? 14 | * Describe your Node.js. Enterprise Use Case 15 | * What's working and what isn't for Node.js in the Enterprise? 16 | ✋ Raise hand to join the discussion 17 | * Open feedback forum 18 | ### Invited 19 | * User Feedback team members 20 | * Dan Shaw (@dshaw - User Feedback Champion, Mentorship, CommComm) 21 | * Mihai Ene-Pietrosanu (@mihaiep, User Feedback) 22 | * Michael Dawson (@mhdawson - User Feedback, CommComm, TSC Chair) 23 | * Tierney Cyren (@bnb - User Feedback, CommComm Chair) 24 | * Enterprise Use Case Representatives 25 | * Ahmad Nassri (@ahmadnassri - Principal Architect, TELUS) 26 | ### Present 27 | * Dan Shaw (@shaw) 28 | * Ahmad Nassri (@ahmadnassri) 29 | * Mihai Ene-Pietrosanu (@mihaiep) 30 | * Tierney Cyren (@bnb) 31 | * Joel Chen (@jchip) 32 | * Adrian Maurer 33 | 34 | ### Notes: 35 | * Thank you, Ahmad, for leading this meeting! 36 | * Ahmad: I want to understand a little bit more from everybody, what does it actually mean that you’re using node.js? What are you using? What is the ecosystem for your development tooling look like and is I mostly JavaScript with node.js as an accelerator for tooling or is it you relying on node.js itself for running your backends and your APIs in your systems? 37 | * Joel: We are still a very heavy user JVM We used different script framework like backbone and jquery so when we moved to node.js we were primary thinking of using node.js to back to power react web application, that means node.js has replaced all and powering would react to run the website and in the backend as an orchestration layer to connect to all the backend, so the backend is still based on Java and a lot of our tooling existed as Java framework like we use Nexus with Jenkins for build and we are building new tools in Java that are complementing the existing Nexus and the Jenkins ecosystem , for example we have teams who built an NPM server on top of Nexus and we have teams who built system on top Jenkins, so node.js is mainly used as an orchestration for the web applications. 38 | * Ahmad: How reliant are you on that middleware terms of your business operations? What’s the opportunity cost for you to even consider trying something other that node.js is that something that you’re heavily invested in, in terms of that matter or being technology reliant on node.js given the front-end dependency or is that just a investment that you’re doing now but you don’t have a dependency? 39 | * Joel: I will say we are deeply integrated with node.js as far as running our websites. 40 | * Ahmad: what would you say the biggest kind of contributing factors for you to be successful and what have been the biggest hindering factors for your success? 41 | * Joel: The biggest factor and is sort of benefit and also a disadvantage, we initially went with node.js from Java because we want to have a unified technology, because before we have to do JavaScript and Java, but the way node.js work asynchronous nature, training has been our biggest thing and we continue to invest heavily in training and to help our developers how to learn Node.js and get up to speed on the entire ecosystem . 42 | * Ahmad: Is there any direct relation to the documentation on Node.js or the kind of guides that exist today from the community that you have benefited more from or seeing lacking? 43 | * Joel: I don’t find documentation lacking and of course I dig into the core more frequently I look at the documentation, but for a lot of our developers the documentation it’s kind of fragmented as far as the documentation goes. 44 | * Ahmad: Adrian, what sort of workloads are you using Node.js for and what has been your success factors and challenges and getting your teams to adopt and use? 45 | * Adrian: Node.js is picking up a lot in that back-end as a front-end kind of style with a lot of the clients and the teams that I’m working on, the companies I work with are heavy into the Java ecosystem they have existing large applications built in Java they want to interface with. There are specific challenges I like to talk about, dealing with complexities maybe in the sharing of certain code bases libraries things like that. Where you have several organizations within these larger organizations each developing libraries or things like standards they want to distribute across broader organization they do that with NPM registries they are self-hosted on their own Nexus repository then the consumer of those libraries or API libraries that are being developed standards are consumed your regular package; the problem is when you have multiple repositories you set up you specific repository, and call the libraries by name in your package JSON file that creates a lot of headache when we try to do things like creates more of a standard way of delivering software, configurations in those environments become complex when you have to deal with several types of our C files. 46 | * Ahmad: How big is a team and how many applications are you managing? 47 | * Adrian: Teams from two to doze, applications portfolios about two thousandand there is an exponential when you talked about libraries are being published. 48 | * Ahmad: My team right now is about 450, one third are developers and the rest are between QA design and project/business leadership teams, as applications, 800 individual apps and 100 or so libraries that we’ve created and maintained internally. 49 | * Joel: about 300 web developers, 10/12 teams with 10-15 developers but as a global org Walmart has probably hundreds of teams continuously migrating to Node.js 50 | * Ahmad: Any recent examples any recent releases or changes or updates to APIs in the core of node that have directly impacted your team or are directly in your line of sight? Do you just rely on CI/CD tools to just keep those up-to-date for you, how do you keep track of all the changes on the core and do you even invest time personally to look at it? 51 | * Adrian: Things moves slow, now we could talk about containers and passes kubernetes to kind of solve these issues and shift responsibilities a bit left to the development teams we’re not there yet, so being able to upgrade and get the latest patches and things like that it is a bit of a process. 52 | * Joel: We have many people who passively and actively monitoring the changes in the core, for our practice we lock to a version and we don’t update that version unless there’s something that’s measuring; we do update every six months then if there is any security or big release then we would consider upgrading. 53 | * Ahmad: Is there an opportunity to become a feedback cycle loop like at what point are you able to invest something back to the community by either testing those things ahead of time? When you look at stats on NPM and you look at numbers, those are devout of any sort of that business value or consumer value, you can see how many downloads a certain package has, but it doesn’t tell you that is operating on let’s say Walmart back ends it’s a critical path the delivery for Walmart, how do we surface these things, so that the investment in either the core or the packages around the ecosystem are, given more attention if not potentially more funding. 54 | * Joel: Whenever a major version comes out with plenty of our developers and teams trying out and running their apps and test. We were able to migrate easily, started with version 4 to 6 and then to 8 and 10, if we find any issues we go to core and see, usually some other people run into same issues; definitely we can have a more systematic feedback loop and we can help out on contributing testing new versions. 55 | * Tierney: it sounds like seamless and smooth upgrades between versions, is kind of a key value for you, would you agree with that? 56 | * Joel, Ahmad, Adrian: Yes 57 | * Tierney: I think there are a different kind of enterprises that are using node, there’s ones who are kind of bleeding edge and have this kind of mandate from the top to act like a startup, I’ve hard that multiple times, there’s those ones I think kind of fall line with what we’re discussing here, and then there’s other ones that are much more laggards, I echo that they don’t have the cost concern but it’s more of an expertise concern; what is the benefit for us? 58 | * Joel: For our management it’s always what is the value of that. 59 | * Ahmad: What information can you provide back that can help? For example: do you track your version history and your performance characteristics of your servers and historically look back at those and say if improved or not; do you look at the amount of error rates you’ve been getting of versions of your code, but also versions of what you are running under your code libraries, the tooling and so on? Is there any way to anonymize that data and perhaps publish it somewhere or feed it back to a crusted organization or group part of the node ecosystem, so that can help them to do something better about it? 60 | * Dan: We have the opportunity with this group to make proposals, like the other groups (tooling). 61 | * Mihai: Ahmad you should open an to follow up or for tracking purposes. 62 | 63 | * (DanS) Node.js follow-up points: 64 | * State of documentation 65 | * Join the Node.js Foundation 66 | * @dshaw I'd also like to add: 67 | * Security releases and how they affect version pinning 68 | * Ahmad Some interesting prior art from the CNCF around effectively what we were talking 69 | * about Ahmad: https://www.cncf.io/certification/kcsp/ 70 | 71 | * Node.js Foundation Calendar: https://nodejs.org/calendar 72 | * Click +GoogleCalendar at the bottom right to add to your own Google calendar. 73 | 74 | 75 | -------------------------------------------------------------------------------- /meetings/2018-09-14.md: -------------------------------------------------------------------------------- 1 | ## Node.js Foundation User Feedback Meeting 2018-09-14 2 | ## Links 3 | 4 | * **Recording**:https://www.youtube.com/watch?v=00YONf8MrIs 5 | * **GitHub Issue**: [91](https://github.com/nodejs/user-feedback/issues/91) 6 | * **Minutes Google Doc**: [Minutes](https://docs.google.com/document/d/1082uJlCb9ar9VThHI1ZRqfy9K2lpHtszSPGWkTfh53A/) 7 | 8 | ## Present 9 | 10 | 11 | * User Feedback Members: @nodejs/user-feedback: 12 | * Dan Shaw (@dshaw) 13 | * Michael Dawson (@mhdawson) 14 | * Mihai Ene-Pietrosanu (@mihaiep) 15 | * Ahmad Nassri (@ahmadnassri) 16 | * Joe Sepi (@joesepi) 17 | * Agiri (@codeekage) 18 | 19 | ## Agenda 20 | 21 | ## Announcements 22 | 23 | *Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 24 | 25 | ### nodejs/user-feedback 26 | 27 | * September 2018 Node.js Online Meetup [#90](https://github.com/nodejs/user-feedback/issues/90) 28 | * Evolving General User Feedback by hosting an online Node.js Meetup [#82](https://github.com/nodejs/user-feedback/issues/82) 29 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 30 | * Survey for strong(er) typing [#61](https://github.com/nodejs/user-feedback/issues/61) 31 | 32 | ## Notes 33 | * **Highlights:** 34 | * We got a max of 14 people in the Meetup and about 140 people on the group! **Thank you Dan! Thank you Michael&Rich for the great presentations at the Meetup.** 35 | * We have a new potential memeber Joe Sepi. Thank you Joe! helping on issue [77](https://github.com/nodejs/user-feedback/issues/77) 36 | * **Action item**: Michael follow up with Chris on Tooling (expectations). 37 | * Minutes: 38 | * Intro/talk about User Feedback and initiatives: by Dan and Michael. 39 | * Michael: we needed to go to sort of the non-core node channels to get this group of people (Meetup) 40 | * Dan: one way is to go on Node.js Twitter https://twitter.com/nodejs . We need promotions on different channels. 41 | * Talked about typing [Issue 61](https://github.com/nodejs/user-feedback/issues/61). Can we do something about it? 42 | 43 | 44 | ## Q&A, Other 45 | 46 | ## Upcoming Meetings 47 | 48 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 49 | 50 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 51 | -------------------------------------------------------------------------------- /meetings/2018-10-26.md: -------------------------------------------------------------------------------- 1 | ## Node.js Foundation User Feedback Meeting 2018-10-26 2 | ## Links 3 | 4 | * **Recording**: https://www.youtube.com/watch?v=Z-j00gVUEpM 5 | * **GitHub Issue**: [Issue 95](https://github.com/nodejs/user-feedback/issues/95) 6 | 7 | ## Present 8 | 9 | * User Feedback Members: @nodejs/user-feedback 10 | * Dan Shaw @dshaw 11 | * Michael Dawson @mhdawson 12 | * Tierney Cyren @bnb 13 | * Mihai Ene-Pietrosanu @mihaiep 14 | * Christopher Hiller @boneskull 15 | * Joe Sepi @joesepi 16 | * Agiri Abraham Jr @codeekage 17 | * Ahmad Nassri @ahmadnassri 18 | 19 | ## Agenda 20 | 21 | ## Announcements 22 | 23 | *Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 24 | 25 | ### nodejs/community-committee 26 | 27 | * Individual Membership: Current and Past Members Survey [#375](https://github.com/nodejs/community-committee/issues/375) 28 | 29 | ### nodejs/user-feedback 30 | 31 | * Evolving General User Feedback by hosting an online Node.js Meetup [#82](https://github.com/nodejs/user-feedback/issues/82) 32 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 33 | * Survey for strong(er) typing [#61](https://github.com/nodejs/user-feedback/issues/61) 34 | 35 | ### Notes 36 | * It is almost one year and it’s time to see what we are going to accomplish and what we can’t commit to. We voted that Friday is working for all of us in terms of bi-weekly meeting (no changes in calendar) . 37 | * This week Dan was asking if anybody needs to step down. 38 | * Michael: in the other groups, it’s a process where we open an issue saying if you still want to be active or move to emeritus; ping after 2 weeks if not answer after 4 weeks of no answer we move people to emeritus, but if you get back in the next period saying “I was out for a month”, you just get added back. 39 | * Michael: It’s a fairly low bar, and even if you missed it for a month there’s a way back. We did it for benchmarking, Diagnostics. We might want to formalize that every working group should do that once a year, or every 6 months it’s a fairly overhead. 40 | * Tierney: Node.Js website is a good example having like twenty contributors and about two of the were active, for a year and a half. 41 | * Dan: One of our goals with meet-up is engaging general user, breaking out Twitter, our collective twitters and github, to get in front of broader user base, to reduce the burden of doing so to us as low a threshold as possible; we aren’t needing to engage a marketing apparatus as much to promote our things. Maybe engage Tracy Lee, Zibby and Foundation representatives to promote the thing for long enough time? 42 | * Dan: from the last meet-up I think we should come up with two things: first let’s define content that we’re going to do and finalize that, for any announcements, for any dates, and then how big we can do, and test the boundaries of that and in order to that well with webinars you kind of need like 90 days, fairly extension promotion to draw folks in overtime/physics time. Take some content that is not just core, having a user share some experience, we’ve had Wallmart in the past. If folks have a proposal this is use case for node, explore that ( I enjoyed American express presentation at Interactive- a user experience). 43 | * Dan: Chris do you still want to leverage the user feedback space and opportunity to support tooling group, or tolling achieved what it needs and that’s going to be a new home? 44 | * Chris: I’m not sure, I talked about this with the group at the club summit and we decided to table that for now, we have plenty of things to do, stuff that needs to get done. I would expect to do another one at some point, I don’t know if it’s going to be a regular occurrence, I guess not, but I can’t say quite yet if we want to move that effort back into that group. 45 | * Ahmad: Enterprise still need a few more tweaks before we can talk about how did that evolved. I don’t see the kind of enterprise group being as active as part of the same community, and somehow it might end up needing a sub community of its own, especially when it comes like call to actions and getting them involved in initiatives that the core team would like to run through for example testing a beta release or getting feedback o performance, either we can replicate and we can make a little corner of it, that we can add these people to without becoming a point of spam and noise to them, as those folks who will be part of the enterprises and new companies in the future might be interested in helping out, they don’t want to be overwhelmed either, but I think could be as simple as a newsletter in a call tp action every once in a while when needed and we want to do like these kind of meetings , it’s a personal invite that works best to get these people to give us their time. 46 | * Dan: The Enterprise group would only hear from their focus area? 47 | * Ahmad: My next action is to schedule another community meeting for the enterprise group, but as a requirement for that I think like having that email signup / newsletter/ method of communication, beyond just me sending emails to individuals so people can opt into that conversation and then we can make it easier for follow-ups, especially as we want to start asking for the different working groups what actions they might want to surface whether it’s a survey or an engagement of some sort so we can make it more structured. Again, the newsletters how would that work? Who would be the person to help? 48 | * Tierney: Zibby. If we want to use the existing work like the prior art that would be the LF mailing list. 49 | * Michael: You want an infrastructure that will manage people getting in and out of the mailing list, I guess. 50 | * Ahmad: It doesn’t have to be an infrastructure it just has to be something separate than public groups so here’s a workflow: if it’s coming from enterprise at node.js.org or something similar that would like this thing distinction for somebody to look in their inbox, they know that this is something to look after and we can add people manually to it, but as long as we’re able to trigger that communication through a centralized thing. 51 | * Michael: We should ask Zibby that there’s something that the Linux Foundation has to help us. 52 | * Tierney: If we are doing manually emails, it shouldn’t be a problem, but if we want to move from manual careful about GDPR, which they handle very carefully. 53 | * Michael: If you want to give me an action, I can do that , hopefully will be an easy answer. 54 | * Ahmad: We probably want to have a process in which we announced all the working groups that if you have something to ask or to leverage the enterprise connections that we have what is the mechanism to do that? We can have a part of the github repo or issues label, format the email or something. 55 | * Michael: the new opened issue 96 https://github.com/nodejs/user-feedback/issues/96 , we had at least one Twitter conversation where somebody was saying I’m having trouble updating to node 10, so we thought it actually would be useful to gather that kind of user feedback. Does anybody has any concern before we start to promote this issue? 56 | * Ahmad: monitor and collect data output from discord forum 57 | * Michael: There’s other discussion like there’s a module which just hasn’t been up updated it’s downloaded 3 million times a week, it will be nice to know if there were five of those modules they will be really good to know that, because in the context of wanted people to move up to ten what could we do? 58 | * Dan: I think it’s a great opportunity to look at these moments in time like the LTS release and what sort of things we can be doing to support other things that are happening in the project. Also, that enterprise newsletter could be solved by having a discussion list, you subscribe to a topic on the discussion list and you go from there. 59 | * Michael: I'm going to send an FYI to the TSC and comm.comm with the link to that issue and then as long as nobody complains all asks either just to promote it through the Twitter account in the next little while. 60 | 61 | 62 | ## Q&A, Other 63 | 64 | ## Upcoming Meetings 65 | 66 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 67 | 68 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 69 | -------------------------------------------------------------------------------- /meetings/2018-11-09.md: -------------------------------------------------------------------------------- 1 | ## Node.js Foundation User Feedback Meeting 2018-11-09 2 | ## Links 3 | 4 | * **Recording**: https://www.youtube.com/watch?v=CWdOqf7OMhs 5 | * **GitHub Issue**: https://github.com/nodejs/user-feedback/issues/99 6 | * **Minutes Google Doc**: [Notes](https://docs.google.com/document/d/1e501J778utbBYguBz3kVe-Pdmd6-MJ_sAoeMc9IdR2k) 7 | 8 | ## Present 9 | * Dan Shaw (@dshaw) 10 | * Joe Sepi (@joesepi) 11 | * Ahmad Nassri(@ahmadnassri) 12 | * Mihai Ene-Pietrosanu (@mihaiep) 13 | * User Feedback Members: @nodejs/user-feedback 14 | 15 | ## Agenda 16 | 17 | ## Announcements 18 | 19 | * Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 20 | 21 | ### nodejs/community-committee 22 | 23 | * Individual Membership: Current and Past Members Survey [#375](https://github.com/nodejs/community-committee/issues/375) 24 | 25 | ### nodejs/user-feedback 26 | 27 | * Upgrading Problems - Can we help? [#96](https://github.com/nodejs/user-feedback/issues/96) 28 | * Evolving General User Feedback by hosting an online Node.js Meetup [#82](https://github.com/nodejs/user-feedback/issues/82) 29 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 30 | * Survey for strong(er) typing [#61](https://github.com/nodejs/user-feedback/issues/61) 31 | 32 | ## Q&A, Other 33 | 34 | ## Notes 35 | * Dan: We have a few surveys in plate and We've been working with Node.Js Foundation team on, how best to execute on that and make it repeatable for a little bit of context. As you know the Foundation runs annual survey things like 10 million users it’s grown, last year the User feedback team helped the Benchmarking team run a survey that is very specific to the needs of the benchmarking working group inside of the Node.js project. 36 | * Dan: we have three surveys that have been requested, one on promises, one for stronger typing and one on upgrading: issue #96 https://github.com/nodejs/user-feedback/issues/96 37 | * Joe: We’ve met with Tracy Lee and discuss that Greg Wallace used to assist in the execution from the Foundation side and since his departure were roping in Tracy Lee and her team to help us execute on and moving forward. My plan is to revive that thread and I may start a Google doc and copy all development things from that thread and ask participants to contribute to helps us wrap it up. I’m going try to formalize sort of initiative document, so we can use it as templates for other initiative we like to start, map up what the objective is, what questions we want to ask and how we want to frame it. I’ll get that moving along. We should evaluate moving forward what sort of open-ended survey we can collect migration feedback, upgrade feedback moving forward . Tracy and her team will like to help us formalizing this process, so I expect some kind of documentation on her end to facilitate future initiatives from a volunteer perspective without too much difficulty. 38 | * Dan: we have to build and refine the questions. The next reasonable time for team meeting is December 7 (in 2 weeks is going to be Thanksgiving weekend), would be the Thursday November 29 10 AM Pacific time -after Comm-Comm meeting ,good for Enterprise meet? 39 | * Ahmad: Yes, the time is good. 40 | * Dan: Online meet-up. Probably we will wait for February 2019, after Holiday season. 41 | * Issues 96: We need some action on this. Not a feedback in the last 4-5 days. 42 | * Need to create a new issue on team drive for surveys and collaboration (sensitive data, team only access or special permissions share) 43 | 44 | 45 | ## Upcoming Meetings 46 | 47 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 48 | 49 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 50 | -------------------------------------------------------------------------------- /meetings/2018-12-07.md: -------------------------------------------------------------------------------- 1 | # Node.js Foundation User Feedback Meeting 2018-12-07 2 | ## Links 3 | 4 | * **Recording**: https://www.youtube.com/watch?v=HlkyGiAG4ew 5 | * **GitHub Issue**: https://github.com/nodejs/user-feedback/issues/105 6 | * **Minutes Google Doc**: [Doc](https://docs.google.com/document/d/13wgfgJpuGF2Jepzcc44-jGLGxaHOL1DCMy5dmHE_MMA) 7 | 8 | ## Present 9 | * Dan Shaw (@dshaw) 10 | * Joe Sepi (@joesepi) 11 | * Mihai Ene-Pietrosanu (@mihaiep) 12 | * Sofia 13 | * User Feedback Members: @nodejs/user-feedback 14 | 15 | ## Agenda 16 | 17 | ## Announcements 18 | 19 | *Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 20 | 21 | ### nodejs/community-committee 22 | 23 | * Individual Membership: Current and Past Members Survey [#375](https://github.com/nodejs/community-committee/issues/375) 24 | 25 | ### nodejs/user-feedback 26 | 27 | * Upgrading Problems - Can we help? [#96](https://github.com/nodejs/user-feedback/issues/96) 28 | * Evolving General User Feedback by hosting an online Node.js Meetup [#82](https://github.com/nodejs/user-feedback/issues/82) 29 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 30 | * Survey for strong(er) typing [#61](https://github.com/nodejs/user-feedback/issues/61) 31 | 32 | ## Notes 33 | * Thank you, Sofia for your feedback and participation. 34 | * Dan: from the last Enterprise public meeting, more diverse use cases is going to give us a better insight and enable us to inform 35 | the project. 36 | * Joe, update on surveys: I posted in the GitHub issue that I would try to carry the promises survey forward and updated the Google 37 | document related with the questions that had been put so far, there was some commentary on the questions and the answers that 38 | I have not been able to fully synthesize but we’ll work on that. I will work through kind of process and package it all up as best 39 | I can, and then ask for any input we move forward in the coming days and next week; I met with Sophia and Tracy from the Foundation, 40 | we can formalize the process so that we can apply it to the migration and upgrading survey that has been mentioned an any other 41 | surveys that we want to put together moving forward. There is progress, on promises in particular, so we can formalize this. 42 | * Dan: Does make sense for us to kick to Julien or Ben able to handle some of these instances? 43 | * Joe: I’ll like to do that, and I’ll ping them so if they can help. I’ll reach out to them. 44 | * Dan: I know that Netflix is doing an operational push into Node 10 where historically promises haven’t been good for their 45 | observability infrastructure and now with the adoption of 10, they fill like getting the point where a post mortem analysis 46 | and other infrastructure they rely on is good enough to greenlight promises. 47 | * Mihai: Are we targeting a number of questions? How many? Do we still need more questions now? 48 | * Joe: We may have 10 or 15, we might want to let the survey take its own shape. 49 | * Mihai: We may want to be more aggressive on different channels to get more questions/feedback. 50 | * Dan: The risk if we don’t push it out with enough context, we risk doing a lot of effort. 51 | * Joe: Do you think we are near the end, we want a call with the key stakeholders to discuss and make sure we have the right questions? 52 | * Dan: Looking at the calendar maybe to have a meeting with go no-go question. Invite Benjamin and Julien. 53 | * Dan: Sofia, what are we looking at in terms of technology solution? Do we have a tech choice for the survey? 54 | * Sofia: I took the notes and the doc is shared. 55 | * Dan: what we have is the reports from SurveyMonkey, what we don’t have is access to the actual survey instance. 56 | What tool are we going to use? 57 | * Sofia: SurveyMonkey is good. 58 | * Dan: If you could work with Tracy figure it out what it takes to get SurveyMonkey up and running for us, in January time frame, 59 | that will be fantastic. 60 | * Sofia; How did you send the survey the last time? 61 | * Dan: Once we publish the survey then we did some rudimentary promotion of it; everybody promote it to their Twitter . 62 | We need to be respectful of the annual survey data collection run by Foundation. 63 | * Sofia: I can propose/prepare for the next meeting, a list of channels where we could promote. 64 | * Dan: Is it possible to ask Ben or Julien if they be willing to write a blog post? I know Ben is super passionate 65 | about high performance Promises. 66 | 67 | ## Q&A, Other 68 | 69 | ## Upcoming Meetings 70 | 71 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 72 | 73 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 74 | -------------------------------------------------------------------------------- /meetings/2019-01-18.md: -------------------------------------------------------------------------------- 1 | # Node.js Foundation User Feedback Meeting 2019-01-18 2 | ## Links 3 | 4 | * **Recording**: https://www.youtube.com/watch?v=c3lvH2KpM0o 5 | * **GitHub Issue**: [Issue 112](https://github.com/nodejs/user-feedback/issues/112) 6 | * **Minutes Google Doc**: [Minutes](https://docs.google.com/document/d/1CXUIUmT9RF8h7kfQQBjlnOz7aIhEXA3ucKZfi9f216s/) 7 | 8 | ## Present 9 | 10 | * User Feedback Members: @nodejs/user-feedback 11 | * Michael Dawson (@mhdawson) 12 | * Dan Shaw (@dshaw) 13 | * Joe Sepi (@joesepi) 14 | * Mihai Ene-Pietrosanu (@mihaiep) 15 | * Ahmad Nasri (@ahmadnassri) 16 | * Sofia 17 | * Tracy Lee (@ladyleet) 18 | 19 | ## Agenda 20 | 21 | ## Announcements 22 | 23 | *Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 24 | 25 | ### nodejs/community-committee 26 | 27 | * Individual Membership: Current and Past Members Survey [#375](https://github.com/nodejs/community-committee/issues/375) 28 | 29 | ### nodejs/user-feedback 30 | 31 | * Upgrading Problems - Can we help? [#96](https://github.com/nodejs/user-feedback/issues/96) 32 | * Evolving General User Feedback by hosting an online Node.js Meetup [#82](https://github.com/nodejs/user-feedback/issues/82) 33 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 34 | * Survey for strong(er) typing [#61](https://github.com/nodejs/user-feedback/issues/61) 35 | * Establish and document a framework for User Feedback surveys [#131](https://github.com/nodejs/user-feedback/issues/113) 36 | 37 | ## Notes 38 | * Thank you Sofia and Tracy for attending this meeting! 39 | * Joe Sepi: Updates on surveys: trying to contact Ben and Julien and see if they want to help and move forward on Promises. 40 | * Joe Sepi: Updates on surveys: trying to contact Ben and Julien and see if they want to help and move forward on Promises. 41 | I opened an issue (#113) on developing a framework for User feedback surveys. 42 | * Dan: Do you feel you need additional experts to contribute to this process? 43 | * Joe: That will be very helpful, from the foundation side as well as anyone who had experience what makes sense to execute a 44 | survey and what makes sense to bring benefit back to organization to act on surveys results. 45 | * Tracy: We talked about this last year and we’re happy when you guys are ready with the first one for us, just take that and create 46 | the process and stick it up in a pipeline; we want something very repeatable. 47 | * Dan: it is helpful once we have the content prepared, then we can hand it off to that workflow. Last time we did the benchmarking 48 | working group survey, we were able to lean on the Foundation, but the Foundation was leaning on external subject matter expert 49 | contractor, so what I think we might need to sort of get everything across the finish line try to get the Foundation a couple 50 | hours of individuals time to give us some of key insights into how to ingest the requests for survey put into usable format. 51 | * Michael: Last time we got good advice in terms of tweak the questions like this, get more concrete answers; Greg moved on but 52 | the person he worked for is still there so we should make sure that we have as part as workflow, getting them to review 53 | the survey and taking advantage of that expertise that the Foundation can provide. 54 | * Ahmad: Is there a context as well of how we share back the results that has been part of that template or process? 55 | * Michael: That should be part of the process, I think we want to follow what we did with last one which was we landed in Github, 56 | so the data was public; there were some pieces needed to be removed. 57 | * Michael: Upgrading problems (issue #96, #116 from User Feedback repo) closing in favor of 58 | https://github.com/nodejs/package-maintenance/issues/136 59 | as we believe the package-maintenance repo is the right place for this discussion to be handled now. 60 | * Meetup: Tracy: The whole idea we had was to get some folks to test out what it would look like to get user feedback from 61 | actual meetups, so we’re thinking maybe Toronto, New York, San Francisco (April?), Ben in Portland, we want to do is create a 62 | framework, I’ve been working with Sophie to put together a how-to, in addition we did put on the calendar we have two blog post, 63 | one here: https://docs.google.com/document/d/1Kr6A4CAPu8fkYJXaCGTOQWUluSriP0wfMFJMdXRACdg/edit 64 | * Twice a year is the right cadence for user feedback meetup (September, February)? 65 | * Tracy: Once we have a framework for this, all the meetups that are being run by local meetups around the world, feel like 66 | the owners and are going to do it themselves. 67 | 68 | ## Q&A, Other 69 | * **Follow-up/New issues** 70 | * https://github.com/nodejs/user-feedback/issues/115 71 | * https://github.com/nodejs/user-feedback/issues/113 72 | 73 | ## Upcoming Meetings 74 | 75 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 76 | 77 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 78 | -------------------------------------------------------------------------------- /meetings/2019-02-01.md: -------------------------------------------------------------------------------- 1 | # Node.js Foundation User Feedback Meeting 2019-02-01 2 | 3 | ## Links 4 | 5 | * **Recording**: https://www.youtube.com/watch?v=dpxTWAe1xl0 6 | * **GitHub Issue**: https://github.com/nodejs/user-feedback/issues/118 7 | * **Minutes Google Doc**: https://docs.google.com/document/d/1jnfZC_UucfrtOziEm99NgdH3mX8NVD40fplpCimz8JU 8 | 9 | ## Present 10 | * User Feedback Members: @nodejs/user-feedback 11 | * Michael Dawson (@mhdawson) 12 | * Tracy Lee (@ladyleet) 13 | * Dan Shaw (@dshaw) 14 | * Ahmad Nasli (@ahmadnassri) 15 | * Sofia 16 | * Mihai Ene-Pietrosanu (@mihaiep) 17 | 18 | ## Agenda 19 | 20 | ## Announcements 21 | 22 | *Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 23 | 24 | ### nodejs/community-committee 25 | 26 | * Individual Membership: Current and Past Members Survey [#375](https://github.com/nodejs/community-committee/issues/375) 27 | 28 | ### nodejs/user-feedback 29 | 30 | * Evolving General User Feedback by hosting an online Node.js Meetup [#82](https://github.com/nodejs/user-feedback/issues/82) 31 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 32 | * Survey for strong(er) typing [#61](https://github.com/nodejs/user-feedback/issues/61) 33 | 34 | ## Q&A, Other 35 | ### Notes: 36 | * Follow-up the meeting:6 new issues: #119,...,#124 37 | * Links: https://github.com/nodejs/release#release-schedule 38 | * Dan: Update from Joe Sepi: he reached out Matteo to finish the survey, and my feedback is, let’s try to align to the current: 39 | * Current and past members survey: this is behind other surveys release. 40 | * Michael: I guess the question is timeliness, is there a time factor in terms of we’re proposing already the individual membership 41 | program is part of the joint Foundation? I don’t think we’re going to wait for the survey at this point, unless we could get 42 | the survey turned around in a few weeks; it doesn’t mean that it’s still not worthwhile it might be something like we time with the 43 | launch of the new program or it’s a checkpoint along the way for implementing that new program. 44 | * Dan: this issue will be on Comm-Comm agenda next week 45 | * Issue 82: Node.js meet-up: the release date for the current is end of April, so on May 2- San Francisco Node (thirst Thursday) 46 | I’ve lined up to host James Snell. The plan is to have James, what’s new in 12, talk and use that for feedback session. 47 | * Ahmad: I’ve talked to the Toronto JavaScript group about what would they need and what would we help in terms of facilitating 48 | such a meeting. 49 | * Tracy: I started creating a guide for this, I already have a blog post in play for speakers who go to meetups and for people 50 | who want to host meetups. PDX: Michel/open source is willing to host the user feedback for us, he’s waiting for more details, 51 | but he’s open to that. 52 | * Mihai: When is the PDX meet-up? 53 | * Tracy: I ping him on Twitter and asked him when he wanted to do this. 54 | * Dan: On May 9 it might be a good choice and I can ask James to do that, and I’m happy to come. 55 | * Promises and stronger typing: Michael: Tierney showed interested in stronger typing;once we catch up on the existing list 56 | we can revalidate that somebody’s going to be willing to put together the questions, ask some availability. 57 | * Invite somebody from Marketing from Foundation for next meeting 58 | * Ahmad: Target Thursday April 25 for Enterprise meeting, 10 AM Pacific time 59 | 60 | ## Upcoming Meetings 61 | 62 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 63 | 64 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 65 | -------------------------------------------------------------------------------- /meetings/2019-03-01.md: -------------------------------------------------------------------------------- 1 | ## Node.js Foundation User Feedback Meeting 2019-03-01 2 | ## Links 3 | 4 | * **Recording**:https://www.youtube.com/watch?v=w3pMzh_D9t8 5 | * **GitHub Issue**: https://github.com/nodejs/user-feedback/issues/131 6 | 7 | ## Present 8 | 9 | * Michael Dawson (@mhdawson) 10 | * Ahmad Nassri (@AhmadNassri) 11 | * Dan Shaw 12 | * Tracy Lee 13 | * Kaelyn 14 | * Agri Abraham 15 | 16 | ## Agenda 17 | 18 | ## Announcements 19 | 20 | * Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 21 | 22 | ### nodejs/community-committee 23 | 24 | * Individual Membership: Current and Past Members Survey [#375](https://github.com/nodejs/community-committee/issues/375) 25 | 26 | ### nodejs/user-feedback 27 | 28 | * Schedule Enterprise Feedback Group Meeting [#122](https://github.com/nodejs/user-feedback/issues/122) 29 | * Next step is to create the draft communication to the members. Do plan on drafting this 30 | Weekend. 31 | * Also working on blog post which will be tied to the communication 32 | * Related Michael archived the enterprise-advisory-group repo. 33 | 34 | * Evolving General User Feedback by hosting an online Node.js Meetup [#82](https://github.com/nodejs/user-feedback/issues/82) 35 | 36 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 37 | 38 | * Survey for strong(er) typing [#61](https://github.com/nodejs/user-feedback/issues/61) 39 | 40 | ## Notes 41 | * Dan: April: current release of version 12 coincide with feedback sessions and work on blog posts and threads continuing with surveys. Action item: Michael will ping Joe asking about survey status. 42 | * Tracy: We have people from the foundation involved on the survey part. 43 | * Ahmad: Issue #122 Schedule Enterprise Feedback Group Meeting: next step is creating the draft communication to the members who want to be part on it. 44 | * Dan: my team from Paypal will be participate there; Netflix also has full approval. 45 | * Dan: for the next meeting we will invite James Snell/brainstorming about the topics we will discuss in May (San Francisco, Portland). 46 | * Tracy: Create a template for meet-up: organizer view? Speaker view? Node User Feedback slides “ What TSC wants from you. Here are 3 questions we’d like to ask…” Create more issues? 47 | * Michael: In the end we want to help people into the regular channels, basically Github issues, get the discussion around (for example) “what problems have you experienced upgrading, if they’re related to modules, we can point them to the package maintenance repo, if they’re related to de itself we can point them to the node repo, suggesting tagging with a certain tag (tag Upgrade Problems). 48 | * Ahmad: In the terms of sequence we asked about upgrade cycles first, then the packages, direct the potential “flood of noise”/ the right repo. 49 | * Tracy:(draft doc format) **Upcoming User Feedback Session Ideas**: 50 | * June: Workers? 51 | * Aug: Other technical issues? 52 | * Sept: Modules? 53 | * Tooling? 54 | * Package Maintenance? 55 | * Diagnostics? 56 | * How easy is it to get involved in the community? What’s working and what’s not? 57 | * End user topics-people using node : what are they struggling with? (I’m writing an app, 58 | what are my pain points in using node? 59 | * Dan: How can we track that back and have visibility into what we’re generating? How do we measure who run a session/measuring growth of the user feedback session? issue [#133](https://github.com/nodejs/user-feedback/issues/133) 60 | * Michael: As a group, we should review how much feedback, count of the number of comments that we got on these issues we’ve pointed to and correlation to the sessions that take place. 61 | * Agiri: WEB design survey? 62 | 63 | 64 | ## Q&A, Other 65 | 66 | ## Upcoming Meetings 67 | 68 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 69 | 70 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 71 | -------------------------------------------------------------------------------- /meetings/2019-03-15.md: -------------------------------------------------------------------------------- 1 | ## Node.js Foundation User Feedback Meeting 2019-03-15 2 | 3 | ## Links 4 | 5 | * **Recording**:https://www.youtube.com/watch?v=RG97WGS38SQ&t=2283s 6 | * **GitHub Issue**: https://github.com/nodejs/user-feedback/issues/137 7 | * **Minutes Google Doc**: https://docs.google.com/document/d/1CVwgWsUR2c4l2pjTBmgHfFkQkQTfeQneuvFZsl6RnI4 8 | 9 | ## Present 10 | 11 | * Joe Sepi (@joesepi) 12 | * Dan Shaw (@dshaw) 13 | * Michael Dawson (@mhdawson) 14 | * Ahmad Nassri (@ahmadnassri) 15 | * Mihai Ene-Pietrosanu (@mihaiep) 16 | * Tracy Lee (@ladyleet) 17 | * Agiri (@codeekage) 18 | 19 | * User Feedback Members: @nodejs/user-feedback 20 | 21 | ## Agenda 22 | 23 | ## Announcements 24 | 25 | *Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 26 | 27 | ### nodejs/community-committee 28 | 29 | * Individual Membership: Current and Past Members Survey [#375](https://github.com/nodejs/community-committee/issues/375) 30 | 31 | ### nodejs/user-feedback 32 | 33 | * Schedule Enterprise Feedback Group Meeting [#122](https://github.com/nodejs/user-feedback/issues/122) 34 | * Node User Feedback at Meetups [#115](https://github.com/nodejs/user-feedback/issues/115) 35 | * Evolving General User Feedback by hosting an online Node.js Meetup [#82](https://github.com/nodejs/user-feedback/issues/82) 36 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 37 | * Survey for strong(er) typing [#61](https://github.com/nodejs/user-feedback/issues/61) 38 | 39 | ## Q&A, Other 40 | 41 | ## Notes 42 | 43 | * Joe Sepi: following the Node core model, done with the “New issue” template. (Good job,Joe!) 44 | * Enterprise group meeting: April 25,2019 10AM Pacific time, Ahmad: the last step, before sending out an email, to the folks 45 | who expressed interest is making sure we have a blog post ready so we can point them to it and put it there; there’s a minor 46 | of listing them in the repository, I will ask their permission to do so at the meeting. 47 | (issue 123 https://github.com/nodejs/user-feedback/issues/123 ) 48 | * Tracy: after Ahmad will do the final review, will publish on the general Node blog (probably around 14-15 April) 49 | * Ahmad: naming the Enterprise group (after debating): will be Enterprise focus group 50 | * Tracy: meetups: we do have a full list of people that have agreed, 12 people: issue #115 (around the world). May 9 the first one? 51 | * Tracy: worked on the doc: “How to run a User Feedback Session as a Meetup Organizer or Speaker” 52 | * Dan: our meetings for all of April would shift from our regular Friday to Thursday because to cover the Enterprise session. 53 | 54 | 55 | ## Upcoming Meetings 56 | 57 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 58 | 59 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 60 | 61 | -------------------------------------------------------------------------------- /meetings/2019-03-29.md: -------------------------------------------------------------------------------- 1 | ## Node.js Foundation User Feedback Meeting 2019-03-29 2 | ## Links 3 | 4 | * **Recording**: NA 5 | * **GitHub Issue**: [#141](https://github.com/nodejs/user-feedback/issues/141) 6 | * **Minutes Google Doc**: [MINUTES](https://docs.google.com/document/d/16v2B0g0UdvPIwTgtJcRVqOFeYBrGx3C7hCFTvDMrNDQ/) 7 | 8 | ## Present 9 | 10 | * Dan Shaw (@dshaw) 11 | * Ahmad Nassri (@ahmadnassri) 12 | * Tracy Lee (@ladyleet) 13 | * Mihai Ene-Pietrosanu (@mihaiep) 14 | * User Feedback Members: @nodejs/user-feedback 15 | 16 | ## Agenda 17 | 18 | ## Announcements 19 | 20 | *Extracted from **user-feedback-meeting** labelled issues and pull requests from the **nodejs org** prior to the meeting. 21 | 22 | ### nodejs/community-committee 23 | 24 | * Individual Membership: Current and Past Members Survey [#375](https://github.com/nodejs/community-committee/issues/375) 25 | 26 | ### nodejs/user-feedback 27 | 28 | * Schedule Enterprise Feedback Group Meeting [#122](https://github.com/nodejs/user-feedback/issues/122) 29 | * Node User Feedback at Meetups [#115](https://github.com/nodejs/user-feedback/issues/115) 30 | * Evolving General User Feedback by hosting an online Node.js Meetup [#82](https://github.com/nodejs/user-feedback/issues/82) 31 | * Public User Feedback request - Promises [#77](https://github.com/nodejs/user-feedback/issues/77) 32 | * Survey for strong(er) typing [#61](https://github.com/nodejs/user-feedback/issues/61) 33 | 34 | ## Notes: 35 | * Short meeting this time, no recording. 36 | * Updates on docs from Tracy. 37 | * April (only) team meetings: moved from Friday to Thursday, 10-11PT. First meeting on 04/11 and 38 | second one on 04/25 Enterprise session. 39 | 40 | ## Q&A, Other 41 | 42 | ## Upcoming Meetings 43 | 44 | * **Node.js Foundation Calendar**: https://nodejs.org/calendar 45 | 46 | Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. 47 | 48 | -------------------------------------------------------------------------------- /meetings/2019-04-25.md: -------------------------------------------------------------------------------- 1 | ## NODE USER FEEDBACK SESSION 2 | ## 2019-04-25 Node Enterprise Focus Group 3 | ## Links 4 | * **Issue #144: https://github.com/nodejs/user-feedback/issues/144** 5 | * **Minutes Google Doc: [Notes](https://docs.google.com/document/d/15RDN7deM6wf2X271zpayrRSSnqdGO_1S0kTvfx5Agwo/edit#heading=h.d738zifwxt86)** 6 | * **Recording:https://www.youtube.com/watch?v=PhyHkdoQDac** 7 | 8 | ## Agenda 9 | 10 | * Gather feedback and insights on challenges faced by closed-source projects that use Node.js within the context of large businesses. 11 | * These challenges might not be immediately visible to the open source community, but they have a domino effect on all users. 12 | * The effects of change in the OSS domain to business operations 13 | * The cost of adoption vs. the total cost of ownership for Node.js application development 14 | * The capacity for Node.js to drive business revenue and curb cost burdens 15 | * Call for Actions: 16 | * Package Maintenance 17 | * Node Releases: better understand Enterprise plans of adoption and barriers 18 | * v6 goes EOL in 1 week 19 | * v12 released on April 23 20 | 21 | ## Invited 22 | * User Feedback Members: @nodejs/user-feedback 23 | * Enterprise Group Members: 24 | * Aaron Heckmann (@aheckmann) Paypal 25 | * William Blankenship (@retrohacker) Netflix 26 | * Adrian Maurer (@adrianmaurer) CGI 27 | * Joel Chen (@jchip) Walmartlabs 28 | * Keith Moore (@AntiqueSounds) HewlettPackard 29 | * Luke Browell (@lukebrowell) Sage 30 | * Steve Tannock (@Stv) Telus 31 | 32 | ## Present: 33 | * Ahmad Nassri (@ahmadnassri) 34 | * Dan Shawn (@dshaw) 35 | * Michael Dawson (@mhdawson) 36 | * Mihai Ene-Pietrosanu (@mihaiep) 37 | * Dominykas Blyse 38 | * Keith Moore (@AntiqueSounds) 39 | * Sumeet Kakkar 40 | * Luke Browell (@lukebrowell) 41 | * Brian Holt (@btholt) 42 | * William Blankenship (@retrohacker) 43 | * Steve Tannock (@Stv) 44 | * Aaron Heckmann (@aheckmann) 45 | 46 | ### Notes: 47 | * Thank you for participating in this meeting! 48 | * Intro 49 | * Ahmad: How big are the teams in your company and roughly how many packages/software distributions? In in Telus we had 500people 50 | with two third software engineers and 1700 software applications about 900 using Node.js. 51 | * Dan: At PayPal we are 22000 and 5000 engineers we are about half Node half Java. 52 | * Brian: we are about 131000 employees and Node it’s one of our biggest platforms. 53 | * Dominycas: the projects I’m envolved right now is fairly small for enterprise but we have very struct security and audit requirements. 54 | * Keith: I’m evangelist in HP for the Node.js at the enterprise level and working with a lot of clients using node, so my 55 | perspective is deployment scale and security type. 56 | * Luke: I’m based in UK and I work for Sage we’re a fortune 500 with significant accounting and financial service apps in the market, 57 | globally with over 50000 employees with over 2000 engineers. I’m a principal engineer in optimization team and I get to work with 58 | lots of different teams for most of the Node.js community lead within Sage. 59 | * Ahmad: Version 12 was just released. The pattern I’ve seen is large teams, the legacy applications don’t always get attention, 60 | how many people who are still running applications on v6 and knowing that v6 is EOL (end-of-life) in less than 2 weeks there is cost 61 | for the teams, I’m interesting to hearing if your companies have any interest or have surfaced any patterns in terms of keeping 62 | up to date with Node.Js security patches and releases and EOL for older versions of node. 63 | * Luke: In the terms of keeping up to day, keeping on top of the Twitter or distributions groups , so there isn’t a sort of single 64 | unified way of getting all of that information. 65 | * Ahmad: Is there anything Node project can do different in terms of not just announcing something and posting on Twitter but in 66 | giving you that roadmap and maybe a different file structure or different visibility that help you take that back to your teams 67 | and roll that part of your planning of your work. 68 | * Michael: The one thing I do want to that though is that beyond being on the repo which has the specific date, it has been every April, 69 | every October for like over three years, it’s very interesting people still don’t know that because that’s like part we’re trying 70 | to achieve. You can just plan for April and October. 71 | * Ahmad: But how does that roll into the work, like Luke you mentioned you are like an advocate internally and externally, but do you 72 | have an uphill battle trying to schedule upgrade work or actually trying to convince product teams to do any sort of upgrades? 73 | Do you have to assign budget to it? What is a typical process look like for a team of your size? 74 | * Luke: It’s generally based on either push or pull so the core would be if we need features that are only available in the newer 75 | runtime versions and push will be if it’s security related patch that we have to patch for. In terms of building those into 76 | the cycle what we do is build a little contingency into our planning and just accept the fact there’s going to be updates not just 77 | from node but from a whole range of other tools that we use. 78 | * Keith: Most of my customers are financial services so I think it’s a general trend the weight analyst is basically a very strict 79 | cadence and the bigger issue for more clients that I work with, is the cadence can’t be spread out too far so if the releases fall 80 | two or three behind, that becomes an issue. Security patches trump all the other stuff. 81 | * Michael: There is always going to be ad-hoc high security releases for things like open SSL has vulnerabilities, we are discussing 82 | internally whether something like a regular schedule for lower vulnerability security releases would make sense, so I’d be interested 83 | in this group input on that in terms of if we plan do those every say four months and roll things up in to them, so basically some 84 | things may come out later, some things may not come out at all until the next release, but that’s probably better than what 85 | we do today which is basically once we get a critical mass that we think is enough to make a security release even though they 86 | aren’t high priority ones will go ahead and do that. 87 | * Keith: In my perspective roll them up it’s a good idea. 88 | * Luke: It’s important to take all security patches and do the risk analysis on those. 89 | * Sumeet: One of the challenges we are facing at PayPal is that one of the recent security fixes reduced the header length and a 90 | lot of our internal teams depending on a high header length it went down to 8k, so stuff like that could be challenging could 91 | slow us down releasing some of the security vulnerability fixes. 92 | * William: We ran in something similar and we solved it by passing the flag to increase the size. 93 | * Sumeet: Yes, you have to include an additional flag in the infrastructure itself. 94 | * Luke: Another constrain in terms of fatigue on the engineers for changes and changes to way of working with different 95 | versions of node and that is largely dictated to us by some of the cloud vendors that we use in supported versions of the node. 96 | * Ahmad: There are a lot of Node.Js 6 dependencies or deployments out there in production how are you planning on addressing 97 | that in 2 weeks (EOL of version6)? 98 | * Steve: We identified about 25 packages still running Node 6 and like 20 of them can just get banned. 99 | * Ahmad: Have any of your organization or your development teams been able to articulate in one shape or form what is a total cost of 100 | ownership for Node.Js based application looks like or a formula around that? Given the complexity of dependency management, 101 | given the complexities of the web and backend and giving the complexities of knowledge management around those teams, 102 | there are lessons for Node project to take away, as part of documentation, as part of training materials as part of management 103 | solutions that the Node foundation can invest more and just create if they don’t exist, to help organizations. 104 | * Michael: I'd be interested in the specific thing that was mentioned which was that even turning the flag on requires rolling 105 | things out, so any feedback on small changes that might help make that easer. For example if you actually take the 106 | binaries vet them and could add a default configuration file if that would make that significantly more easier that’s something 107 | that would be worth exploring. 108 | * Sumeet: I think it’s a great point rolling a flag out, which means that when the node is launched, whatever it is launching 109 | it have to make sure that particular is passed in vs configuration which is easier to deploy. 110 | * Ahmad: Where do you spend most of your teams of time and effort, total cost of ownership, is it knowledge management, is it 111 | configuration, is it spinning up servers? 112 | * Dan: There is a pretty big delineation at PayPAl between the infrastructure teams that focus on rolling out our capabilities 113 | and the application teams to focus on building the applications with, those are separate workflows and distinct teams that 114 | are managed each of those things so it’s not in the same pool. 115 | * Luke: coming back to the question of total cost of ownership we tend that in a comparative way against other technologies 116 | and tools for which we have experience within the workforce and quite often one of the blessing of microservices and in general 117 | is that we’re able to kind of compartmentalize functionality based on those strengths of skills, but in terms of total cost of 118 | ownership we look at the tools and the biggest thing that I can sort of that a striking difference between working with node 119 | and with other tools is the fact that node it’s got this plethora of libraries that are fantastic for the choices of standard 120 | libraries are rich and varied so having a way of tracking what we as a enterprise organization users are standard node 121 | libraries is something we have to do outside of the side of npm ecosystem usually ends up in wikis or other tools and the 122 | review process around what we now accept there’s a library that we’re favoring within the organization is more manual than 123 | it feels like it should be, so from that perspective because we don’t have a very rich standard library that’s off the shelf 124 | and we have to sort of extend that ourselves with other libraries there is sort of a need there for being able to say 125 | “well these are the features are build in node and these are the libraries that this particular enterprise organization uses 126 | across the board so therefore you can get them from a private npm repo and they’re supported and they’re security checked. 127 | Its kind like of a hidden cost, but it is also great strength because you don’t have contend with something that’s 128 | in the standard library you don’t want to have, you just bring what you need. 129 | * Ahmad: What is the business impact of that? 130 | * Luke: Different organizations using libraries in npm the question is around whether we kind of provide some kind of badging 131 | to that when a significant proportion of enterprise consumers of node are using some libraries and we can sort of service that 132 | in a more visible way generally projects that are quite proud of who uses them they talk about themselves all the time in their 133 | github repos, but having that kind of data more actively surfaced in a kind of rating system would probably help. 134 | * Michael: I think that fits in the package maintenance team where the effort is to figure it out how we bring people together to make 135 | sure that the key modules that the ecosystem depends on are in a good state and the first challenge is always like what is that 136 | list of modules. You can come up with the top few but then when you go beyond that we needed the sort of the regular feedback and 137 | I think the enterprise you should figure into that. 138 | * Brian: You don’t want to stifle the creativity of the ecosystem; I don’t want to end up in like this more Java like scenario 139 | we like you have ten libraries and if you’re outside of that it’s like niche use case. 140 | * William: Something similar at Netflix, a quick audit of one of our code base showed that like the node modules the directory 141 | tree at about 1.7 million lines of code in it which at that point you’ve kind of reached a point of no return in terms of 142 | even audit the amount of code you’ve deployed and we’re exploring policy based and enforcement at runtime where you define 143 | acceptable behavior of this process is as opposed to exploring like trying actually find a way to systematically evaluate 144 | that entire directory. 145 | * Dominycas: You mentioned the number of lines of codes, do you remember how many modules that was individual packages? 146 | I did a similar thing, on the stuff that we actually deploy that’s besides all the other tooling but just the top level 147 | services that we do deploy they depend on around 2000 unique versions and in a week the drift of code basically I compared 148 | two sets to snapshots of the whole node modules across (20 repos or so) that’s 2000 unique questions there 3 or 4 thousand lines 149 | of changed code in a week, there is a case that some of them are reviewable, especially after you rule out certain modules. 150 | * William: I am finding 27 direct dependencies and 1500 indirect dependencies so the module tree kind of explodes 151 | once you go down there. 152 | * Luke: You can think all about those modules and you think about node the runtime and then you think about all the platforms 153 | and tools that we use around that, the dockers, they all have release cadence that we need to go and check out Twitter feeds 154 | and our approach is quite ad hoc so my question is: given that node now has fantastic link into that to the Linux Foundation 155 | side is there a way we can sort of standardize how we inform businesses about what versions of things are coming out when in 156 | a standard way, could we use a standard calendar format so we can have that information literally flying into our project 157 | management tools and allowing us to plan for the things we need to do over the next few weeks, where we see that these security 158 | updates coming in or we see that there’s a normal release cycle, I don’t think this is a problem that’s isolated to node, 159 | is sort of a more general approach to it. 160 | * Ahmad: Given that this group is the Node Foundation and whatever solution we can but propose or come up with the question is, 161 | will your business use that? 162 | * Luke: I think it’s about surfacing risk. What we can do is to ensure the information is available in a consistent form. 163 | * Ahmad: As representatives do you find any challenge in making the case for those type of investments and what are the 164 | challenges you’re facing? 165 | * Steve: everything at Telus relates around the business case for what it is better than what is currently there, c 166 | onversation about what at the enterprise level, new versions like new version node will enable to do offer for us, 167 | I think is a really useful thing that Foundation can have like a media package. 168 | * Ahmad: performance is a good example, so the teams can work on at every release of Node.js. 169 | * Michael: we already have a benchmark group who generates some charts, the challenges, all those things are very valuable, 170 | we would just need more people to engage to help them happen, because based on the current people who are involved we’re not 171 | going to be able to do that. The group is there, we just need more involvement if that’s one of priorities. 172 | * Luke: One of the things that we do is we benchmark ourselves, so we’ll run our unit tests and integration test suites. 173 | * Ahmad: **Cadence for this group? More than happy to do it monthly.** 174 | * Sumeet: interested in packages. 175 | * Luke: Maybe we can have like a major and a minor and then just having a more general catch-up that we draw bring agenda items 176 | up to the larger ones. 177 | 178 | ## Links: 179 | * https://raw.githubusercontent.com/nodejs/Release/master/schedule.json 180 | * GitHub.com/sindresorhus/awesome 181 | * https://benchmarking.nodejs.org/ 182 | --------------------------------------------------------------------------------