On 21/10/2026 23:04, Tomas Härdin via ffmpeg-devel wrote: > On Wed, 2026-10-21 at 15:00 +0200, Michael Niedermayer via ffmpeg-devel > wrote: >> Hi Tomas >> >> On Wed, Oct 21, 2026 at 01:22:46PM +0200, Tomas Härdin via ffmpeg- >> devel wrote: >>> On Wed, 2026-10-21 at 00:09 +0200, Michael Niedermayer via ffmpeg- >>> devel >>> wrote: >>>> Also fairy today gained the ability to close PRs and Issues >>>> >>>> First issue she has closed: >>>> https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/24564 >>>> >>>> ATM closing tickets still requires human approval, but i will >>>> likely >>>> soon remove that latency as i expect her to be able to do that >>>> reliably >>> >>> A fancy Markov chain is not a person >>> >>> If we're going to be automatically closing tickets, why are we >>> delegating that to a statistical model, whose behavior is >>> fundamentally >>> random? >> >> We have >500 open tickets and not enough volunteers to review them >> all manually. >> That's why we're using Fairy to help with this. > > You could just let them remain open. Having thought a bit about it, I'm > leaning towards what Rémi said. There's no reason to close tickets. > What we could do is ping the creator of old tickets once per year > asking if the issue still exists and if not that they can close the > ticket if they feel like it. > > Tickets are also fertile ground for GSoC. We could ask students to take > a look at a couple of them. If we close them prematurely then there's > fewer to choose from. >
Just a note on this: GSoC's rules do not allow projects to be centred around maintenance work. I realise some tickets may not fall under that category, but it's preferred that students work on implementing new features, rather than bug fixes and the like. -- Frank _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
