Please only vote if you have contributed to PieFed in some capacity (e.g. coding, translation, reporting bugs, discussing bugs) or might in the near future!

Currently, we have two different developer chats on Zulip and Matrix. This means, that new devs will be confused about which channel to join and experienced devs have to actively look around in both channels for questions to answer. This seems like a really inefficient system, so we should at least decide on one official communication channel.

More discussion at https://piefed.social/c/piefed_meta/p/1964543/we-should-rethink-how-the-communitcation-channels-for-piefed-devs-work

Personally I find Matrix to be a pain in the ass and prefer Zulip. But it hasn't managed to attract as many users as Matrix has despite pushing it quite hard for months. Also PieFed development has started to bleed over into PieFed naturally, such as !piefed_css@piefed.social and !piefed_plugins@piefed.social. So we're in an awkward place at the moment.

31% A PieFed community, only
3% chat.piefed.social - Zulip
10% Matrix channel
18% PieFed + Zulip
21% PieFed + Matrix
13% PieFed + Zulip + Matrix
3% Zulip + Matrix (what we have now)
3% Zulip
39 votes - ended 7 months ago
you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 7 months ago* (last edited 7 months ago) (7 children)

an option that seems to be surprisingly absent is discussion where the source lives, on codeberg. imo it's very useful to have persistent discussions close to the source.

while i still consider matrix to be the best option for chat on this list, primarily due to federation, it's mostly useful for ephemeral conversations. finding old messages in matrix is often a pain, knowledge isn't searchable (search engines won't see this at all), and even new joiners typically won't have "all" history. structure with threads is also still very limited due to there still being a fair number of clients without thread support.

having discussions in codeberg issues also makes it a lot easier simpler to find context when you e.g. look at a commit, find the associated PR, then see the linked issue with the discussion.

edit to add more info:

what i've also seen in various projects in the past is when more complex issues have been discussed in chat, that a summary and key elements of the discussion or even a copy of the conversation will be persisted to e.g. issues, to allow for easier discussion (real time communication can work a lot faster and more efficient when there is some back and forth) while also ensuring that the information isn't lost over time.

i voted for piefed + matrix, but in reality i'd prefer codeberg + matrix. with federation, codeberg + zulip would likely also be a good alternative.

  • source
  • hideshow 7 child comments
  • [–] [S] 4 points 7 months ago (3 children)

    We can take it as a given that codeberg will always be with us.

    It is very much a forge, though, not a true discussion space. Issues only have a single thread, @mentions only work with contributors, banning is limited or non-existant(?) and so on.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 7 months ago (2 children)

    do mentions really only work for contributors or is it more of an issue of people not being autocompleted when typing @? i noticed earlier today that autocomplete doesn't even work for people who previously contributed, like @wjs018@piefed.social. maybe it only autocompletes for people who already commented in the issue/PR?

    in terms of banning, it looks like this has been implemented 2 years ago already: https://codeberg.org/forgejo/forgejo/pulls/802

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 7 months ago (1 child)

    I think the autocomplete only works for certain users - the owner and anybody already involved in the issue/PR, but I haven't thoroughly tried to test this at all.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 7 months ago (2 children)

    finding old messages in matrix is often a pain, knowledge isn’t searchable (search engines won’t see this at all), and even new joiners typically won’t have “all” history. structure with threads is also still very limited due to there still being a fair number of clients without thread support.

    All of these issues are solved on Zulip

  • source
  • parent
  • hideshow 2 child comments