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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEV6G/FbT2+ZuJ7bKf05SBrh55rPcFAmhAY5gACgkQ05SBrh55 rPcfoBAAvoWiSpKaC6y3Z9aHOut5WnanwXT0lgrp206cmbcPtlGj2QpqMaUsW38A jl2xkthFXZF74hIbnvbsJJEm0uRdhwlx6xFQJW4LTQ5ys4ZBNSTnv1fjUfA/6raF BM76PcxRwO/ssYGWF6tak74L2ThHpP1VdFYW2S6F7CkiM7KiAMISB5OkmVkKuKbB INrOt3/9RiZrO6d6XUs0cqudH4QMywQqMwflT+SqyAx4dcg18ZkGXF1w4OWXCw1+ QYq/ru5RKBrMChDxl/2gIO1GhiYjZF1N2ULpMF2EtUb0VHe+c3y2OHR8wfvdmmmz FU6DpeFY56AR9hsgG9xtPzpNPymgABQ6GmlRXCRFUA3d1cn+4Q7/NtzG9oNLSYVn EI6ew/sne2ra6yUPt0hUX5NDhjYz4eeErnVXtrTnMfOTkeLBjUO3ODtx9kc0ze1F 2F67Fgb+A1Lm4q0FDXu+/XQ8bIJnVCQ8Eam1qnkHWnVm1qww30bULIL8VXH4yQBJ XVPWmsZrWASkKCMxeVgfpllAQ6HBS3d7YB+ugBedIzts4jC5G3cP0fWxUjuLixvi ci62HctaOv411mnSchqhOEeRetXpSEgEtVYlYnluhlXuKYHFNiJc5ecUvVx1Jm7t 01fTOUWRvhmgoF4vV12x0RqjRFN4ZHJRS37AkKUeWUMfI6i2/7M=
=+czg
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)