Re: Unified internal communications channel
On Donnerstag, 7. Dezember 2023 18:04:24 CET Carl Schwan wrote: > On Thursday, December 7, 2023 4:15:36?PM CET Nate Graham wrote: > > What I'm proposing is some kind of place that *only* has internal > > announcements and is very log signal-to-noise such that we can > > fearlessly recommend that *everybody* subscribe to it. In addition, > > ideally those who want to subscribe via mailing list could do so, but > > its content would automatically appear in other places too, such as > > discuss.kde.org and an invent.kde.org project. That way people can > > subscribe by whatever means is most comfortable to them. > > > > Thoughts? > > I fear this will just create a new source of information instead of unifying > the source of information. We already have the following channels for > announcements: > > - planet.kde.org: contains release announcements, gear release schedule > announcement from Albert as well as random development updates > - kde-code-de...@kde.org: contains mostly news about new apps and modules > - kde-de...@kde.org: contains the gear release schedule announcements and > other technical announcements > - plasma-devel@kde.org: contains important for plasma developers and the > meeting notes of the monday chat meeting. > - kde-commun...@kde.org contains general community (non technical) > announcements > > Adding a new channel that is either a mailing list, rss feed or a forum > category won't help and will probably only makes it worse. It's also very > difficult to defines that is an important internal news for the whole > community is as it will be different for every subproject in KDE. The > plasma logo discussion would have not been very relevant for any app > developers. Similarly discussion about the new default database backend for > Akonadi won't be interesting for Plasma developers but might be interesting > for KMyMoney and other non-PIM apps using Akonadi. Technically we do have a low-traffic channel for everyone even, kde-cvs- announce. That one is even mandatory for people with contributor accounts AFAIK, you get added to that by default. However that is really only for things relevant for everyone, such as important infrastructure changes. A topic like the one that triggered this discussion obviously doesn't qualify for that, that was mostly relevant for people involved in Plasma. So we'd need to clarify who we mean by "everybody" here, and I suspect that will be a subset of people varying from topic to topic. If so, one more channel is unlikely to magically fix things I think. > Something that might help is merging the kde-core-devel and kde-devel > mailing lists as those are very similar and should hopefully not be too > complicated to do. And/or kde-frameworks-devel, yes, we probably don't need all three of those anymore. While it might help a bit in finding appropriate channels to address the subset of people you want/need to reach it's somewhat orthogonal to Nate's proposal and would not have made any difference for the Plasma logo discussion I think. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Unified internal communications channel
On Thursday, December 7, 2023 4:15:36?PM CET Nate Graham wrote: > Hello everyone, > > There have been a couple instances of drama this week caused by > decisions being made without some of the relevant stakeholders knowing > about them. In all cases, the decisions were announced, but either not > announced in the places where all the stakeholders saw it, or not all > stakeholders were able to notice the announcement in a place where they > do generally pay attention. The drama could have been avoided if the promo folks would have followed my recommandation to contact the relevant stakeholders in the plasma- de...@kde.org mailing list or attend the Plasma chat meeting hapenning every Monday at 4 PM in the Plasma matrix/irc channel. I tried to bring this up many times and it was dismissed every time i brough it up and I was told that I didn't understood the proposed idea and that should re-read the previous messages. It is unfortunately a recurring pattern in the promo channel and I decided for now to leave the kde-promo matrix channel as I feel like I'm wasting my time there. > It makes me think that maybe the KDE development community has grown so > large that we can't reasonably expect everyone to be paying attention to > everything, or for everyone with something to announce to know exactly > where the people who need to know it expect to find those messages. > > So perhaps this could be addressed at the source by creating a single > unified "internal announcements" place that everyone can pay attention > to without fear of being spammed with too many messages. In theory the > kde-devel mailing list is one such place, but it's got more than just > announcements, and also mailing lists aren't very accessible for a lot > of newer contributors who didn't grow up with them. > > What I'm proposing is some kind of place that *only* has internal > announcements and is very log signal-to-noise such that we can > fearlessly recommend that *everybody* subscribe to it. In addition, > ideally those who want to subscribe via mailing list could do so, but > its content would automatically appear in other places too, such as > discuss.kde.org and an invent.kde.org project. That way people can > subscribe by whatever means is most comfortable to them. > > Thoughts? I fear this will just create a new source of information instead of unifying the source of information. We already have the following channels for announcements: - planet.kde.org: contains release announcements, gear release schedule announcement from Albert as well as random development updates - kde-code-de...@kde.org: contains mostly news about new apps and modules - kde-de...@kde.org: contains the gear release schedule announcements and other technical announcements - plasma-devel@kde.org: contains important for plasma developers and the meeting notes of the monday chat meeting. - kde-commun...@kde.org contains general community (non technical) announcements Adding a new channel that is either a mailing list, rss feed or a forum category won't help and will probably only makes it worse. It's also very difficult to defines that is an important internal news for the whole community is as it will be different for every subproject in KDE. The plasma logo discussion would have not been very relevant for any app developers. Similarly discussion about the new default database backend for Akonadi won't be interesting for Plasma developers but might be interesting for KMyMoney and other non-PIM apps using Akonadi. Something that might help is merging the kde-core-devel and kde-devel mailing lists as those are very similar and should hopefully not be too complicated to do. Cheers, Carl > > Nate
Unified internal communications channel
Hello everyone, There have been a couple instances of drama this week caused by decisions being made without some of the relevant stakeholders knowing about them. In all cases, the decisions were announced, but either not announced in the places where all the stakeholders saw it, or not all stakeholders were able to notice the announcement in a place where they do generally pay attention. It makes me think that maybe the KDE development community has grown so large that we can't reasonably expect everyone to be paying attention to everything, or for everyone with something to announce to know exactly where the people who need to know it expect to find those messages. So perhaps this could be addressed at the source by creating a single unified "internal announcements" place that everyone can pay attention to without fear of being spammed with too many messages. In theory the kde-devel mailing list is one such place, but it's got more than just announcements, and also mailing lists aren't very accessible for a lot of newer contributors who didn't grow up with them. What I'm proposing is some kind of place that *only* has internal announcements and is very log signal-to-noise such that we can fearlessly recommend that *everybody* subscribe to it. In addition, ideally those who want to subscribe via mailing list could do so, but its content would automatically appear in other places too, such as discuss.kde.org and an invent.kde.org project. That way people can subscribe by whatever means is most comfortable to them. Thoughts? Nate
