| 01:25 | <devsnek> | someone might help if it was a wiki |
| 06:38 | <sideshowbarker> | devsnek: https://github.com/mdn/content/edit/main/files/en-us/web/javascript/reference/functions/get/index.md |
| 06:42 | <sideshowbarker> | The source can be edited there directly — and that source is in Markdown, so it’s now functionally the equivalent of a wiki editing experience. Or better, really. And from there it’s literally one button push to submit the update contented. |
| 06:44 | <sideshowbarker> | And yeah of course the big difference is, rather than that button push making the change immediately go live in the production site, it creates a PR and requires the content to then be scrutinized for technical accuracy and proofreading. |
| 06:49 | <sideshowbarker> | But that’s a feature, not a deficiency. The previous wiki system, while it made things easier for contributors with a very high level of JS domain knowledge to get their changes directly into MDN without anybody standing in their way — it also made things easy for contributors without very good JS domain knowledge to get a lot of suboptimal and outright-wrong changes directly into MDN without anybody standing in their way. |
| 06:53 | <sideshowbarker> | And so now we’re somewhat left with a big ongoing opportunity cost of contributors needing to spend time correcting problems in content that made its way in with zero review back in the wiki days — time those contributors could maybe be spending instead on things like writing new content for newer JS features that, so far, are undocumented or (under-documented) in MDN |
| 06:53 | <sideshowbarker> | |
| 07:16 | <yulia> | The MDN team did a really amazing job with the migration, plus github is a workflow most developers are familiar with already |
| 07:51 | <yulia> | Does anyone recall how / why this stalled? https://github.com/tc39/proposal-setmap-offrom (pinging bakkot as he most likely knows) |
| 15:30 | <Domenic> | Does anyone recall how / why this stalled? https://github.com/tc39/proposal-setmap-offrom (pinging bakkot as he most likely knows) |
| 15:31 | <bradleymeck> | yulia: last i saw on this kind of stuff was from leobalter I believe, there was a lack of agreement on need (isn't there always) / concerns about expanding API area without usage demands |
| 15:31 | <bradleymeck> | so... pretty close to what any Set/Map thing seems to face |
| 15:34 | <bakkot> | I am still fond of it; I'm more likely to bring it back if we get consensus on the extent to which we intend to support subclassing builtins (relevant because, does (class extends Set { add(x){ } }).of('element') invoke the subclass's add method?) |
| 15:36 | <bakkot> | Given that people were only lukewarm on the proposal, I didn't really want to deal with the fight about subclassing again for this proposal's sake |
| 15:38 | <bradleymeck> | if it helps, Symbol.species once again was a way to get a bug bounty |
| 15:38 | <bradleymeck> | I'm quite skeptical on this whole subclassing builtins, but I've said that before |
| 16:59 | <leobalter> | I recall it stalling because people thought it wasn't well-motivated. Array.of/from exist because the Array constructor sucks. The Set and Map constructors are good already and adding Set.of(x, y)/Set.from(iterable) as a duplicate of new Set([x, y])/new Set(iterable) was not wanted. this captures well the feedback received and I'm yet to build a better explainer, unfortunately with no cycles to prioritize this work so far. bradleymeck yulia bakkot it's up for grabs if anyone wants to champion it, otherwise I hope I can eventually find someone from my org who wants to do it. |