>
I am very much in favor of modernizing our communication tools. But I don't think this is the way to go (but I don't know anything better, except maybe a more "traditional", more structured forum).
I'm up for modernizing things and making them more efficient as well, though as Matthew replied to me earlier, that's not his reason for suggesting it.
Having taken some more time to consider this and thinking about the past, I've actually sort of already experienced this when I was a PuppyLinux dev. At the time, we used a forum as their primary means of dev communication. (I think they still do, but I'm not sure) Puppy is a different dev community with many working on their own derivatives of puppy but happily collaborating together with other devs doing their own side thing.
I'm up for modernizing things and making them more efficient as well, though as Matthew replied to me earlier, that's not his reason for suggesting it.
Having taken some more time to consider this and thinking about the past, I've actually sort of already experienced this when I was a PuppyLinux dev. At the time, we used a forum as their primary means of dev communication. (I think they still do, but I'm not sure) Puppy is a different dev community with many working on their own derivatives of puppy but happily collaborating together with other devs doing their own side thing.
While there definitely was an increase in interaction with people, that also came at a cost. Two or three devs having a conversation in a thread would also have to deal with a dozen or so no- devs chiming in on the situation and putting in their two cents. Time and again this would end up being nothing more than a distraction, an argument, or causing a developer to end up going to PMs to discuss the bug they were trying to resolve instead of doing it openly.
The users who were jumping in on the thread weren't doing so maliciously, they were actually trying to help, but due to not understanding the issue it ended up doing the opposite.
The problem with mixing general community discussion and development discussion... is you get exactly that as the outcome.
While this did sometimes result in a community member getting more involved in development, I am/was an example of that, it also had the result of causing devs to end up relying on direct emails or PMs to other devs to cut through the chatter of most of the thread being non relevant or wasting time to read through replies that are off topic or unhelpful. And once that communication went private, it was no longer accessible to any other devs to read. This resulted a few times in bugs being fixed in some custom releases but not others, and devs having to re-engineer the same fix because the solution that was found wasn't open. That's less of a problem in Fedora's case because it's not disjointed like Puppy, but it could still happen if there was an issue a dev was dealing with patching source due to some GCC update.
The fact is with a mailing list, someone has to intentionally seek it out and sign up. You dont run into the people casually ending up in developer discussions around esoteric but important engineering discussions.
In the real world I'd relate it to this...
A small housing development somewhere, that occasionally has visitors who just drive through to check the place out and look at the neighborhood.
Versus
When there's a detour on the highway and the entire interstate's traffic ends up getting routed through that same small development to get back onto the interstate later.
The first case is one that no one really gets upset at, the latter is one that almost no one is happy with.
I feel like there is a delicate balance between not making communication hard or putting up roadblocks... and making it so easy that the volume becomes a distraction for those that are trying to get code work done. We know what we have now mostly works even though it's not very elegant and has its own issues. Updating tools, encouraging new people to get involved in development are great things, but we dont want to take one step forward which results in two steps back for development overall.
Maybe this can be addressed somehow with discourse, but I am clueless as to how.
Hopefully those smarter than I can find the right balance for what we should use.
The users who were jumping in on the thread weren't doing so maliciously, they were actually trying to help, but due to not understanding the issue it ended up doing the opposite.
The problem with mixing general community discussion and development discussion... is you get exactly that as the outcome.
While this did sometimes result in a community member getting more involved in development, I am/was an example of that, it also had the result of causing devs to end up relying on direct emails or PMs to other devs to cut through the chatter of most of the thread being non relevant or wasting time to read through replies that are off topic or unhelpful. And once that communication went private, it was no longer accessible to any other devs to read. This resulted a few times in bugs being fixed in some custom releases but not others, and devs having to re-engineer the same fix because the solution that was found wasn't open. That's less of a problem in Fedora's case because it's not disjointed like Puppy, but it could still happen if there was an issue a dev was dealing with patching source due to some GCC update.
The fact is with a mailing list, someone has to intentionally seek it out and sign up. You dont run into the people casually ending up in developer discussions around esoteric but important engineering discussions.
In the real world I'd relate it to this...
A small housing development somewhere, that occasionally has visitors who just drive through to check the place out and look at the neighborhood.
Versus
When there's a detour on the highway and the entire interstate's traffic ends up getting routed through that same small development to get back onto the interstate later.
The first case is one that no one really gets upset at, the latter is one that almost no one is happy with.
I feel like there is a delicate balance between not making communication hard or putting up roadblocks... and making it so easy that the volume becomes a distraction for those that are trying to get code work done. We know what we have now mostly works even though it's not very elegant and has its own issues. Updating tools, encouraging new people to get involved in development are great things, but we dont want to take one step forward which results in two steps back for development overall.
Maybe this can be addressed somehow with discourse, but I am clueless as to how.
Hopefully those smarter than I can find the right balance for what we should use.
On Fri, Apr 21, 2023 at 10:15 AM Peter Boy <pboy@xxxxxxxxxxxxx> wrote:
> Am 21.04.2023 um 15:37 schrieb Emmanuel Seyman <emmanuel@xxxxxxxxx>:
>
> * Fulko Hew [20/04/2023 21:18] :
>>
>> Can you say the same for Discourse?
>
> ... leave a lot to be desired. So much so that
You put it very nicely. I have been desperately trying to follow new posts under the tag #server via email notification. Total failure. I missed everything.
A nice collection of "bells and whistles" just doesn't cut it yet. Currently, it is far too unreliable for systematic and long-term professional activities.
And it is structured in an undercomplex way. Try to find something further back in time. You must have a lot of boredom. A simple grouping by year/month like the mailing lists is very comfortable in comparison.
And I think that's not what discourse was originally designed for. We are now trying to squeeze in something that works "somehow". An 'egg-laying, milk-gearing woolly pig' like with the infamous SAP software in some companies. And the problems that Matthew accurately describes (lengthy discussion, abusive discussion style, etc) cannot be solved by this, in my opinion.
I am very much in favor of modernizing our communication tools. But I don't think this is the way to go (but I don't know anything better, except maybe a more "traditional", more structured forum).
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
