Hi Matthias, On Sat, Mar 14, 2026 at 2:52 PM Matthias Andree via Mailman-Developers < [email protected]> wrote:
> Are you sponsoring the completion of what the student project has left > behind half-done? The projects have cost (effort) with design > reviews, advice, communication, but evidently these student's projects > did not complete to integration (time/quality), and nobody/nothing > stepped up to take them behind the goal line outside GSoC. > I'm not sponsoring them since I believe Google handles that, but overall, I have no issue with sponsoring them to completion - both financially and man/hours-wise. No one ever asked me to do that before. > So _how_ do you, Danil, propose, concretely, to organize the required > items (resources, expertise, acceptance) to get those half-finished > items completed and integrated? > As a bare minimum, we can have a list of half-done projects somewhere, since after I did an extensive manual search, I didn't find any information on them! The only place where I learn about them is this mailing list, and they are like moths: they appear for a second only to disappear forever. > Else the GSoC graveyard as you call it is the dignified version of the > scrapyard where so many other GSoC efforts landed. And maybe it's fine > if it's something new and a prototype that everyone can learn from - > scrap it, and then redesign, and do it right -- after you've learned > from the prototype. Research is also about finding out what does not > work. This absolutely makes sense. Perhaps I should consider GSoC as a CS students' educational initiative only, rather than an effort to improve Mailman. My view on GSoC might be wrong. But the list of ideas does not sound like educational tasks at all. They sound like the most important and most wanted features, so I'm jealous that they keep disappearing into a void every year. > GSoC does not have a success warranty implied, no project has, it > takes diligent work - and GSoC is deadline-constrained with a bit of > regard for quality (midterm review, per 2026 rules) and the overall cost > is charged to the "organization" and the mentor. > But what is your view on the expected success rate? 1 of 5? 1 of 10? Should we expect projects to be merged into the codebase at all? Based on historical data, the answer might be "no" (I haven't found any projects merged into Mailman after GSoC in the last five years). If this is the case, my questions are definitely irrelevant, and I'd say the entire GSoC-related discussion in this list, honestly, too. If we don't expect any benefits for Mailman from GSoC, why use this list, given all the discussion? It needs its own list, dedicated primarily to GSoC rather than Mailman. > GSoC doesn't cover the second phase though, so integration of GSoC-made > material seems like a game of luck. > Hm, I didn't know that. If the current Mailman maintainers are too busy to make this happen, I'd be happy to participate and ensure that valuable contributions reach the Mailman codebase! Especially those the most wanted by the community. > That being said, if your concern is mailman being valuable, what makes > you think it critical that past GSoC bits that haven't fallen into the > place you'd wished for? Why would one value a half-finished GSoC > material package more highly than Mailman? > I didn't get it, sorry, please elaborate. Sincerely, Danil Smirnov > > -- > Matthias Andree > > _______________________________________________ > Mailman-Developers mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/mailman-developers.python.org/ > Mailman FAQ: https://wiki.list.org/x/AgA3 > > Security Policy: https://wiki.list.org/x/QIA9 > _______________________________________________ Mailman-Developers mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
