| 08:00 | <Aki> | Hello delegates! Please get your transcript edits, summaries, and conclusions written TODAY! TODAY! Notes are due from me on Friday. I have put them off as long as I can. Honestly it's not really ideal that I have to cram it all in to one day but as long as everyone else procrastinates I'm kinda stuck 😕 What is a summary? Mostly written before you even present, it summarises the presentation and any interesting details from the subsequent conversation. What is a conclusion? Any decisions that were made at the end of the agenda topic, along with any conditionals or relevant details. And the rest? Find your TLA and make sure everything you said was accurately represented by the transcription. Find conversations you were a part of and see if any missed TLAs (often, but not always, represented by |
| 08:02 | <Aki> | And for my sake: If you don't get them done today, it's better you make an attempt at doing them tomorrow than not try at all. It might be too late, but it might save me an hour of trying to read a transcript and poorly summarise. Or a future reader an hour of reading just to realise the information they're seeking isn't in that section. |
| 08:05 | <Aki> | Also, thank you to everyone who's already gotten to this, you're wonderful. |
| 08:27 | <Aki> | Aurèle Barrière: You're so on top of things that you have two summaries and conclusions. Could you help me understand how to format them? |
| 08:50 | <Zb Tenerowicz (ZTZ/naugtur)> | |
| 08:52 | <Ashley Claymore> | We shouldn't link to the notes here |
| 08:52 | <Aki> | oh wait that link shouldn't be here |
| 08:52 | <Ashley Claymore> | Yeah. This chat is public |
| 08:52 | <Zb Tenerowicz (ZTZ/naugtur)> | oops. sorry. didn't know that. |
| 09:17 | <Michael Ficarra> | Fixed. I wrote the summary/conclusion at the bottom and it looks like someone else had already (or has since) written one at the top. They're merged now. |
| 09:18 | <Aurèle Barrière> | Thanks! We had written one with @cpitclaudel:epfl.ch yes! |
| 16:16 | <Michael Ficarra> | I really like this Bytecode Alliance AI Tool Use Policy (adapted from LLVM, itself adapted from Fedora Project) https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.md |
| 16:17 | <Michael Ficarra> | I think it is aligned with the spirit of our own AI policy, but spells it out in more detail and provides justification |
| 16:18 | <Michael Ficarra> | any thoughts on replacing our AI policy with something similar? |
| 16:20 | <bakkot> | Opposed, I don't want to read AI prose whether or not a human vouches for it |
| 16:20 | <bakkot> | Code is a different matter |
| 16:26 | <Michael Ficarra> | how about scoped to code contributions? |
| 16:29 | <bakkot> | Our AI policy doesn't technically cover code at all; I might be ok with adding something like the above for code, but most code contributions are test262, and adding more work for test262 reviewers (in the form of more submissions, from contributors using LLMs) is probably an anti-goal |
| 16:29 | <Michael Ficarra> | like technically this PR violated our AI policy in its description, but the code contribution did not: https://github.com/tc39/ecma262/pull/3865 |
| 16:32 | <Michael Ficarra> | but I don't want to review code contributions that the author did not review themselves |
| 16:33 | <Michael Ficarra> | and I think it's a much nicer experience for a contributor to receive an explanation of why exactly that's antisocial and unhelpful behaviour instead of just a sentence or two saying that it's unwelcome |
| 16:51 | <bakkot> | is spec text code? debatable |
| 16:51 | <bakkot> | I agree that it would be good to have something more expansive to point people to though |
| 16:54 | <ptomato> | I automate some writing of test262 tests using LLMs but with my reviewer hat on, I haven't found the output to be good-quality enough to use without me editing it. nonetheless, it's often helpful. I wouldn't want to forbid others from using it responsibly if I believe I can do so myself, however, a large portion of our review backlog consists of LLM-generated PRs adding coverage for fairly low-priority edge cases (which would require deep-diving into the spec to understand if they are really correct) |
| 17:06 | <bakkot> | yeah, I am fine with people sending LLM-authored PRs if they're sufficiently competent but that's not really a policy you can reasonably write down |