Hello Carlo,

Carlo Zancanaro <[email protected]> writes:

> On Sun, Feb 15 2026, Sergio Pastor Pérez wrote:
>> This is interesting. I'm not someone with experience using Zulip, so I
>> really appreciate you feedback. I think this particular concern is
>> something we should fix socially, rather than it being the
>> responsibility of a tool.
>
> Absolutely. What I am describing is a social issue, but we benefit from
> the fact that expectations are already set for email and IRC by society
> more broadly. I don't think anybody expects real-time responses to
> emails, or days/weeks-delayed responses to IRC messages. (Although, it's
> possible that I'm just biased by my expectations of those tools - feel
> free to let me know if I'm completely off base!)
>
> Moving to Zulip means moving away from these expectations, which is
> fine, but it means we have to do real work to set and uphold those
> expectations.
>
>> [...] I propose to describe our expectations on our code of conduct.
>
> I'm not sure the code of conduct is the right place for this. Although,
> I don't know what is.

Right, maybe someone with a better view of the social organization of
Guix, has an idea on where to describe the expectations. I think it
could be written down in the website page, where the link to access the
community would be posted.

>> I worry that some newcomers from faraway time-zones may be excluded
>> from conversations or help due to the nature of IRC and them not
>> having a bouncer, which increases the boundary for participation both
>> economically and technically.
>
> I just wonder if this is looking for a technical solution to a social
> problem. The social issue is: "some people can't take part in
> synchronous conversations because of the different timezones" and the
> proposed technical solution is "we'll turn(/bridge) the ephemeral
> synchronous medium into a persistent (ambiguously) asynchronous
> one". I'm not convinced that's an improvement.

Maybe I have not been clear. I'm not proposing to remove any of those
platforms, the expectations for those have no reason to change, people
know what to expect from a mailing list; and if they do not, the will
find out as they use it. So I don't think that allowing newcomers to
participate on the mailing list from a Zulip webclient will necessarily
change things for the mailing list. What I would expect is to see more
participation from newcomers, and in the best case, this could lead the
project to gather more feedback from first user experience who
previously would not participate. The could describe things like how
intuitive the API has been for them or if they didn't understand some
particular part of the manual, those conversations could be discussed in
a mail thread, now with the participation of newcomers that do not have
much knowledge of mailing lists.

I believe most newcomers will play around with Guix, read manual and
blogposts, and once they are enough invested in the community, they may
decide to setup their mail client to participate in some of the
conversations where they could have a nuanced opinion. That was surely
my journey here. The problem is that by the time I got involved in the
community, I was no longer a newcomer, so we lost all this initial
feedback which I don't even remember.

How to gather this newcomer feedback has been a recurrent topic during
Guix days, so I know I'm not alone with this concern.

The idea is not to replace what we have, but to open new doors to
different interactions that our current media does not allow. Some
obvious ones are: video call integration, pinging across different Guile
related projects, polls, etc.

One thing I would expect to be impacted is the Guix help mailing list,
which I would imagine would lose most of the traffic, since newcomers
will, in my opinion, use Zulip for fast troubleshooting problems and
recommendations, which is the role that most of our fragmented chatrooms
are fulfilling (Matrix, IRC, XMPP, Telegram, etc).


Best regards,
Sergio

Reply via email to