|
| 1 | +# Node.js Web Team Meeting 2025-10-27 |
| 2 | + |
| 3 | +## Links |
| 4 | + |
| 5 | +- **GitHub Issue**: https://github.com/nodejs/web-team/issues/56 |
| 6 | + |
| 7 | +## Present |
| 8 | + |
| 9 | +- Aviv Keller @avivkeller |
| 10 | +- Brian Muenzenmeyer @bmuenzenmeyer |
| 11 | +- Matt Cowley @mattipv4 |
| 12 | +- Augustin Mauroy @AugustinMauroy |
| 13 | +- Claudio Wunder @ovflowd |
| 14 | + |
| 15 | +## Agenda |
| 16 | + |
| 17 | +Extracted from **web-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. |
| 18 | + |
| 19 | +### nodejs/nodejs.org |
| 20 | + |
| 21 | +* Card Sort Session Results [#8234](https://github.com/nodejs/nodejs.org/issues/8234) |
| 22 | + * Aviv, explained what happened at the Card Sort |
| 23 | + * Brian, we need to analyze the data and look for patterns. Take that, and propose new article layouts |
| 24 | + * Brian, let's go over the general concerns |
| 25 | + * The navigation is too linear, however, there are many cases where this harms the reader (i.e. when a document contains a sub-document, like "Flame Graphs") |
| 26 | + * Aviv, explain the difficulty of getting to certain articles |
| 27 | + * Matt, being linear shows users a general order, but we _should_ have sub-articles |
| 28 | + * Aviv, the downside of linear articles is that things fall under multiple categories |
| 29 | + * Brian, the learn articles look like a pathway, which they aren't really, since you don't *need* the articles to use Node.js |
| 30 | + * Aviv, our CSS styles promote that idea that it's a pathway |
| 31 | + * Matt, our articles are written in order (ie TypeScript) |
| 32 | + * Aviv, No group echo-ed our current Getting Started |
| 33 | + * Brian, a "learn hub" would be really nice |
| 34 | + * Matt, "Parent Articles" groups would be nice for grouping |
| 35 | + * Brian, lets cut an issue for this concern |
| 36 | + * The order of categories prioritizes categories that might not be as helpful to the reader (i.e. Test Runner should be greater than Diagnostics) |
| 37 | + * Matt, things like teach "new" users information are more important than advanced deep-dives |
| 38 | + * Aviv, a good first issue is to move content around |
| 39 | + * Many articles have their own "Intro" page, maybe a general "Intro" section would be nice? |
| 40 | + * Brian, routing page |
| 41 | + * A lot of articles are out-of-date, which leads to incorrect content |
| 42 | + * Aviv, a lot of articles are *old*, and are very out of date |
| 43 | + * Brian, this is not meant to be a MDN resource |
| 44 | + * Matt, a quick fix is to put the file change date in the frontmatter |
| 45 | + * Brian, a [review system is proposed](https://github.com/nodejs/nodejs.org/issues/7295). We (the Website Team) shouldn't be the reviewers, but rather delegate to working groups |
| 46 | + * Aviv, maybe at the next summit we make the collaborators do some of this |
| 47 | + * There is a lot of content, and it's doubtful that many users have read the entire thing. |
| 48 | + * Aviv, some articles are **long** |
| 49 | + * Matt, the content is _very_ useful, but it can be split up. |
| 50 | + * Aviv, the article doesn't even mention `npm publish`. It should be its own section |
| 51 | + * Matt, the "TypeScript publishing" article can reference this (as a section) |
| 52 | + * Matt, we should be a bit more opinionated about ESM/CJS. Recommended paths and what-not. |
| 53 | + * It would be nice to add an entire "HTTP" section, with fetch(), node:http, and the various other ways to make network requests |
| 54 | + * New article -> New issue |
| 55 | + |
| 56 | + |
| 57 | +* Add lint rule ensuring that a publishing date is valid [#7845](https://github.com/nodejs/nodejs.org/issues/7845) |
| 58 | + * Aviv, https://github.com/nodejs/nodejs.org/pull/7838 was meant for the future, and we published it, not knowing it wasn't supposed to be published |
| 59 | + * Brian, should the date be content-only, or should we hide posts until a given date? |
| 60 | + * Claudio, it's fine to keep as is |
| 61 | + * Matt, a lint rule is a solution to a problem that shouldn't be a problem |
| 62 | + * Aviv, it's going to cause a problem for everyone with a valid blog post |
| 63 | + * Claudio, the _max_ we should do is a CI/CD comment |
| 64 | + * Matt, the PR had _zero_ indication of a future date, and should have |
| 65 | + * Brian, this is an edge case, since the content was semi-embargoed. |
| 66 | + * Matt, the author is responsible for their own date and publishing information, unless it's a repeat problem. |
| 67 | + |
| 68 | +### nodejs/web-team |
| 69 | + |
| 70 | +* Meeting with Microsoft Advisor [#53](https://github.com/nodejs/web-team/issues/53) |
| 71 | + * Skipped, as the advisor could not join |
| 72 | + * Aviv, I'll reach out privately and resolve the issue |
| 73 | + |
| 74 | +* Create Means for Private Communications [#14](https://github.com/nodejs/web-team/issues/14) |
| 75 | + * Matt, leaning toward Slack channel over repository. Do even need this? |
| 76 | + * Brian, we really don't need this that often, and the topic specific channels work fine. |
| 77 | + * Matt, other teams do it, but they have a lot more need than we do. |
| 78 | + |
| 79 | +## Q&A, Other |
| 80 | + |
| 81 | +* Azure Credits |
| 82 | + * Matt, we should see what nodejs/build needs |
| 83 | + * Claudio, we have _another_ Azure account with legacy credits, and should migrate over here. Ours are just sitting there. |
| 84 | + |
| 85 | +## Upcoming Meetings |
| 86 | + |
| 87 | +* **Node.js Project Calendar**: <https://nodejs.org/calendar> |
| 88 | + |
| 89 | +Click `Add to Google Calendar` at the bottom left to add to your own Google calendar. |
0 commit comments