Re: Officially adopt "Noteworthy" label into KDE policy
Thank you Nate and Johannes for your positive feedback. If there are no further complaints / comments, I'll edit the Commit Policy wiki page tomorrow and add the points I listed below. Cheers, Julian / xyquadrat On 18.09.20 10:05, Julian / xyquadrat wrote: Hi all, A few months back I suggested on behalf of the Promo team the introduction of a new label for issues and merge requests (see https://marc.info/?t=15869532709&r=1&w=2 for the thread). The idea behind this "Noteworthy" label was to make it easier for Promo to keep up with all important new changes that are coming up in our software and reduce the possibility that something noteworthy gets overlooked. Since then, the GitLab migration has been completed and such a label has actually been introduced (see https://invent.kde.org/dashboard/merge_requests/?scope=all&label_name[]=Noteworthy for an overview of Merge Requests tagged with "Noteworthy"). Given that the technical challenge is now solved, I'd like to propose to make this Noteworthy label official in the sense of adding it to the "Special keywords" section of Commit Policy (if there is a more appropriate place, please suggest it!) and encourage all contributors to start using it. A few remarks: - Of course all contributions are noteworthy and important. Promo does not want to discount the work that goes into small and unnoticeable fixes. - If you are not sure whether a MR or issue should be "Noteworthy" or not, tag it with "Noteworthy" (-> be liberal with the label usage). Promo will then consider such edge cases in detail. - Not all things tagged might make it into an official announcement. This is (usually) not due to us overlooking them, but because we have to carefully prioritize what we include. If you think something was left out that should definitely have been included, reach out to us on #kde-promo and we will be happy to discuss individual cases and solutions. *Examples of noteworthy changes:* * User facing feature additions (e.g. /New useful effect added to Kdenlive/) * Big changes in UI (e.g. /a KCM is rewritten in QML and now looks distinctively different/) * Long-standing, annoying bugs (e.g. /Rework of the previously bug-ridden MTP implementation in KIO/) * Large technology shifts (e.g. /Port to Qt 6/) * Significant performance improvements (best paired with concrete numbers, but not necessary) *Examples of changes not considered noteworthy: * * Small UX annoyances and fixes. Whilst those add up to something very important, the individual changes (e.g. "more consistent padding in dialogs") are not interesting to users. * Shifts in technology that do not affect the behavior of the product (e.g. /porting from library X version Y to library X version Y+1/) * Minor changes to tools and backends used in the development process Feedback and criticism is much appreciated. Cheers and have a nice day, Julian / xyquadrat
Officially adopt "Noteworthy" label into KDE policy
Hi all, A few months back I suggested on behalf of the Promo team the introduction of a new label for issues and merge requests (see https://marc.info/?t=15869532709&r=1&w=2 for the thread). The idea behind this "Noteworthy" label was to make it easier for Promo to keep up with all important new changes that are coming up in our software and reduce the possibility that something noteworthy gets overlooked. Since then, the GitLab migration has been completed and such a label has actually been introduced (see https://invent.kde.org/dashboard/merge_requests/?scope=all&label_name[]=Noteworthy for an overview of Merge Requests tagged with "Noteworthy"). Given that the technical challenge is now solved, I'd like to propose to make this Noteworthy label official in the sense of adding it to the "Special keywords" section of Commit Policy (if there is a more appropriate place, please suggest it!) and encourage all contributors to start using it. A few remarks: - Of course all contributions are noteworthy and important. Promo does not want to discount the work that goes into small and unnoticeable fixes. - If you are not sure whether a MR or issue should be "Noteworthy" or not, tag it with "Noteworthy" (-> be liberal with the label usage). Promo will then consider such edge cases in detail. - Not all things tagged might make it into an official announcement. This is (usually) not due to us overlooking them, but because we have to carefully prioritize what we include. If you think something was left out that should definitely have been included, reach out to us on #kde-promo and we will be happy to discuss individual cases and solutions. *Examples of noteworthy changes:* * User facing feature additions (e.g. /New useful effect added to Kdenlive/) * Big changes in UI (e.g. /a KCM is rewritten in QML and now looks distinctively different/) * Long-standing, annoying bugs (e.g. /Rework of the previously bug-ridden MTP implementation in KIO/) * Large technology shifts (e.g. /Port to Qt 6/) * Significant performance improvements (best paired with concrete numbers, but not necessary) *Examples of changes not considered noteworthy: * * Small UX annoyances and fixes. Whilst those add up to something very important, the individual changes (e.g. "more consistent padding in dialogs") are not interesting to users. * Shifts in technology that do not affect the behavior of the product (e.g. /porting from library X version Y to library X version Y+1/) * Minor changes to tools and backends used in the development process Feedback and criticism is much appreciated. Cheers and have a nice day, Julian / xyquadrat
Re: The chat situation
Hi, First off, let me say that I personally have been increasingly satisfied with Matrix and am of the opinion that once an alternative homeserver implementation (Dendrite or conduit.rs come to mind, both of them have top-notch performance) is ready for production, it will be the optimal solution for KDE. Additionally, as a young developer (< 20 years old), I very much appreciate how similar Matrix is to other chat services and would likely be less active if I had to participate via IRC. What I am asking myself right now is how to lead this discussion into the most productive way possible. I have gathered from the current mails in this thread that there is a wide variety of opinions, preferences and approaches to this problem. There has already been a community-wide poll (https://sessellift.wordpress.com/2017/09/05/results-of-the-requirements-survey-for-a-kde-wide-chat-solution/) back in 2017 - are the requirements based on this survey still accurate? Additionally, how can we most efficiently reach a decision on what to do? I suspect that simply talking about the pros and cons of Matrix and IRC will not get us anywhere. Best wishes, Julian On 11.06.20 01:16, Nate Graham wrote: Carson's email about bridging #kde-devel to Telegram got me thinking: we should have a discussion about the situation we're in regarding chat services in KDE. The current Matrix solution does not seem not optimal to me. I have really tried my best to be a good citizen and use Matrix as much as possible over the last year but I find myself gravitating back towards Telegram because of how much better the overall UX is, especially for fast-moving discussions and those involving images. I haven't found a Matrix client that offers both a half-decent UX and also a reasonable featureset. The service suffers from lag, sometimes severe. Periodically the federation breaks, or the bridge between IRC and Telegram breaks, leading to people's messages silently vanishing. The implementation of the bridge itself impedes discussions between Telegram users and IRC/Matrix users because when a Telegram user replies to a post made by someone on IRC or Matrix, that person person can't see the message being replied to. Overall it just does not feel like a great user experience. This situation really needs to be fixed, somehow. I'm not knowledgeable enough regarding chat software to be able to propose solution, but I don't feel like the status quo is something we should live with. Can we fix Matrix? Or should we migrate to something that offers a better UX? Nate
