In the past, KTextEditor notified the user about externally modified files with a modal dialog. Many users were annoyed by this behavior.
Starting with KDE Frameworks 5.27, KTextEditor will show an embedded widget for external changes, see:
Dominik and me got the Akademy 2016 Award for our work on Kate and KTextEditor.
I want to pass that on to all other contributors of both the application and the framework: You all rock and people seem to appreciate our work!
Lets keep on improving our stuff and providing people with a very usable editor and editor component for various use cases.
Arrived at Berlin for Akademy/QtCon 2016, too ;=)
Already met some other KDE & Kate people, lets see how the week goes.
I was contacted by Buovjaga from the LibreOffice QA team to spread the word about the current bug triaging efforts going on.
Therefore now a short guest block about that ;=)
Thanks to Buovjaga for trying to get some public interest in this important aspect of open source work: handling our flood of bugs!
Free software needs more contributors from the non-coding user community. The problem is that there is no scientifically proven method for attracting them.
After dealing with thousands of LibreOffice bug reports and simultaneously trying to recruit more testers through various cunning plans, I realized the topic of free software quality assurance needs to become more prominent. I came up with the idea for a publicity stunt where I camp out at different bug trackers while telling the world about it. I chose KDE and Kate for my first month of triaging.
Bug triagers act as guardians of the bug tracker and save the developers from a lot of wasted time. If the number of unconfirmed reports in a project is not close to zero, it needs more triagers.
There were about 120 reports I deemed suitable for testing. I skipped crash debugging, testing of advanced features and only focused on the basic stuff. My take on the stats is that there is currently no one doing this sort of thing regularly for Kate.
To get started in triaging KDE bugs, you
– start testing unconfirmed reports and ancient confirmed ones while keeping the Bug triage guide at hand https://community.kde.org/Bugsquad/Guide_To_BugTriaging
– join #kde-bugs IRC channel after having commented on a bunch of reports and request rights to edit report details
– join the IRC channels of the products you are helping and coordinate testing with others https://userbase.kde.org/IRC_Channels#Applications
I believe a goal should be set for recruiting one person to deal with triaging per every actively-developed KDE product. After achieving this goal, it will quickly become apparent to each product team just how many triagers are needed in order for the work to be sustainable. However, the teams should not remain in isolation. The whole of KDE needs to become transparent. An “Everything about KDE” web dashboard would enable contributors to quickly see, which teams are in need of assistance. Tools for this are available in the Grimoire Lab suite http://grimoirelab.github.io/. KDE sysadmin team does not have the resources to set them up, so if you have the necessary skills and want to make this happen, please contact them on the #kde-sysadmin IRC channel.
If you want to contact me, you can find me on the #libreoffice-qa channel @ Freenode network, nickname: buovjaga.