Hi Andreas, Nice to see you in this thread. I guess this counts against my promise to raise this issue on the MLs a while ago ;-) On Tue, Jun 03, 2025 at 05:52:06PM +0200, Andreas Tille wrote: > > I've been thinking about this overall problem for a while now. Since > > several technical solutions I've considered seem organizationally > > un-viable, for the time being anayway, I've been pondering starting a > > "Welcome Team". > > This is another wording for "There is no technical solution for a > social problem". ;-) I'd be more than happy if we could find some > working solution. You know. I hate this way to frame organizational problem solving. It's hardly ever accurate or helpful. Isn't email just a technical attempt at the social problem of long-distance estrangement? Maybe we should go back to semaphores or smoke signals. [Now I wonder if history knows flamewars on those mediums :D] > > We would identify interactions of new people across the whole project by > > subscribing a bot to maaaaaany maling lists and as much of salsa as we can > > without getting hit over the head by admins ;-). > > Hmmm, sounds tricky. I don't think so. It already sends out slews of emails shouldn't make much of a difference. I had a quick look at the [gitlab code] and while there doesn't seem to be a convenient setting to dump all (public) notification mail somewhere I don't see an obvious scaling limit to user notifications. [gitlab code]: Start at services/notification_service.rb and trace from there. NotificationRecipients::BuildService.build_recipients is most relevant. The polling required to keeping the bot subscribed to all public repos could be a limiting factor, but since new project don't spring up that quickly I doubt it'll end up being a problem. Where there's an organizational will there's a technical way. Historically we have MLs for archiving archive/BTS changes (d-changes@l.d.o, d-bugs-dist@l.d.o) so why not also for salsa anyway? Seems to be a serious gap in our email centric workflow and archiving story to me :-). > > Given the unfortunate fact we don't see that many newcomers anyway this > > doesn't seem like too impossible a task using some light email and salsa > > API tooling. I've been meaning to build something fun with mblaze(7) since > > I found it anyhow :-). > > This rather sound also like technical attempts for a solution. Hardly. The strategy is human centric with technical augmentations :-). To be clear: I'm not suggesting we should automate the reach out, only the search&highlight aspects. > > Thoughts anyone? > > By all means, if we have volunteers who feel dedicated to guiding > newcomers, that's great and very welcome. In my experience, the best > path into Debian is often through a smaller, focused subgroup — one that > aligns with the newcomer's technical interests. Within these groups, > people tend to know each other better, which can make it easier to > notice and support newcomers and their needs early on. Exactly my thinking. Problem is many areas people could be interested in seem to feel hollow these days as exemplified by Joachim's experience. > I'm not convinced that creating a formal "Welcome Team" will solve the > broader issue. Instead, those who feel inclined to support newcomers can > already make a big difference by being approachable and kind — as we > sometimes already see happening quite successfully (though admittedly, > not always consistently). Indeed. I just worry about those people that fall through the cracks because all our inboxes are (likeley) already bursting and that newcomer desperately waiting for a response is buried somewhere among 10k other emails :| --Daniel
Attachment:
signature.asc
Description: PGP signature