PRs and issues triaging

Speaker 1: I don't like it, but are

Speaker 2: we live yet?

Speaker 1: I think we are live. My zoom is thinks we are live.

Speaker 2: How are you switching to the French accents now?

Speaker 1: That's that's just how I speak We

Speaker 2: are live. Great. Hello.

Speaker 3: Hello.

Speaker 1: Hello.

Speaker 2: Hey Sage. Hey Baptiste.

Speaker 3: Hey Tibo. Hey Baptisse.

Speaker 1: Hey Tibo.

Speaker 2: Thank you for joining me in this edition of the weekly white tail review.

Speaker 1: Weekly White Tail Review.

Speaker 2: Give us a better jingle.

Speaker 3: That's the best you can get. You mean there's something better than that?

Speaker 2: Oh, I know you love the Django chat, Django Sage.

Speaker 3: I think it might be copyrighted. I don't know.

Speaker 2: Do you watch uh Django chat as well, Baptiste?

Speaker 1: I don't think I've seen a single episode. Is that when a bunch of dudes come to talk about Django?

Speaker 2: It's not just dudes. That's not fair. I I think they're really good actually at uh having a diverse uh range of panelists But uh the the key hosts I suppose are dudes. It's only the guests that they get to mix and match a bit.

Speaker 1: The guests are usually the best part of uh any uh Internet.

Speaker 3: Are you the guest today?

Speaker 1: Yes, that was the yeah, that was the joke.

Speaker 2: We're always glad to glad to have you. What are we doing today? Sage, tell us.

Speaker 3: Oh well, I think you said the title just now.

Speaker 2: Yes, I did. PRs

Speaker 3: and issues are we doing

Speaker 2: are we doing PRs or issues first?

Speaker 3: I mean Looking at the PRs count on white tail, it has gone up since last time, I can I think. We're no longer under the hundredth mark.

Speaker 2: Oh no The critical below 100 mark. Can you tell us what we care about? Why we care about being below 100, Sid?

Speaker 3: Well, I mean ideally we would like to get in as many contributions from other people as we can, right? And yeah, the more number means that we haven't got around to merging them or at least closing them if if we don't want to merge them. So that means we have contributions waiting for reviews and that's not ideal because we want our contributors to get their code in, right?

Speaker 2: Yeah, I guess, yeah, fundamentally it's about contributor experience, making sure that um people who invest the time to work with us, make it as smooth as as possible. But it's definitely challenging for a project like Wagtail. Yeah, 110. It's definitely been higher in the past, but also much lower recently. I think we almost reached 90, right? As of um like a couple of weeks ago.

Speaker 3: We might even hit 89.

Speaker 2: 89, oh my god. Do you keep tabs, Baptiste, on like pull request counts on projects like this? Do you think it matters much as like a signal of project health or whatever?

Speaker 1: I mean it's a it's a tight balance, right? Because if project with zero pull requests is like, well nobody cares. But a project with 2,000 open pull requests

Speaker 3: Nobody cares either.

Speaker 1: Sometimes you care too much, you know, and then like you you get paralyzed by the amount of like it just seems completely daunting to try and claw back. So it's it's tricky.

Speaker 2: Yeah. This uh insights view from GitHub I think is a good summary of where we are at, um which is that We do have lots of PRs merged on a regular basis by a few people, but there's definitely way more people opening new PRs. And I guess right now in particular, um, we suspect we are seeing a lot of uh interesting contributions. from people expecting to join the Google Summer of Code program that is coming up in um I believe about like two months we'll be starting like official contributions from people around specific product ideas. Um but well ahead of the official timeline

Speaker 2: people already are trying I suspect. to build up their contributor profile basically on on those projects. I don't know if we have anyone watching this right now who takes part in Google Summer of Code. Um we do have like a public expression of interest. Um, Fred, for our potential participation this year? And the only thing to do in there is uh submit the the form that we have at the top. And there's already 250 people who have submitted that form. So there's definitely interests out there. Yeah, how much it correlates with what we're seeing here, I don't know, but I suspect it does. Should we look at a few pull requests?

Speaker 2: Maybe let's start simple and uh look at this one that's just been approved and we can switch over to something that hasn't been approved yet. Maybe I can ask you both to pick one that you think is interesting to look at together. And uh once I'm done with this one we switch to yours? How about that?

Speaker 3: What do you mean by interesting?

Speaker 2: I'll let you be uh creative, Sage.

Speaker 3: Okay.

Speaker 2: Oh you've just you're the one who approved it, okay. Mmm uh yes, so this pull request I opened yesterday so I know it pretty well. First steps of triaging for something like this would be to add the labels, but since I'm the one opening it, I already did that. I think I might have missed a needs review label, which is what we use to um I guess um denotes the status that the pull request is in and um yeah say you already picked it up and you have some feedback Um reuse existing variables. Root doc.

Speaker 2: Oh. I suspect Sage that the Sphinx root dog isn't gonna be aware of read the dogs.

Speaker 3: Maybe, but um it says it's used for the path to function and if you click on if if you go back to the PR The line just above the

Speaker 2: spike too.

Speaker 3: And if you look at the Avenged website, that static file is hosted under the um

Speaker 2: version

Speaker 3: like language and version yeah

Speaker 2: okay so you're definitely right um

Speaker 3: well i haven't tested it so

Speaker 2: Yeah, I'll do that. Um and I think this is the kind of thing that I definitely don't think I need to test locally. I'd much rather see them the preview in our read the docs preview environment. So I'll make that change and we'll see what happens. So we'll mark this as needs work. Um it definitely works as is but might as well make it right. How did you know about root doc? I like tried to look this up and just couldn't find the variable.

Speaker 3: I could I it was it took some time to find the right page on things, but your code where you put page name um uh I guess that put me in the right direction because I need to get a list of all the available available uh variables uh in the context by default And yeah, I tried to look for like URL or some something similar or like also I I know about this path to function, so I uh looked it up and see whether it can be used for the same thing.

Speaker 2: Yeah. That's great, thank you. So that's our three edge done and yeah I'll take a look at the proposed changes and hopefully We'll be able to by the end of this stream test a new version and merge this.

Speaker 3: I just realized even sorry, I was a bit distracted by GitHub's UI. Um it kind of uh it kinda has the dynamic um saving of of the labels state, right but when you change the labels while you scroll after you scroll down it disappears and it went back up because is I think the the UI state is refreshed from the server. So if you maybe if you reload the page And then you scroll down. Wait, I thought it was, is it not

Speaker 3: sticky? Oh, you you were interacting with it. Never mind. Yeah. So if you if you have it open and you scroll down, I think. Wait. I swear I saw it all the way down. It was there, but Okay, never mind.

Speaker 1: It's just uh A -B testing gaslighting.

Speaker 2: Entirely possible. And my refined GitHub has also been in the way a few times. One of the ones that I spotted recently is um Refine GitHub, the extension, it has this approved now UI. Like the YOLO mode, and that definitely not something that GitHub is itself has let's keep all reviews and just make it as easy as possible to hit approve. Um anyway. Um do you have a PR for us or should we look at the next one in the list?

Speaker 3: Well I mean this one.

Speaker 2: Small typo, great.

Speaker 3: This is a quick one. And

Speaker 2: you've already figured

Speaker 1: I think this is a great example of like a pull request where Doing it yourself as a maintainer would take orders of magnitude less time than trying to get a contributor to do it.

Speaker 3: Yes, exactly. Because

Speaker 1: the contributor correctly identified there's a typo But like it's like a three character fix and two of them are wrong. Essentially it should have been just a one character fix. But

Speaker 2: we can get it done. Look badists. Three, two, one I can edit the pull request.

Speaker 1: Yeah, but like that's exactly what I mean. It's it's very easy to do it yourself. You can edit pull requests, you can push to the branch, you can push to commit, you can just like do it in your own pull request, but how much of an investment do you like on the contributor do you make? Do you want to teach them how to edit their pull requests? Because a lot of people who are new to GitHub or even Git Like they don't really know that you can just make another commit or and so as as maintainers, you know, you have to uh spend some time like part of your responsibility as a maintainer I think is to educate new contributors and You know, to bring it back to everyone's favorite topic, I think in an age of LLMs and and AIs and stuff, I think it's kind of a it broke something in there

Speaker 1: because If you saw someone making big requests and responding to changes, you could assume that they were interested in learning things. But nowadays it's hard to distinguish between an LLM generated pull request and then you want to invest time in in teaching a person but you're not actually teaching a person it's just Sometimes people are gonna take your feedback and put it straight back into their favorite LLM and everyone is a loser here, right? So I think this is a In this case, my spider spider sense spider sense is like this is probably a genuine person who is making contribution, probably not uh LLM assisted.

Speaker 1: And I think Sage is a comment is very good. But I find it typical of like this. Or I I think it's a good demonstration of like Being a maintainer is often a very like there's there's no tech involved here. It's mostly about communication and willingness to teach people because you never know who's gonna be a future contributor My first contribution to open source to was to Django and I fixed a one-character typo in error message I still remember. This was my my intro. And I'm sure it took the maintainer more work to baby me through my contribution process rather than fix fix it themselves.

Speaker 1: But sometimes the The investment pays off place a bit of a gamble.

Speaker 3: Yeah , well said. And also, um, yeah, that that's also one of the reasons why I just left the PR as is because I would usually In this case, it's clear what the next steps are to uh get the PR to be in a good good enough state to be merged. I would wait like a few days for the contributor to make the changes and um for me to merge it because but but if it's a regular contributor or someone who has contributed in the past it's usually uh like they would be happy with the changes anyway so I would just do it and get the get the thing merged

Speaker 3: because uh they've already known uh they they already knew how how to contribute right and in this case this is this person's first VR well there's actually a bit of background to this If you look at uh this user's PRs to White Tail, there have been a few. It's just, this is the one that is close enough to be merged.

Speaker 2: I think I've seen their name on Slack as well.

Speaker 3: Yeah, but the previous PRs, I just I just don't understand what exactly they were trying to do, to be honest.

Speaker 2: Yeah. So you would would you would rather they come back to it even though it's that that simple of a change?

Speaker 3: The thing is the It's because that's the only thing that the PR changes. If it changes a few things, uh like a lot more things, and then there's just this one bit that's um preventing it from being merged, I would fix it immediately. But in this case, like what what the teeth said about it being a three-character change and two of them are wrong. So That's like more wrong than right. So you want them to at least learn to make better pull requests next time?

Speaker 2: Yeah, I feel the same, but I feel like personally if it seems like I can get it right with not much extra time compared to just providing the feedback. I'll probably provide the feedback like you do and just get it over the line. And I would assume they would learn these same amounts.

Speaker 3: Also I th I think what I want to see is at least for them to respond uh and see the suggestions that I made. So it's not just like uh I don't know it what's what's happening behind the screen. But there's a chance that somebody will let's say uh if they made this pull request and then I fixed it and then I just merged it, they would think they didn't uh like that pull request was good enough as it is to be merged. So they they had a different idea of what is the level of quality that we want because like yeah they if if they didn't see this uh review comment and

Speaker 3: they just see it b uh merged. That's uh yeah I I don't want them to get the wrong idea.

Speaker 2: Okay It is trianged.

Speaker 1: I agree with Sage. Also one thing I I wanted to uh point out is that the what they're fixing is not such like it's not a huge deal right um the it's not a broken link it's not preventing anyone from working like We wrote or someone wrote panels group instead of panel group. You know, it's obviously it's an error, but it's it's not really preventing anyone from working or exam break. So I think giving it some time is is the right call here and seeing if the contributor responds and training people to get in the habit of following up on pull requests. We see this a lot, I think, as maintainers of people who make a pull request.

Speaker 1: You write a comment and then they never come back. And so using this a bit of as a test of like are they gonna see that you wrote a suggestion? Do they know how to commit suggestion? Do they you know I think this is a a good exercise in being a good uh citizen and understanding how requests work. I think giving it some time before intervening is the right call, even though it takes more time now. I think the hope is that it will save time in the future with this contributor.

Speaker 2: Amen. But it's it's tricky

Speaker 1: because it's like it's such a tiny pull request and then Obviously Sage has not a lot about this.

Speaker 3: And by leaving that comment, you might as well have done it already, right? It would have taken me less time to make the change and merge it than writing out that comment.

Speaker 1: Yes. There's so much invisible work like from from if you just see the pull request, you don't see all this work of thinking about Do how much investment am I willing to make? Like you're trying to imagine how it is from the other's perspective, you're trying to guess their level of experience. So there's there's a whole amount of of work that's invisible here.

Speaker 2: We have another documentation change that has gone through a similar process of suggesting some changes and the person has come back to it. That would be interesting. I don't know how much we want to look at the details of the feedback back and forth. I think I'll just uh put the link in the chat for people who wanna look at this. in their own time without being distracted by um my scrolling up and down. I see we have lots of people watching this so definitely feel free if you have comments along the way reactions. Joel, it's good to see you Joel Chol is definitely one of those contributors who we're very happy to have spent time with because

Speaker 2: I don't know just quality work. Great. Values alignment. Um Sage, have you seen the issue that this pull request is about before?

Speaker 3: I think so, yeah.

Speaker 2: I'm surprised what's going on here. Why does the diff

Speaker 3: It's usually because of Windows CRLF versus LF. Line endings.

Speaker 2: Line endings. What's the simplest way to fix that?

Speaker 3: Um in your text editor on the bottom right there should be a number option to convert.

Speaker 1: But would it go away here if you hit the white space changes?

Speaker 2: Probably would you right?

Speaker 3: Probably.

Speaker 1: But isn't there uh don't you have a linter that checks for line endings?

Speaker 2: Uh we have um we have a linter and we also have I believe an editor config file who that is responsible Responsible for sorry typing the wrong thing. Responsible for making sure people's IDEs are configured for line endings uh but it's always possible that someone uses um way to edit the file that doesn't support um this tooling

Speaker 3: Or lem

Speaker 2: I think it's the same as like if it was human generated, you know, some LLMs will know to respect the editor config and some will not. I don't necessarily suspect LLMs to use like Windows line endings probably what would happen is um yeah anyway I don't want to speculate too much I think this might be a bit too involved actually for us to review in a triage session like this. Unless you wanna invest the time into it. How do you feel about it?

Speaker 3: I think I would rather review it separately.

Speaker 2: Yeah. Okay, so yeah, just adding the labels. Seems like all the information is there for it to proceed. It's just

Speaker 3: add the label reference index. Oh, it's already sorry.

Speaker 2: Way ahead of you.

Speaker 1: For me, I also want to say that as a contributor, I often try to minimize my diff. So if I open a pull request, I will always go look at the div view and make sure there's no noise. Sometimes it's unavoidable, but if like I think it really helps the the reviewers to try to Make sure that in the diff uh in the files change tab only relevant changes show up if you see something that shows up there that you didn't intend or that isn't relevant here I would try to find a way to remove it before asking for a review.

Speaker 3: Yeah, I mean I think in general you really should review your own PR before asking for people to review.

Speaker 2: Yeah.

Speaker 1: Yeah, but sometimes you don't you don't know what it means to review your own own PR.

Speaker 2: Yeah

Speaker 1: But I think trying to minimize uh the changes is always good advice.

Speaker 2: Yeah. In my opinion. I mean in addition to the noise when reviewing, we also have a really strong need for a clean git history. No , like it has to be clean at all costs, but if we can catch things as part of the contribution process, it's definitely worthwhile. Um this Seems like another one where there's plenty of feedback for the person to get back to in due time. And I see there is feedback from our colleague Matthew

Speaker 2: already. So I think this is just a matter of adding the right labels. Always like to compare with the issue as well, see if um we use the same labels here and there. What do you think if I decide to use AI to automatically label all of the upcoming issue incoming issues and pull requests, would that make you happy or sad?

Speaker 3: I need to see how accurate it is, I think. I'm not sure which one is more useful. Not ha uh which one is worse, I guess. Um not having the labels or having incorrect labels.

Speaker 2: What do you think, Baptiste?

Speaker 1: Well how do you use labels in practice?

Speaker 2: Good question.

Speaker 1: They look cool, like it's very colorful, but do you are they part of your process?

Speaker 2: Um So I think for pull requests it's really most important to use our status labels. that in this kind of uh triaging sense, you then know whether to invest time into a pull request based on whether there's work expected from a maintainer or from the person making the pull request. For the issues, the like like the theme thematic areas, components, labels we have are much more useful to triage what quite what is quite a big backlog so that you can find um common themes

Speaker 2: or you know if someone asks me like oh I really wish API support was better in Wactel then I can find the relevant label and get a really strong sense of exactly what type of improvements they might be after. I'm sure this is you know like really obvious but um We do have many people suggesting the same things or reporting the same issue multiple times. So being able to access those past reports is um really crucial Yeah, so you know practically speaking, uh it's something that is really useful but does take a lot of time. Probably on the order of a minute per issue, a minute per pull request.

Speaker 2: Um we have on the order of I'd say probably like 30 pull requests and issues per week. Maybe a bit less, maybe like 20. So 20 minutes per week, it's not nothing, but times a whole year, it it does add up. And um I think to Sage 's point about uh labels being wrong, uh definitely humans get it wrong pretty often as well. Um Yeah. Does that help?

Speaker 1: I mean the with the AI the risk is uh or not the risk, but I think The motivation is often that you want to solve a task that takes you a lot of time. And usually if you're gonna use the eyes because you don't care too much about SHC's errors or You know, it's not uh something that you find. You can't uh you can guarantee its correctedness, so you can't use it for things where it's very important but as you say here humans also make mistakes uh if those mistakes can easily be corrected by human And if there's no risk that, for example, it would close issues or give them a category that would make it

Speaker 1: disappear into the ether, never to be seen again That could be a like if an if an AI incorrectly labels an issue and then no human ever gets to see that issue again, it could be a problem. I'm not sure what processes you have where it could happen so in this case it could be a good use case if you think it saves time and the potential for uh negative outcomes is low maybe it's good on maybe it's also worth to do a time box try tryout like try it for months and then reevaluate

Speaker 2: yeah

Speaker 1: How would that work in practice? Is this a feature GitHub provides or would you write a custom bot or

Speaker 2: um they have some like RND to implement this? They have this um This thing called continuous AI. I guess the naming here is to parallel this with continuous integration where you have like AI helping you continuously with different aspects of the project. And one of the like RD things they do under that umbrella is um automated triaging, like adding labels. Um Yeah, there's there's three things under the continuous triage. Label, summarize, respond. Label. At least to me, it is pretty clear that AI can do it just as much as good or even better as humans.

Speaker 2: I don't agree with you, but it's necessarily worse because it's AI. Summarize and respond to issues, definitely not. Definitely humans, I would assume, would do a much better job at that, uh, even if it takes time. I think right now like UK there's some automated support in uh in GitHub Actions as well based on simple keyword matching, like oh if the issue mentions API. We can add the API label, but you can clearly see how that's just way too basic to be worthwhile. Um yeah, I'd love some kind of um AI detected in the PR label as well.

Speaker 2: Sage, you're very generous to let that this PR be, because it's definitely not the right fix. In addition to

Speaker 3: I I was really tempted to just close the PR.

Speaker 2: Yeah, this is why we do triage together, you know, because one of us can be like nope We have to spend our time elsewhere. Um Yesh, if you're watching this, I'm really sorry. This is just like not helpful. It at least from my perspective without knowing. It looks like something that someone put very little effort into. They just asked their LLM to fix an issue from our backlog. And really what's missing from this more than anything is some sense that it's actually a solution that's been tested and that we're not arriving on this just on a hunch. like uh an AI would have no problem pretending like oh definitely 300 milliseconds that has to be the answer.

Speaker 1: But they they check the box that they verified that it fixes the issue.

Speaker 2: Yeah, they checked the box. Thank you. Yeah. I um

Speaker 3: but how? There's no screenshots, no video no screen recording and mind you headless setup with white tail is not as easy as just starting a new white tail project so For a new contributor. I'd really like to see how they set it up because I'd also like to uh reproduce the the issue locally because I haven't been able to reproduce that issue even the reporter said so

Speaker 1: that's one of the things I find the most useful in in a pull request or contribution or even a review is just saying what you've done. So you don't you don't just say oh I verified it works but you said I verified it works by doing this or if you're using an LLM maybe include the prompt say I've used a an agent and LM to help me with this. Here are the prompts I use. Because as a as a reviewer, you essentially want to reproduce what they have done. And if you withhold that information, you kind of make the you push a lot of the work onto the reviewer. Either the reviewers can have to duplicate some of the work you've done or uh

Speaker 1: just try to guess uh and people telling you what they've done it's like a superpower like much easier to review

Speaker 2: It is a superpower. Um First step here will be to reproduce this issue. I would recommend Yeah, so definitely like I'm not opposed to someone using AI for this. Um just you know Sharing the right information at the right time, giving us more confidence that as you said, Batist, we're not gonna like they don't offload too much of the actual work of checking what happens to us

Speaker 2: Good confidence, it's the only option. It's okay I think um language could be a bit better here, but

Speaker 1: You mean using like a superior language to English?

Speaker 2: I mean just like I'm not super precise because I'm rushing about a bit Um what 's next? Do we just keep going top to bottom?

Speaker 1: Let's look at the oldest pull request.

Speaker 2: Oh god. Ooh, yes, which kind of oldest?

Speaker 3: Creation or loss activity or the age of the person submitted.

Speaker 1: The age of the person submitting it.

Speaker 2: Let's look at the actual oldest. I'm interested because I rarely look at pull requests by opening date. Oh, it's Scott. I don't think this needs triaging Batiste though. It's clearly needing in of work

Speaker 1: There's sometimes easy wins in old tickets or open requests in that sometimes they've just been fixed since then. Or like This one for example circle CI sometimes it's fixing something that you don't use anymore. So they're very easy to to close. But

Speaker 3: we still use circle CI

Speaker 2: Yeah, we definitely do. You underestimate how good we are at uh triaging old stuff, Baptiste?

Speaker 1: Well I I wasn't commenting for Wacker specifically, just like a

Speaker 2: Um yeah, so I guess something like this um definitely um a good uh a good one. Um Actually we like this because it's something else that we do pretty often that I think more projects should do, which is cut our losses a bit and signal is definitely still something we'd like to solve. but as an issue so that it gets other contributors more aware of it. Um I think you know this is like Potentially really valid work, but seems really unlikely that it's gonna go ahead in the current state. And um someone else might be more keen to take it over if it was more visible as an issue. So I think I'd probably wanna do that.

Speaker 2: Does that sound okay? Not hearing much objection.

Speaker 3: Very farm or AI forter

Speaker 2: yeah and honestly i think the ai could be really good at this um because it requires very careful looking at the circled ci docs And the AI probably can find the docs and produce the relevant code. I'm actually really hopeful, Sage, that's someone with vibe code the fix to this.

Speaker 3: I just hope that they reveal the changes before they submit it.

Speaker 2: But we have CI for that, no?

Speaker 3: Yeah, but you know, I d I don't want it to be just someone putting the prompt to an L11 and just submitting the PR as is without knowing Why or like

Speaker 2: oh this really might not do this now. Have you ever like opened an issue on a project and felt like, oh, should I just give this to the now?

Speaker 3: No, no, I I think I think it's it's fine to to have the issue. I I I'm just saying that it's pretty much inevitable that we'll get VRs uh that are AI generated and so it it might be good you know um it really depends on the person submitting it whether they took the time to understand what they end up submitting or whether they just took the LLM output as is. And then it would be on us to review.

Speaker 2: Yeah. I'm hopeful for this because I think one the LM can be quite good at this finding the relevant docs in circled CI and um you know linking to them in the pull request but also just generating the more correct code from it and to also it'll be very damn obvious. when the thing runs, whether um the changes are correct or no. You just need to submit different pull requests and see which ones go through or not.

Speaker 3: And the nth ER will get it right.

Speaker 2: I sense some hesitancy on Baptiste's side.

Speaker 1: Oh, there's no hesitancy. I just have a different opinion.

Speaker 2: Do you wanna elaborate?

Speaker 1: I think we use or I shouldn't say we, but the way I see LMs being used is kind of a abdication of your uh of you caring like you there's as sage mentioned like opening an issue here is opening for ai slop so you're gonna get Multiple people submitting a pull request that is gonna use time from the maintainers and those people are just gonna you know one shot whatever. There's no no one wins anything here. Uh everyone does this time. And then maybe someone else will provide a little better. They will actually review the code, try to make it like

Speaker 1: try to run it. But then I think you kind of abdicate on you understanding what how things are gonna work. And it might work now. But then you commit yourself to never having anyone on your team who understands how it works, who knows where to go find information in a circle CI docs in the future when something changes. And you kind of commit yourself to oh I guess the AI is in the future is always going to be able to update things because you will not have the skill to do it yourself or you would not have a contributor who has the skill to do this themselves. So for me I I view this as giving up in a way. And giving up on the on the assumption that

Speaker 1: we'll always have the AI models to do the work for us. And I don't know if that's a assumption that can be made. Prices might change. Um it's still unclear whether yeah. So It's tricky. I don't know the problem at all. I know that it's trying to decide when and when not to run things is very tricky. There's some really subtle bugs because You might think you know if I have uh something that links my HTML, I don't need to run when the HTML changes But then you also want to change if your the linter 's configuration uh changes

Speaker 1: and it's often this kind of really subtle things where you like it's never as easy as checking the list of files. You know, you might only want to run your Python code tests if Python files have changed, but maybe some of these files depend or they load the text file, they have test fixtures. And it's the kind of bug that's gonna work uh 99 % and then on the 1% it's not gonna work and that's gonna be very hard to track down with potentially uh catastrophic effect where if you skip CI you know you might put things in production that you that are broken because the CI didn't uh trigger

Speaker 1: So it's yeah, it's it's tricky for sure. I think it's as always it's a balance of maintainers time, maintain your skills Where do you want to build your skills? Where do you want to say, okay, this is not a skill I need to build? I would rather have the quick and easy fix now that an LLM will provide. It's um I think each project, each developer have to find where they put that balance.

Speaker 3: Right. So I I think basically the big part of this is defining appropriate files in this title what what would you how would you decide which files are deemed as appropriate as things that would that should trigger a CI run if it's just a matter of setting up conditional runs of the CI like um the configuration to make it um Conditional, I'm sure AI can do that just fine. But defining which files would trigger what jobs, for example. that's that's the thing that I without even defining it on the issue how would the AI

Speaker 3: know because even us you know we we still don't know Uh the exact definition of that

Speaker 2: Good wisdom right there. I don't think I'm giving up on understanding the nuances of Circle CI completely, but I definitely think that um I'd like another contributor than me to do the bulk of the research. And

Speaker 3: that's the important bit, like the the research made done by humans, not just blindly accepting what the LLM

Speaker 2: Oh yeah, yeah, yeah. But I definitely think it's research that could be helped by um. Yeah, yeah , I

Speaker 3: no doubt. Like I if I were to do this, I would definitely make use of AI to to help me find things on circle CI. on like or like give me starting points but I would still need to do the bulk of the research on how um it's best uh like how what's the best way to apply this on our repo and with our set of files. That's the bit that I don't think you can just rely on AI. Yeah and it would also be tricky for new contributors if they don't understand um the files that we have and the CI setup. So yeah, it's and it's quite likely for Well given what we've seen on GitHub, it's likely that some people will just ask AI, take whatever it outputs, and make it a PR without

Speaker 3: doing the research. So yeah, that's that's my main hesitancy. I'm not saying that you can never use you should never use AI for this kind of task. I would personally use it

Speaker 2: It's a fine balance to find if you want to use AI exactly where to trust it I don't know how much you wanna go in that tangent, but there's this article that I read recently that I found very illustrative. I'm not gonna read the whole thing together right now. I just want to show you one image from the article, which is this one right there. That's the stages of AI adoption for coding Figure one. You type the code in your IDE. Maybe you have some auto-complete in there now and then. Then you have your coding agent on like a third of the screen and you accept, reject.

Speaker 2: it changes one by one. Same thing but yellow mode, just let the agent do whatever it wants and hope for the best. Then you end up editing the code less and less. coding agent takes over like two two-thirds of your screen metaphorically. Then you're not even looking at the code anymore. You're in cloud code with a similar workflow but no manual editing of the files ever Then you have three in parallel, then you have way more in parallel. Um so I guess depending on the view that you have of how and where AI could be used. You decide where on that spectrum you want to be.

Speaker 2: I do feel like even with the later stages of the spectrum, there's clearly still room for humans in the loop, but it's definitely way more of a strategic level where like paraphrase what you said Baptiste you probably definitely care less about the solution and your understanding of the solution at that that later stage It's just like coding is a means to an end, I suppose.

Speaker 1: You also probably get paid less if you're at figure eight than if you're at figure one.

Speaker 2: Do you think?

Speaker 1: I think AI is a big de-scaler where it's gonna make the coders more easily replaceable. I think is a very big labor issue in the weights.

Speaker 2: Yeah.

Speaker 1: Especially in the market right now where there's been a lot of layoffs. I don't think it's coincidental.

Speaker 2: Yeah.

Speaker 1: Because essentially at this point the key part is your cloud code subscription. Who pushes the buttons to make Cloud do what you want? Does it matter?

Speaker 2: Yeah, I don't want to um like project too much on the job market because I do find it really hard to predict, but um at least coding wise, it's definitely a very different job if um in in ear quotes all you do is um kind of like architect and delegate the tasks to the machine. Though you know it does it does take some kinds of skills to have a good sense of um how to architect things yeah you can delegate those tasks to AI.

Speaker 1: I I got those skills by writing the code.

Speaker 2: Yeah yeah yeah yeah

Speaker 1: so what happens when you never you skip that part?

Speaker 2: We're gonna find out soon, Batiste. Okay, um moving on from this one, I guess just what I might not have mentioned is obviously I Have been looking at this specific issue pull request, sorry, for for years, it being our oldest. So I do have lots of context that's the PR in its current stage. Definitely isn't gonna gonna work for us and there's definitely a new approach that I suspect will help. So it's not just like oh I think someone else should take a look at it. It's also I felt like this was way too much um bash scripting

Speaker 2: for our needs. And I'm sure that Scott would uh would feel the same and uh will be happy to see someone else have a go at this Hopefully that other person does it right.

Speaker 3: And was this before or after we started using GitHub Actions for most of our CI jobs?

Speaker 2: I think after. My understanding is uh the problem ish we have with GitHub action actions is just uh Since it's used for our like multi-version support compatibility test matrix, um the quota we have there runs fast and I think because of this we haven't invested into it enough to like orchestrate the CI steps so that we'd have some checks first and others later. Uh definitely, you know, it's but it's but I as far as I know we're really happy with circle CI. But it's also definitely possible that if we wanted to invest more time into CI, we would want to consolidate. Though um

Speaker 2: For other reasons, I do feel like it's nice to not be reliant on a single provider.

Speaker 3: No, I I think uh uh I mean I was talking about in terms of saving up resources. We would save up even like a lot more resources by doing the same thing for our GitHub actions.

Speaker 2: Oh, we already do. Uh it's not necessarily to the fullest extent possible, but we do already have lots of builds keeping logicing GitHub actions. I think. Uh keep No?

Speaker 3: Oh yeah, it can work. I have

Speaker 2: signal, yeah. Obviously it could be way more refined than this, but as you mentioned, there's lots of risks there if you ignore too much. Um yeah, maybe maybe someday we will have um contributors to invest the time. I'd really like us to publish our um GitHub Actions metrics a bit more so that we can also report on the the carbon impact of CI. It's definitely like not tremendous compared to other types of computing, but it's not not nothing either, you know. It's uh pair bits of time on a yearly basis spent building and rebuilding the project.

Speaker 2: So yeah, I'm hoping that someday we'll we'll look at like more Let's do one more triage. Baptiste, do you want to make an executive decision on whether we look at oldest or newest or some other filter?

Speaker 1: Middlest.

Speaker 2: Middlest? We just like go for page three or four?

Speaker 1: Sure.

Speaker 2: Okay. Page three.

Speaker 1: I hope one of these is mine.

Speaker 2: We can look at your pull requests if you want.

Speaker 1: No, I don't think I have open one.

Speaker 2: So we have pull requests that are not from that long ago. that have pretty clear states and I think lots of these were definitely happy to wait for contributors to come back to them within that kind of time frame I felt like this one I had already said was a bad idea. Oh no, okay, it's a different different take on it. So this definitely needs review. And at a glance this definitely looks reasonable enough. So we'll assign me.

Speaker 2: Okay, let's do let's do one more. Let's try out our fancier triage setup. Where we look at needs decision maybe? Oh, we don't have any needs decision. What the hell?

Speaker 3: Is this this up to date? Uh

Speaker 2: it's always up to date, but it's only pull requests.

Speaker 3: Okay.

Speaker 2: Do you want to look at a let's look at a needs decision issue for a change. That'll be an interesting one to end on. Do you feel like making decisions, Baptiste?

Speaker 1: Sure.

Speaker 2: Oh, this one you know way more about it than I do.

Speaker 1: Close it for sure No sorry you can you can click on it.

Speaker 2: I'm just looking for something that we can unpack without it taking a whole hour. Ooh, enhanced block previews. I know someone who's worked lots on block previews

Speaker 1: It wasn't me.

Speaker 2: Oh, why does the status icon need alternative text? Okay. Let's look at this one. I feel like you both have come across this and can educate me in the process. You can really fuck up your site if you delete a page that's really high up the tree, in particular the root page. And I feel like generally speaking we try and have some guardrails for situations like this that really can put you in a bad state. Um

Speaker 2: so I think basically here the idea is to have an extra guardrail for this situation. And

Speaker 3: I don't see why this needs a design decision. I thought it's pretty reasonable.

Speaker 2: Yeah, the problem that I have is here Someone says, oh, we should have on-delete cascade. And someone says, oh, we should have on-delete protect. And I've never had to make the judgment call on these two myself. My you know ORM usage is way simpler than this and you know I could probably get up to speed, but um I think we need someone with more experience of the nuances It seems like we all agree what change needs to happen, but literally we have Cascade, Setnol, and Protect all in the same discussion. So

Speaker 1: Well, if I'm reading this right, this person is not suggesting to use cascade. They're saying we currently have cascade, which is the source of this issue. Because cascade means that when you delete it,

Speaker 2: it cascades.

Speaker 1: I think the two options are set now or uh protect.

Speaker 2: Yeah, my bad. You're right

Speaker 1: So see that's like a 30% say uh cost saving already in the number of possible options. Went from three to two My gut feeling is I don't see the argument for said no.

Speaker 2: You expand?

Speaker 1: As you said, if you delete the root page of your site, that's a big uh that has big consequences And Setnol would just not prevent any of these consequences.

Speaker 2: Yeah, yeah, you'd have to do lots more updates of the code to handle that.

Speaker 1: Protect would simply not allow you to do it. I guess the question is, is there a scenario where you would want to delete the root page I can't think of one, but

Speaker 3: I mean if you want to delete the site

Speaker 1: Yeah, but then what just delete the whole database?

Speaker 3: No, but if you have multi-sites.

Speaker 2: Yeah.

Speaker 3: You want to delete one site.

Speaker 1: Well that would work because you just delete the site first and then you can delete the root page if it's protected.

Speaker 3: Yes, that's what Andy is saying. It feels that it's more likely to get in people's way so that you have to do that in the right order. You have to either unset the sites uh root page first or delete the site first and then to delete the root page making it has to be a two-step process instead of it's just one so it's yeah whether you want to prevent um making like deleting the page and the side accidentally or at the cost of getting in the way of people who absolutely know what they're doing

Speaker 3: I guess if if there is a way to just, you know, have a warning, but on the same page has a confirmation that says yes. what I want so that it doesn't become a two-step process where you have to do one thing and another and it's just uh but it still prevents accidental deletion.

Speaker 1: Doesn't deleting the page already gives you a warning?

Speaker 3: Yes, but I guess it doesn't specifically say that it's the root page of a site. So

Speaker 1: would that be the way forward to add an extra logic on the page deletion um

Speaker 3: template?

Speaker 1: Yeah.

Speaker 2: Yeah, and I guess um it might be a matter of permissions as well where some users might have permission to delete pages. but not to delete the sites. What's a permission model like again? No , no, no Yeah, so you could imagine someone having wide-ranging permissions to mess with pages, but no permission to edit site records. So in some sense you would be saying that only the people

Speaker 2: I guess there's there's a case there where you make it so only the people who can edit site records can do the This kind of deletion. Um I don't know that there's a right or wrong answer there, but I guess we can respond along the lines of uh Beyond the database level check, there needs to be um quite clear messaging in the UI, whether it's a warning or like explaining the two-step process. And um maybe in that mindset the actual like database level configuration doesn't matter as much.

Speaker 1: I mean if you want to support deleting a site by deleting a suit page, then you have to have cascade or will have to, but that's

Speaker 2: It's just like I I think the actual deleting is quite a rare scenario compared when when definitely when you have it like you'll go through any steps as long as they're clear enough. Whereas the preventing Doesn't rely on what the database says anyway.

Speaker 1: There is a permission issue which I'm assuming if you have permission to click pages but not sites deleting the root page you would still delete the site regardless of your permissions. I'm assuming.

Speaker 2: Yeah.

Speaker 1: So that's kind of a permission bypass issue

Speaker 2: Do you think we should investigate that specifically more?

Speaker 1: As you said, it's like it's probably like a point one percent uh Because I think in practice the people you trust with deleting pages probably are already have high trust. So it's probably quite rare to have permission to delete pages but not sites. I assume at this point you're kind of like probably super user, most likely But it's technically yeah uh a possibility.

Speaker 2: Yeah.

Speaker 1: I mean there's a reason this this is an old issue and it's like It's it's tricky, it's because there's not a clear right answer here. I think it's depends on your use case, depends like in a single-side context, which seems to me like it's the most common deployment. the uh I think it's quite different than in a multi-side context because in a single side context you never want to delete your site right like

Speaker 2: That would be bad.

Speaker 1: Yeah, that would be really bad. In the multi-site it's still bad, but it's more I I could be convinced that this is an actual use case. And so you already like have a fork in there and then yeah, it's uh trying to be a a framework uh where you support many people 's quite different scenario. It's yeah.

Speaker 2: And you know what trips us up even more, Baptiste, when no decisions? is also deciding what to do for people who have misconfigured their project one way or another. There's a whole other degree of nuance there of exactly how much you wanna do the right thing despite the permissions model being configured wrong or stuff like that.

Speaker 1: Yeah. Yeah, writing software is not easy.

Speaker 2: Maybe we should have like three confirmation screens. Like do you mean it? Yes, do you really mean it? Yes, there will be consequences. Are you sure that you mean it?

Speaker 1: Please retype the title of your root page before uh deleting the

Speaker 2: yeah the title of your root page translated in uh Indonesian or as emoji, that'd be fun, that'd be a fun one.

Speaker 1: That would be the ID of your root page. ID being the language code for Indonesia.

Speaker 2: And on that note, I think it's a wrap for this edition of the Wagtail Review. Do we have like a outro jingle?

Speaker 1: It's just whacktail weekly weekly review backwards. That's probably like you're wrong, Ruggsy Kim