Combating the onslaught of features

Speaker 1: The on slap. Love it. You ready for your intro, Sage?

Speaker 2: Oh yeah, maybe Should I do it now or give me the keys?

Speaker 1: We are live Hello Sage, do it.

Speaker 2: Alright. I hope you can hear this. Oh

Speaker 1: Oh music to my ears, literally. Thank you Sage for bringing the vibes to our review sessions.

Speaker 2: It's a new instrument.

Speaker 1: Wow. When did you get that?

Speaker 2: Oh I think I bought this back in Indonesia, but I I'm sure you can find it on anywhere. It's Kalimba.

Speaker 1: I like it. I think I have one had one when I grew up. I don't have no idea where it came from. Do you have one, Baptiste? Not with me now, no. Fair enough. Okay, what are we here for today? I think we're supposed to talk about Wacktail. Yes. And uh the title we are landed on is Combating the Onslaught of Features. I thought this would be a valid like globally encompassing term for what we're up to. Um Sage, do you want to give us a problem statement?

Speaker 2: Um I don't know, that title sounds interesting. Why don't you want features? I thought we want all the features.

Speaker 1: We do love features. We do have a tendency to, you know, our public roadmap is. Generally half of the items are features, I think. About half maybe are developer-focused features, the other half for CMS users. It's an important balance for us to have. But you know, we only have room for so many features , lest we risk technical debt. or cognitive debts as people phrase it these ways these days in the AI uh universe. And also we only have so much time for reviews, I suppose. How much time do you spend on reviews on a daily basis, Sage? If you go to average.

Speaker 2: It really depends um at least three hours maybe. Um if if we do have a backlog that we need to get through. Well, we always do, but you know, um and sometimes I when I'm working on other things I have to prioritize those. But I think usually when we're when it's closer to um feature freeze for example where we're usually done with features or or I guess during the feature freeze period we're we're done with features and we can use the time to review our backlog And in those cases I would spend more, but I guess it on average day at least one or two hours.

Speaker 1: Yep. That's the kind of budget we have times how many core team members we have times how few of them actually feel like they have the expertise or um capacity to be reviewing things that could be quite challenging. We can only fit in so much and yet if we look at our like pulse charts in a GitHub interface We see in the last 30 days merged 18 pull requests, but there's been 41 opened. So It keeps trending up and up and up and we just can't keep up is the problem.

Speaker 2: Yeah, it's not sustainable, I d I think.

Speaker 1: It's definitely not sustainable. We have reached 150 pull requests opened. I have never seen that high of a number for Wagtail ever. Not that the precise figure matters, but it's certainly a sign of the underlying trend there

Speaker 2: And I can remember just a few months ago we were down to like 89.

Speaker 1: Yeah. Had broken below the 100 and yeah And you know, it's it's uh it's a good uh health indicator for the project that there are pull requests getting opened. Um But it's not gonna be sustainable, as you said, unless we can also keep the pull requests getting through the pipeline. Uh keep that in check. Um And yeah, I guess like just um the this this is uh burying the lead a bit, uh the big reason why this is happening uh I think is AI is fair to say. Um People have a much easier time approaching an open source project like Quagtail and uh proposing changes to it.

Speaker 1: And I think AI slop is a term that lots of people are familiar with these days. There's definitely some elements of that here where there's this people that are frankly probably a bit clueless and just give us pull requests that are complete nonsense. And what I mean by complete nonsense is just like Django templates inside React components type situations, you know, like it's it's pretty clear that this isn't gonna work. Uh but there's also just lots of uh lots of improvements that are being made That are actually pretty correct, uh, but it's not because they are correct that we have any more time for them, I suppose. Um Like my go-to example for this these days is uh like improvements to our error handling on specific scenarios.

Speaker 1: That's really useful in a broad way, but there are some scenarios where Really is it worth our time to add better this or that's there? Um so we have a problem, I suppose. Um Baptiste, I don't know if you see this on other projects too. I assume it's not it's a global thing, it's not just Wagtail, right?

Speaker 3: No, it's just Wagtail. Uh AI is not uh impacting any other open source projects right now, it's just Wagtail. Yes, uh I think this is the um the times we live in. Um I think it's all about it's shifting the dynamics of converting a one-time contributor into a repeat contributor. And it used to be that because the barrier of entry was higher to opening a pull request , the people who would open pull requests tended to stay long stay around. and maybe open a second pull request and a third and you know they would become more like this was the path to becoming a core contributor

Speaker 3: But these LLM tools now that are so readily available have lowered the barrier of entry, which in some ways is good, but in other ways I think it shifts the workload onto maintainers. And I see I see a lot of open source projects essentially drowning under the load of all these, even if we assume all of them are well-intentioned. There's just too many people opening pull requests that require reviewing, that require the In a way the emotional labor of open source, right? Welcoming someone, teaching them the ropes, uh, the tools you use, the processes you have, and

Speaker 3: Yeah, it's uh I don't think it's a fair fight for the maintainers.

Speaker 1: Yep And um there's definitely, you know, a problem that some really good pull requests are getting hidden in in that um I guess onslaught is definitely the way to put it. And I think that just for clarity, like if we could keep up I'd probably be happy with the increased amount of contributions even if the quality is uneven. It's just like we can't keep up. It's just impossible. So we have to find, I guess we have to adjust. how we work to find those opportunities to keep up so that we stay sane, I think it's the TLDR here. Eventually maybe we'll have a different workflows to support higher amounts of PRs.

Speaker 1: Just for now, it's probably gonna require us to be more selective on what's coming through And yeah, I thought it would be a good conversation. Topic for today is actually how we become more selective about what we want people to contribute on. I don't know how much time either of you might have had to look at our triage processes. uh before so thought we might start with a quick look at our uh diagram for this um I thought github had um yeah more full screen option have you seen this before Baptiste

Speaker 3: Uh no. I mean I have seen diagrams before, but this particular one I'm not sure.

Speaker 1: So let's say this is you, Baptiste.

Speaker 3: No, it's Alex. It's my friend Alex.

Speaker 1: It's Alex. Okay, let's say it's Alex. And uh Alex is a contributor and Alex is really keen to contribute to Wagtel. Um there's different types of contributions that they could be making. I think for today we're gonna say that Alex is making a feature request because that's where we think there's the more room for us to change our process. And um this is this is kind of Alex's uh workload here, initial workload is making that feature request. And from then on There's workload for our maintainers to process that request and then once we've done that processing. Some other contributor could come and say, okay, I'd like to work on this.

Speaker 1: Thank you, Alex, for writing the feature request. Someone else might take it on. or Alex might decide to take it on. And there's a key flaw right there, which is that in a current pipeline for those requests First off, there's not necessarily anyone else that's gonna check once the request has been received that yes it sounds reasonable we should proceed and second that kind of check currently we leave it to anyone and everyone to provide uh the the feedback basically on the requests being made um so We when we produced this diagram that represents our current process, we alluded this alluded this issue with this uh

Speaker 1: notes that we need uh needs sounds good status to confirm that at the point of the feature request having been made, we do need someone else to say like, oh yeah, this this sounds good, or on the contrary. No, it doesn't. Yeah, Sage, I don't know how we came up with that wording, but uh I guess the idea is we'd have that kind of label there from the get-go when someone opens a feature request And then someone else would have to take it off? Is the the is was that the plan?

Speaker 2: Yeah, some kind of clear way to communicate that, you know, this was just an idea that someone suggested and It's not necessarily something that we would accept a PR for right away because we want to know if it's just going to help that one specific person. We don't know like what are the implications. Is it because it could be like one very specific use case that's not very useful for anyone else or it might affect other users in a worse way, you know. So we we need to that kind of confirmation first.

Speaker 1: It might affect other users and it also affects our maintainability of the project very often.

Speaker 2: Yep.

Speaker 1: Just people requesting customizations that are um way too much work for us to sustain. Uh also often also people requesting like very widespread changes like Oh, I'd like to make sure that uh every uh page chooser in Wagtail or maybe every button should have this or that different thing done to it, which you know like it only takes a few seconds to request those things It's gonna take us weeks, maybe months of work in some cases to to make the changes happen. So we need to be really careful with um what expectations we set there.

Speaker 2: And sometimes even uh an idea could be good and like we we could agree on the principle that yes, that would be a great thing to have in Whitetail, but there are different ways to approach it, like to implement that feature. And we'd like to know like the advantages and like the drawbacks of each um each way to do it and like the considerations before someone uh should jump in and create a PR because uh that that's where it usually you know takes some time to to to actually get it accepted. And if someone just jumps in with, hey I made it this way and like because we'd like to know why didn't you

Speaker 2: uh did you consider the other ways? Like is this the best way to do it? We we don't necessarily have to always do the best thing 'cause it's not always possible, but we want that bit of, you know, research done into it, not just someone jumping on it and like even worse, asking an AI to just do it because you know, you can do that in less than an hour, just a few minutes. But the time it takes to review those and like consider the alternatives and so on, that that's the big the big the bigger chunk of work I'd say.

Speaker 1: Yeah. It's a bit tricky though because when you say jump on it, like I also definitely appreciate it when people who have a clear understanding of the problem go straight for a solution that they know is the right one. I think there's definitely contributors who understand all of this enough that they'll be able to tell like, yes, this is the only way to do it. I should get on with that probably.

Speaker 2: Yeah, I think I think my I wouldn't mind uh I think my main concern is just the person who contributes to it has to take accountability for what they submitted and like they could say in full confidence that they have reviewed it and like, okay, I did it this way because for A B C reasons, not just the prompt and LLM do it for me. Submit it, leave it. Like that's not what we want.

Speaker 3: You want them to prompt the LM to give them the reasons why they did it.

Speaker 1: So that that's the thing. Like that's the thing. Cause that's definitely an issue. To me, like I don't necessarily expect them to have full confidence, but at least be clear about which aspects of their approach they are not confident with. So that's We can interrogate that in particular.

Speaker 2: Yeah, which parts have been reviewed by humans? That's that's what I'd like to know. If it's completely LLM. Uh we could do that ourselves if we wanted to.

Speaker 1: Yeah. So so then earlier on in the pipeline We need to change how we triage those requests so that it's more explicit that this thinking has to happen. And then when it comes time for the pull requests, we need either for the pull requests to be tied to an issue where that thinking has happened, or if the pull request is just out of the blue. make it clear that you should have to share it along with your thought process, I suppose, is the

Speaker 2: Yeah, that sounds about right.

Speaker 1: What do you think, Badis, when you're going to get two projects? How much uh because I I want to be careful here with um burdening people too much. Do you Will you always like make sure there's an issue first and then a discussion? Do you feel like sometimes you can just go and make the PR? How do you decide what's uh the best way to spend your time to make a given improvement?

Speaker 3: It really depends on the size of the improvement, right? And also the type My favorite issue to fix is like a small bug because then it's it's usually easier to review, especially if you come up with a test case. uh you can clearly show the you know the issue and then the issue is fixed and then if you have a pull request to start on you know it's a good starting point and You can then later argue with the maintainer. Not argue, but like discuss what the um if that's the best approach, but at least you have an approach to start with. Coming up with a I think typically the the phrase we use is like a pony. So you arrive and you say I I want a pony.

Speaker 3: It's like this chat magic feature that you want. It's very it's kind of the easiest thing to do, right? You have this idea and then turn it to a feature request. But the actual work as Sage mentioned of like deciding on different alternatives, how it fits within the project, what levels of extra work to do does the project want to take on. Those are really They require much more work and it's work that has to be done by specific people. It's not really possible to have a global community of people with all their agents and all their varying levels and expertise contribute to this this part. It's

Speaker 3: just I think by nature it has to be done by a small way smaller Group of people.

Speaker 1: Yeah. Because that's the people that have, I guess, the background knowledge of the project or just the expertise.

Speaker 3: Yeah, but also the people you trust to come back if there is ever an issue. I remember

Speaker 2: it's not a one and done situation. After the code is merged, it's not like it's gone. It's it's It's living in the code base and we have to keep maintaining it. And if something ever, you know, it comes up, like it whether it's a bug or you know, we need to update it in one way or another It's usually on the maintainers to to do that. It would be great if the original contributor would come back and like help us with that, but it's not something that we can expect out of everybody. So it always accumulates with every single every single thing that we merge.

Speaker 1: Yeah. And like thinking of what you said, even um the pony requests, to be honest, um they can be pretty valuable um because you definitely want people who point out things that are that could be kind of glaring to them and to you they might be in the back of your mind for ages without necessarily having crystallized into a request. It's just like you know when people make requests like this then then you don't want someone else to jump on it right away and be like let's do it there has to be some amount of um um brewing I suppose.

Speaker 1: Maybe we should have uh request of type like idea and then be explicit that yeah there's space for ideas like random ideas but like it's not gonna be something that you jump to Is that something we should do? Like hang on, how do we, what happens if I click new issue Bug reports, documentation, discussion Yeah, so I guess discussion here that could be reframed to ideas if we wanted or we could have one more item here to guide those towards our discussion forum.

Speaker 1: I guess suggests an idea. Yeah. See that's the idea.

Speaker 3: Do you control

Speaker 1: Yeah?

Speaker 3: Do you control the order of templates?

Speaker 1: I think so. Yeah.

Speaker 3: I wonder how how many people just pick the first one.

Speaker 1: No, they usually it's it's rare for people to choose the wrong one. Um I think the main reason that someone would choose the wrong one is just our you know definition of what's a bug what's a feature rather than um just um going in the UI oh so we don't actually control them

Speaker 2: Um I think it's based on the file name of the template. So if you want to order them, you could name them like 01 bug report 02 feature request if you want that to come up uh the second Or

Speaker 3: just with emoji. You just have to know the order of emojis.

Speaker 1: Do you think the order of emoji is predictable? Like

Speaker 3: Absolutely. It's just a character like any other.

Speaker 2: So which one which one goes first, the egg or the chicken?

Speaker 1: Oh

Speaker 3: it's the egg. Everyone knows that.

Speaker 1: I wanna I wanna test this now, but um yeah, it'll be fun. Um Yeah, okay, so potentially more options in here so that we guide people towards the format that um better matches what we expect to need to happen once they've made their uh request. And then once the requests come through a process on how we have those discussions as a community and as you said like we probably need at least two different states one for like community input and one for Maintainer input, I guess, is what we're saying.

Speaker 2: Yeah.

Speaker 1: Maintainer. I'm taking notes as we go through this.

Speaker 3: Sorry, I got it wrong. The chicken is first.

Speaker 1: Oh no. Did you test it in um code?

Speaker 3: Yeah, I put a code. It's a one-liner. I put a code in our zoom chat. I don't know how to put it somewhere else

Speaker 1: Sorted. Okay. Uh do I have like a Python in the browser environment? I'm sure there's like a microPython, yes. Do you think your code works in MicroPython? This is either not working or loading 40 megabytes of WebAssembly. Okay, Baptiste, I'll we'll uh leave you with homework to produce a

Speaker 3: you have to put a print. There's no output you have to put a print.

Speaker 1: Oh, do you think it's that? Well now you have to vibe code the front end so we can see the output of uh sorted egg chicken. Please and thank you. Um okay, yes, so maintainer input, community input. And then at some point there's a decision needed? Has there been enough input?

Speaker 2: I think um yeah the needs decision is usually the the one that requires core team input, right?

Speaker 1: Yeah, so I think then we're gonna expect our core team to be deciding whether the input provided has been sufficient so far. So it's not necessarily so much um Yeah, I guess it is a decision on the approach still. Do we want to reuse this existing label is what I'm asking or do we want something a bit different? Because this feels a bit daunting. I feel like when I add this, it means like, oh, serious considerations here.

Speaker 3: For a long time the Django project had a tag or category or state, I forgot, but that was design decision needed, abbreviated as DDN, and that was the graveyard of things you didn't really wanna deal with that maybe were good at it was too hard to say no to them too hard to actually implement them or decide on what was the best and so that that tends to be the category of like yeah things there go to accumulate and then just wait that the the person who asked for it goes away I think there's there's a very like social aspect of like how do you say no?

Speaker 1: Yeah.

Speaker 3: It's It's very easy to say no.

Speaker 1: Well um 100%. But we're very lucky for Wagtail. My official job title is Wagtail Product Lead. So I'm basically paid to say yes and no. Yeah, but there's only one of me, so I think we want the no to be a bit more distributed if we could

Speaker 3: You're saying the yes needs the no to win against the no?

Speaker 1: Where does that come from again? Remind me.

Speaker 3: That is a vintage French meme.

Speaker 1: Yes. Yes. I wasn't sure how much it translates to uh have you heard of this sage?

Speaker 2: No. What is it?

Speaker 1: Oh It's it's I d I don't know if this is uh PG enough, but

Speaker 3: it should be. It is uh uh ancient French prime minister, I believe, who had terri terrible English. And this was in the context of the some referendum relating to the EU. I think maybe the EU constitution. That's probably a good 20 plus years old

Speaker 1: Yeah.

Speaker 2: Uh-oh.

Speaker 1: It's marvelous. It's a

Speaker 3: uh high-ranking French official uh with terrible English.

Speaker 1: Yeah.

Speaker 2: I'll look it up.

Speaker 1: The yes needs the no to win against the no. It's literally what he said Oh anyway, there's yeah, French politics. Um okay, so we're saying we can reuse this label if it doesn't turn into a graveyard So Sage, what do you think? Is it already a graveyard? Do we need another separate graveyard?

Speaker 2: What i is the difference between like so hang on. A feature request comes in, it needs community input, and let's say enough people have provided their inputs. And then what what would be what would you say i uh what would would make it different to our current needs design decision?

Speaker 1: I guess in my mind there is a case where someone comes with a feature request and it seems pretty clear what should be done It's just a matter of do enough people need this to warrant it happening? And then there is a separate case of This is a gnarly problem, like a valid problem, but pretty gnarly. And we need someone to I guess in your diagram you had this as um write an implementation plan. Like some sometimes the issues, the feature requests come with that plan and then it's just like a thumbs up that's needed. And some other times someone needs to do that

Speaker 1: I don't know if the nuance of the two is worth um having separate status for though Yeah, I think in my mind design decision it's more there is multiple competing implementation plans or no implementation plan at all and someone needs to sort one out. Whereas the more common situation is we just need to confirm that the plan is kind of there enough. Does that make sense?

Speaker 2: Right. So whether the implementation plan already existed or not and just needs like a sounding board.

Speaker 1: Yeah.

Speaker 2: Compared to um Yeah. Okay. Yeah, I guess that could warrant a new label. Not sure what to call it though.

Speaker 1: Yeah. I'm a bit hesitant on how many labels is the optimal amount of labels because I feel like the more you add the more complex of a process. But also at least the more you add, the more explicit the steps of the process are. And you know if you have a label it's somewhat self-documenting. I don't know how much the working on this section is working so far. Because you know, like we could explain this in this those kinds of like instructions for contributors. But then there is a fair chance that people just don't read this or just like visually

Speaker 1: none of this stands out enough that people notice. At least the label, you can't argue with the label being there. So yeah, I feel like I'm leaning towards the size of side of more labels, more granular triage.

Speaker 2: Yeah, I think what what I personally would appreciate is if there's a clear, actionable Like here's what needs to be done for this thing to proceed. It could be, you know, based on the labels. So yeah So like for example, these status labels maybe in an ideal world there can only be One wait no I mean you can have needs tests and needs docs.

Speaker 1: Yeah, definitely the fewer the better.

Speaker 2: Yeah

Speaker 1: Yeah, there is a few things where you could need both user research and um UI design or design decision but you don't want yeah you don't want too many either. Um okay so I'll try to come up with the new needs some kind of confirmation of implementation plan and we can keep NIST design decision for the Narlier um We need someone to spend time thinking about this, not just like thumbs up. Okay, and then once you've done those things at the point of removing this label, we add a new accepted label

Speaker 2: I think Are there any other considerations?

Speaker 1: If only we got a diagram.

Speaker 2: I feel like at some point it has to have an accepted label that would make it much easier because Okay, the if a PR comes in and the issue has an accepted label, we can be confident that it has gone through enough of that process.

Speaker 1: Yeah Yeah, okay. So I guess that's this um congrats state here where things could still, you know, we could still change our minds later on. There's some further tree edging that could happen. But um normally it's definitely ready for um for pull requests. Um Yeah, so basically it's uh either accepted or some other kind of unambiguous ready-to-be-worked-on terminology.

Speaker 2: Yeah, because right now I think our list of issues are a mix of, you know, there are some diamonds in there where we have issues that are actually ready for people to work on. But Yeah, it's drowned in all the other stuff that's that hasn't gone through that process.

Speaker 1: Yeah, yeah. There's definitely some diamonds in there.

Speaker 3: Show us a diamond.

Speaker 1: Um So there is some diamonds that are a bit rougher than other diamonds. I think this one, for example, uh I think I would qualify it as a diamond. Um it's uh it's been a while since it was opened and it's definitely always been an issue with Wagtail that uh was always easier than we expected, than we wanted, sorry, to um Spend time working on a draft and then for one reason or another the draft doesn't save. And um I think it's been very daunting because you know in order to detect this or save anyway There's just like some amount of fairly intense engineering needed, but now it's so much more approachable.

Speaker 1: Um It would because we you know we've implemented autosave and it's literally now just a matter of um better showcasing this state because we already know that we're in this state it's just a matter of showcasing the state in the UI Is that a valid diamond?

Speaker 2: Yeah, I think I would say so.

Speaker 1: Do we have other diamonds? Now this one is a diamond as well. That's something that I think Someone shared in our discussions and it seems like such a clear win where um in the CMS we have um administration of user accounts and we show who's an admin but we don't show which groups people are part of which is Particularly useful. Um

Speaker 2: yeah, but uh I think you need to consider the performance as well.

Speaker 1: Do you?

Speaker 3: There's probably a prefetch related or two that needs to happen, but it should be doable. I would be worried about I've seen uh a lot of groups. People because it's so easy to create a group or a role uh people love to create them.

Speaker 1: Yeah.

Speaker 3: And I've seen sites with like hundred plus and what happens when someone is in older groups.

Speaker 1: Yeah.

Speaker 3: That's gonna change the layout of the pitch quite a bit.

Speaker 1: Yeah, yeah, yeah.

Speaker 2: It takes the whole the entire screen just for one row of the table.

Speaker 1: It's a diamond, like you have to refine it. It's not like you know like a guaranteed home run or anything.

Speaker 3: Well so many metaphors.

Speaker 1: No, but yeah, like this I don't know if it's a pony, but like pretty clear. I can see the need for this right away. Definitely there's a need for discussion on exactly how you display it. And performance wise, like definitely two, but I suppose that's why we paginate those views, right? It should be enough to do this for 20 users at a time.

Speaker 2: Yeah, but you know, for example, I I guess this is a an example of a good comment because, you know, it also goes through these performance considerations, but th those were not in the issue originally. So um yeah that that's the kind of thinking that we'd like to see before someone just submits a PR, for example, without having prefacts related, and then we have to um Yeah, th the the review would be so much quick quicker if if all these discussions have been done firsthand

Speaker 1: If only people came up with perfect feature requests.

Speaker 2: Well, no, that's that's the point of discussing it in in the issue.

Speaker 1: We discuss it first before someone spends their time building it in a way that isn't quite right.

Speaker 2: Yeah, that's that's my point.

Speaker 1: Okay. Well you know the next thing we're gonna need to do once we define all those extra states is writing down what's helpful to do in each and every one of those states So we'll need to have a list of okay like when we say community input, okay, we need to share use cases, okay, we need to like um explain how frequent of a need this is when it's maintainer input it'll be like okay consider performance consider the UI I think we're gonna need to write all of that It's gonna be good for us, I assume, to document this. That's things we consider anyway, just without necessarily it being explicit, right?

Speaker 2: Yeah

Speaker 1: Oh, another diamond. Look, this has been like sitting there, innocuously tagged as a UX enhancement. It's almost like you could just make a pull request and go for it if you only looked at the labels and nothing else. So I think this needs needs RFC.

Speaker 2: But there's an RFC for that.

Speaker 1: Yes, but now the RFC needs approval, I suppose.

Speaker 2: I guess so.

Speaker 1: Do you do you dig RFCs, Baptiste?

Speaker 3: Not really. I'm not really uh an RFC RFC person.

Speaker 1: It's tricky because it definitely feels like you know we are here is this feature request we don't know quite what to do with let's burden you with hours worth of research and technical analysis and architecture decisions. But I suppose sometimes it is what it needs.

Speaker 3: Absolutely. But I I'm more of like getting my hands dirty kind of person.

Speaker 1: Yeah.

Speaker 3: And uh The RFC is too abstract for me. But sometimes it is the answer. And sometimes it is a way to get rid of someone you don't want to say no to.

Speaker 1: Yeah, I'm I wonder how RFCs are gonna um evolve in the AI world because So much more approachable to do proof of concepts now. And uh sometimes it does feel like you know It's not necessarily that needed to have your ideas written if you can just show that it works in this or that way Um I think we I think we have a good plan, no? Community input

Speaker 1: maintainer input accepted needs some kind of um confirmation of the approach so that's four more labels I just need to write this up as a proposal, take it to our core team.

Speaker 2: The needs confirmation thing is does that replace the or is that basically our current needs design decision?

Speaker 1: No, I still think we'll have things where we need like we should convey separately that someone needs to Yeah, I guess in my mind this clearly separates, but I need to think of how to phrase this.

Speaker 2: I think m my what I'd like to see the most is the accepted label.

Speaker 1: Yeah.

Speaker 2: That would also make it much easier for new contributors to, okay, I can pick from this list of issues that have these uh this label and have a bigger chance of it being accepted because the issue is already accepted.

Speaker 1: And then we retroactively add it to existing issues or the opposite?

Speaker 2: Yeah, I mean if w you know that's that's a bit where if we have time we'll go th back through like or you know if someone leaves a a comment on an older issue like Uh so that it it it gets our attention and then we see that oh it makes sense. Um we can just add the accepted label, but you know, we don't We might not have time to go through all the issues, but I I think if we could go through all of them at some point, that would that would be great.

Speaker 1: Yeah I think Baptiste is um on the money with saying we should always say also say no. I feel like I'd love to say no to half of these. just so that the other half sticks out a bit more as like the the here are the things that actually move the needle meaningfully.

Speaker 3: I think letting an issue of um go un unaddressed is just like a I'm gonna say the coward's way to say no, even though it's already cowardice, it's just like it's really hard to say no. But in effect it is a no when you just Don't choose it so being able to say no is a lot more explicit about your intent not to pursue this And if you can put up a process in place that makes it easier to say no, I think that's also very valuable.

Speaker 2: I think w one of the reasons why we don't close it right away is because we want to hear from other people who might need it and leaving it open makes it easier to discover.

Speaker 1: Yeah. Yeah, I think the problem is is definitely though like this current label or I guess lack of status label, it becomes really time consuming to have to figure out for a given issue, is it of the type that you can pick up now? Is it of the type that it's underwhelming and we don't know how to respond to it? Is it of the type that it's promising and uh we just need more information This makes me wanna spend the rest of my day reviewing all existing feature requests.

Speaker 3: I would just take the last order by activity, take the last five pages and close everything.

Speaker 1: Do you think?

Speaker 3: Don't even look at them No, I'm being facetious, but

Speaker 1: honestly, you're probably right, because um definitely the ones that have the least activity, they're the ones that are easy to open and hard to make progress with.

Speaker 3: I mean I'm always wary of these kind of auto-closing stale issue types of like bots or whatever. Yeah. Because sometimes You know, it's the usual stuff. It depends. Sometimes there's a good reason why something hasn't happened. And you know, like we've mentioned a few times autosave this giant feature that shipped recently that's has been in the works for However, maybe now it unlocks things that can uh make these old standing um issues like tacklable. So sometimes It depends. Sometimes you want to close all this old stuff that's aren't really relevant anymore. Sometimes some of them like I used to do this a lot with Django

Speaker 3: of going through old stuff and try to figure out if they're still relevant. Sometimes they've been fixed already, sometimes another change made them irrelevant. I think that get that can happen a lot with projects that span years.

Speaker 1: Yeah.

Speaker 3: But yeah, no closing

Speaker 2: who submitted the issue doesn't even care about it anymore. They moved on.

Speaker 1: Even them have moved on. It's just you the maintainer staring at something that no one else cares about.

Speaker 3: But also maintainers come and go like Sometimes everyone who was involved in this is gone. Some people like

Speaker 2: Yeah, it's a relic of an old world.

Speaker 3: Yeah, but it it doesn't always mean that there's no value in them anymore. Like that's kind of the beauty of open source is that it can also transcend people coming and going and like But there's still value in the code or in the problems it solves or the issue being described can still be solved by people who have not you know everyone's gone but the new person comes and solves the issue and then It adds value, so

Speaker 1: Yeah. Our process, at this my process for this in Whiteel in the past has been um definitely no auto closing at a set time. Like it's so so grating. I'd much rather do it as a human, even if it takes me a bit of time now and then. Um, but try and move some of those things to discussions so that you know the discussion is still out there, you can still add to it. Uh but just be clear that there's not necessarily gonna be we're not sure that there's gonna be any one change that could meet the the brief for the improvements. No, this has happened. This has happened years ago. But maybe not enough. Anyway, um I think we should leave it there in interest of time.

Speaker 1: It's been fun. I'm looking forward to um reviewing our backlog while first making a proposal for this new triage process and then reviewing our backlog Uh there's one thing we haven't discussed. I'd really like to discuss at some point. We do have people like Baptiste in our community who aren't on the core team, but I think have pretty good I guess taste when it comes to I I mean it, you know, test taste when it comes to triage and decisions on Django projects. So one thing I'd really like us to try is actually to not necessarily have this just rely on the core team, but a wider pool of trusted contributors. Which

Speaker 1: um yeah, I guess is a whole other story. How would you feel, Baptiste, if I granted you the triage permissions for the Wagtail backlog?

Speaker 3: I'm not sure I would feel confident in making these kinds of decisions of like closing and moving things forward, but I think I go into uh into moods where sometimes it's I feel really hard to say no to people. It's like very empathetic. Oh it's a person coming in is project, it must be scary. They really they were brave. They put themselves out there. And sometimes, you know, I just see an AI slope pull request. I'm like, well, F this. F this S uh and just like close like no uh AI slot. So it's I think triaging is is there's a uh very really big social aspect to it of um

Speaker 3: You you're in many ways kind of the first thing people will see when they enter a new project is oh I opened an issue and it was closed by someone saying no and no comment. It can feel really discouraging.

Speaker 1: Yeah.

Speaker 3: Or you copy an issue and then people like welcome you and like point you to the right place and then maybe you become a recurring contributor and you know So and then and then there's a whole range of scenarios in between.

Speaker 1: Yeah.

Speaker 3: But I do think triaging effectively you need to kind of feel that you're trusted and that you have the right instincts for moving things forward or not backward I guess to stop them in their tracks

Speaker 2: Trucks.

Speaker 1: Yeah, it's a balance. I would like to think that we will still find plenty of time for people who mean well with or without AI to make good um good requests and good um You know, good pull requests, but also good feature requests. Um, but yeah, if I can tell that you're not trying too hard. And definitely it probably also often means you're using way too much AI, then I only have so much patience and time to spend on that Um yeah. Things are shifting. We'll see where we land.

Speaker 1: Thanks both. It's been interesting. And um See you next week.

Speaker 2: Alright. Thanks everyone.