Get your Christmas presents: Amarok 2.5 and KDE 4.7.4 on Windows!

Our KDE-Windows team has been working silently in the background to present you a whole new experience: You can now use your preferred Desktop experience and Audio player on MS Windows, too!picture by Patrick von Reth

Indeed, Amarok 2.5 is the first stable version we release on Windows, offering the same options as the already famous Linux version does. To quote Patrick von Reth, the developer who brought Amarok 2.5 to the MS Windows platform: “In 2005 when I first used Amarok on a Live CD and whished they would support Windows I never imagined I would be the guy who would help bringing it to Windows”.

As a special Christmas gift you can now use the KDE 4.7.4 software compilation on Windows as well. Although still not considered stable and suitable for production work, it is worth a try as it brings a lot of improvements such as the brand new Konversation IRC client 1.4 version, the personal finance manager Skrooge in version 1.1.1 to only name a few KDE applications and, as a technical preview, the speech recognition software Simon in 32-bit. You can get Amarok 2.5 as a standalone product or, even better, install it together with KDE 4.7.4 through the KDEWinInstaller.

Don’t hesitate and get your preferred Free Software on Windows as well :)

Posted in Amarok, Free Software, KDE | 19 Comments

When is a bug report useful?

Every now and then we get the same complaints about bug reports again: Either it is a complaint by the user who feels her/his report doesn’t get enough attention from the developers or it is the developers who complain that there are too many bad and useless reports making them spending too much precious coding time on triaging bug reports.
Disclaimer: I am not a developer but do bug triaging, documentation writing and application testing.

I think personally that bug reports are an important feedback from the users, provided those reports are indeed useful to the developers. But what is actually a good bug report? I will restrict my explanations to KDE and its Bugzilla bug tracker, but this applies of course to all bug reports.

1. It should be about the most recent version available

I know that not everybody is updating their computer regularly, some people only do security updates which is probably well enough for their use case, but they should also be aware that Free Software is fast-paced and most developers are already working on newer versions and may even be some versions ahead. In general, bug fixes are not backported to previous version by the developers, simply due to lack of time and manpower.

If you use an older version you can still report it to your distribution if they provide support for it, though. Some distributions even do backports, but also rarely to older versions a smost do not have enough resources either.
Don’t forget to specify the exact versions of the product and of KDE (available in the Help menu of all GUI applications).

2. It has to be reproducible

A one-time bug is not reproducible, so it is impossible to fix as the developers need to be able to reproduce it to test and search the location in the code where the problem lies. It is also very important to give a short step-by-step guide how to reproduce the bug.

3. The subject and comment must be in English, easily understandable, and searchable

If you can’t report a bug in English, please don’t. The KDE community is international and the working language is English as it is the one most people in the community understand.
We often get reports with subjects like “Doesn’t work” or ” Your application sucks, fix it!”. This is of course not very clear and highly subjective. For a bug report to be useful it must be well described so it can be searched in the database and so it is actually understandable by the developers.
The Subject should be a short sentence summing up the important points of the bug, for example “Product X crashes when clicking on Icon Y”.
You can and should give more details in the following comment, but keep it short and with a clear structure.

4. The report should be unique

Some bugs will hit many people so it is not unlikely that many people will report it. This leads often to duplicate bug reports which need to be eliminated and collected into one unique report. Knowing that more than half of the reports we get are duplicates this will of course cause quite some triaging work.
When reporting a bug a well written subject line will allow to find duplicates in Bugzilla quite easily. It is even easier if it is a crash as usually Dr. Konqi will suggest duplicates by querying the database. In doubt, don’t submit the report but ask in IRC, search the forum or the mailing list of the project if somebody has already seen it.
Bugzilla provides a very good advanced search query one can get used to quite easily.

5. If it is a crash, it should come with a valid backtrace

But what is a valid backtrace? Most distributions will strip the applications files of their debugging symbols to gain space, especially if they ship a CD and/or DVD of their versions. Those debugging symbols can be obtained separately and have file name endings like -dbg (Debian and Debian-based distros), -debuginfo (OpenSUSE) or -debug (Mandriva) for example. You will find more information and more distributions listed in this KDE Techbase summary.
Dr. Konqi will rate the backtrace quality with stars as you can see here:

A duplicate of Bug 282875

As a general rule: do not submit crash reports that do not have 3 stars as something is missing. If you don’t have debugging symbols installed, Dr. Konqi will warn you and provides the opportunity to install them directly from within Dr. Konqi.

Of course, a backtrace should ideally always be posted in the comment and not as an attachment, so it will be searchable in the database. Hint: the important thread is the one that has [KCrashHeader] after the thread header, so you can most of the time strip the other threads.

6. Be available to give feedback if needed

By submitting a bug report you get in touch with the KDE bugsquad and developers. Make sure you will be around to give feedback and you should also be available for testing if needed. If you are not willing to contribute in that way, please do not submit reports as it will be causing more work for other people to test.

7. Be patient and polite

It is not always possible for the bugsquad and/or the developers to get back to you immediately. We get an average of 50 to 100 reports a day, of which most will be either duplicates or invalid, so there is quite some stuff to get through in a day.

Don’t forget that this is Free Software and almost all KDE people work on their projects as volunteers in their free time. So shouting at people working as volunteers is totally counterproductive as they will probably prefer to do something else instead.
Make sure you stay on topic and be polite and helpful in the same manner as you would expect others to behave towards you, this is more likely to make people work on solving the problem.
Another point to consider is that your use-case is not necessarily the unique one, there are often many ways to do things in an application and you know that KDE is highly configurable for the users. Don’t expect to be the one who does use an application in “the standard way” and be ready to accept a workaround.

If you want to help, you can of course also give a hand in triaging to clean up the database. We welcome all volunteers who want to contribute to make KDE even better! Feel free to come to the #kde-bugs channel on IRC and have a look at the links given below.

UPDATE: Just to put this in perspective of the work ahead I asked Ben Cooksley, one of our sysadmins, to give me some numbers:

With the sheer number of reports in KDE’s bugzilla and not enough people to triage, a valid report can well get drowned: as of today, October 20th 2011 the database has

  • 278,805 total bugs
  • 1,173,947 comments
  • 64,469 attachments
  • 234,403 are CLOSED/RESOLVED/VERIFIED
  • 56,301 bugs were resolved as DUPLICATE
  • 20,250 were resolved as INVALID.
  • 40,571 open with the status ASSIGNED/ NEW/ REOPENED/ UNCONFIRMED
  • 3,830 are in NEEDSINFO status
  • 26,174 are UNCONFIRMED and need triaging

Thanks to Ben Cooksley, Martin Grässlin and Will Stephenson for suggestions and spotting typos :)

Useful links:

How to Report Bugs Effectively by Simon Tatham
Bug Writing Guidelines in Bugzilla
Quick Introduction to Bugzilla in KDE’s Techbase wiki
Guide to Bug Triaging by Dario Andrès in KDE Techbase

Posted in Amarok, Bugs, Free Software, KDE | Tagged , , , | 28 Comments

Last week in Amarok

The last days working towards a release

We plan to release Amarok 2.4 at the end of this week and our developers have concentrated their efforts on fixing release blockers and eventual regressions. A lot of users helped us with testing and pushing our favorite audio player through some heavy stress.
Since Amarok has quite a few features it is almost impossible for the developers alone to test everything and testing is a really easy way to help us making Amarok better. So let’s say a big Thank You to the many individuals who gave us some of their precious time.

Google Code-In ended

By Valorie Zimmermann: All good things end, so does this first edition of Google Code-In. For Amarok this was a big success and gave a lot of students aged 13 to 18 an opportunity to get their hands into Free Software development, Quality Assurance, Documentation writing and Translation to only name a few.
In the last 3 weeks, the following students successfully completed their tasks in Amarok:

  • Pedro Oliveira Raimundo
  • MTGap
  • Ivan Nakov
  • Daniel Marth
  • Paul Ivan
  • Eli Manning
  • Samuel Brack
  • Salma Sultana
  • Kristian Ivanov
  • coldblud
  • Goffrie
  • Caleb
  • Sasu Karttunen
  • It was such a pleasure to work with each of these intelligent, hard-working kids. Their emphasis on quality makes me very optimistic about the future of Amarok, KDE, and the free and open software world of the future.

    Bugs and wishes

    As mentioned above, the emphasis was on fixing release blockers and possible regressions. Our developers were really quite busy working on those fixes and invested some holiday time into it to make Amarok 2.4 really good :)
    We again got precious help by a Google Code-In participant, Timothy Lanzi, who tested and triaged iPod related bugs. Despite him being only 13 he delivered a truly excellent task and deserves a special Thank You for his dedication!

    A total of 126 were closed, here are the details:

  • Fixed: 48 reports, of which 11 were crashes, 5 critical or major bugs and 2 implemented wishes.
  • Invalid: 18 reports were not useful for us.
  • Duplicates: 50 reports were marked as such.
  • Upstream: 7 reports concerned a dependency.
  • Downstream: 2 reports were distribution related.
  • Wontfix: 1 report was closed.
  • Posted in Amarok, Bugs, Free Software, KDE | Tagged , , , , , | 1 Comment

    Last week in Amarok

    Since we were quite busy in the last weeks, here comes a report about the last month in Amarok. The main reason for this delay is the following:

    We released Amarok 2.4 beta !

    You can read all about the beta release here: Amarok 2.4 Beta 1 "Closer" Released
    Please test it extensively and report the bugs and errors you find. Thank you already for helping to make Amarok 2.4 even better!

    Transcoding is here

    By Teo Mrnjavac: The long awaited music transcoding feature from this year’s Google Summer of Code has finally been merged. Currently, transcoding between local tracks is supported with a variety of encoders, while transcoding to media devices is being postponed until we finish some major restructuring in the media devices stack. As the code is quite young it might be a bit buggy, so testing and bug reporting is strongly encouraged.

    Google Code-in tasks

    By Valorie Zimmermann: Our #rokymotion IRC channel has been humming 24 hours a day it seems, with all the Google Code-In students checking in. Tasks were written for an article for the next Amarok Insider, and many pages of the forth-coming Handbook. Since the Code-In continues until January, it seems like the students will help us even more in the coming month! So far, out of 20 tasks I’ve set, only three remain open for claiming, two are being done, and the rest finished successfully! This is a huge gain for Amarok, for KDE, and for the students also!

    At the half-way point, this is what has been completed:

    • Pedro Oliveira Raimundo (pedromundo): an article about APG for the Insider, the Handbook page: AutomaticPlaylistGenerator;
    • Sasu Karttunen (skfin): Handbook pages for the CoverManager and SavedPlaylists;
    • Ivan Nakov: Handbook pages PlaylistFiltering, and Playlist;
    • Daniel Marth: Handbook pages SearchInCollection, and TagEditor;
    • Paul Ivan: Handbook page OrganizeCollection;
    • Salma Sultana: Handbook pages ScriptManager, and ViewMenu;
    • Caleb: Handbook page AmarokMenu; rfw: Handbook page Playlist.

    A round of applause for their contributions to Amarok, to KDE, and to Free and Open Source Software!

    Bugs and wishes

    Over the last 4 weeks we had a more intense bug triaging, especially with the help of Ogynan Angelov and Samuel Brack who worked on the bug triaging task in KDE’s Google Code-In during the last two weeks.
    Overall we closed not less than 187 bugs: 73 bugs have been fixed, of which 22 were major bugs or crashes and we implemented 6 wishes. 8 reports were marked as invalid, 90 were duplicate reports and 9 were reports for bugs upstream. Thank you very much Ogynan and Samuel, you did a tremendous triaging work!

    Posted in Amarok | 22 Comments

    Podcast: Ian Monroe on KDE Masters of the Universe

    gamaral-at-workGamaral at Work. Image by Martin Cathrae

    KDE developer and master conspiracy theorist Gamaral has recorded a new Podcast episode of KDE and the Masters of the Universe. This time, the main guest is Amarok developer Ian “THE BEARD” Monroe, and co-host of the show is Mark Kretschmann.

    It’s a really good episode, the guys seemed to have tons of fun, and it’s also pretty interesting, as they reveal some secrets, as in every episode of the show.

    Please enjoy:

    KDEMU with Ian Monroe

    Posted in Amarok, Free Software, KDE | Tagged , , | 6 Comments

    How to submit patches for Amarok

    If you followed the Amarok development in the last 18 months, you have seen us move from SVN to Gitorious, and finally to KDE’s own git implementation, projects.kde.org. For patch submitters  and other external contributors there was always a bit of a confusion on what is the best way to submit code to Amarok. Unfortunately there have always been several ways, with the risk of loosing track of the patches, which is a sad side effect when there is too much choice.

    Since we moved to git.kde.org, we now also have a reviewboard! It is available here: git.reviewboard.kde.org and this is the perfect place to submit code for our project. String or feature freeze and code “not just ready” is no excuse to not use the review board

    So to all contributors: register at identity.kde.org and show us your code :)

    Important: Please, subscribe to amarok-devel@kde.org and first talk about your ideas there. Good ideas are often shared by more than one person and that can avoid two people working on the same implementation without knowing about each other. It is really mandatory for all contributors to talk to the team about their ideas before even starting to code to avoid such problems. And of course, don’t forget to read our HACKING guide!

    Posted in Amarok, Git, KDE | Tagged , , | 1 Comment

    Seventeen…

    .. is the total number of countries where the Multimedia/Edu sprint participants in Randa are from. You read that right: seventeen! We had developers from Austria, Brazil, Croatia, Denmark, France, Germany, Greece, Holland (the Netherlands), Italy, Norway, Peru, Poland, Scotland (yeah, I know…), Spain, Switzerland, Ukraine and the USA.MmEduSprint
    Impressive, isn’t it? So sad I had to leave this afternoon already, but here are a few highlights of the weekend: we had a very talented chef who spent his holiday to prepare our yummy meals, very productive sessions in the various rooms of the huge building during the day, dsc_0945_smallgorgeous weather, the worlds most beautiful mountain right around the corner ( I am biased :) )dsc_0823_resized and of course the mandatory Raclette evening, prepared by Mr. Fux: dsc_0820-small And here is the man who made all this possible: Mario, the most efficient Sprint organizer I know:dsc_0813_resized Kudos, Mario, well done!

    I should not forget the reason why we were in Randa: Amarok and the Mulitmedia people gathered in this lovely Swiss village to concentrate on various themes, amongst them the current state of Amarok and it’s roadmap, presenting the state of Pulseaudio, sharing a vision of the Multimedia future, possible uses of Nepomuk in Amarok, and many more like Sound events in KDE, a VLC presentation by Jean-Baptiste Kempf and the future of KMix by Christian Esken. But I better leave it to the developers to blog about the details :)

    A special Thank You! goes to the currently most famous man in Norway, Knut Yrvin. He made it possible to have an online presentation and discussion over the phone with the Qt Multimedia developers in Brisbane, who kindly stayed in their office much longer than usual to talk with us. A big hug to Knut for being such a great Community Manager, and a big sorry from me, I totally forgot to take a picture of him, so I am shamelessly using a picture made by Thorsten Rahn on the Little Matterhorn: dsc_0899_resized And no, they didn’t break it, the Matterhorn is still up in all it’s glory ;)

    Posted in Amarok | Comments Off

    Want to test the phonon-vlc backend? Here you go :)

    As some of you might have read in Mark Kretschmann’s blog, we now have a fairly good phonon-vlc backend that already works better in many ways than other available backends. It is still in alpha stage, but we would love to have testers give it a try.

    The instructions below are for a Kubuntu or Debian system, I did the installation on the latest Kubuntu 10.04 beta checkout as of Saturday, April 4th. I will give some additional commands for other distributions where those are needed.

    DISCLAIMER: Please do not install this backend if you are not comfortable with alpha code and willing to test and report bugs. We currently do not give support for it. We also strongly suggest you test this with Amarok from git, since there were quite some changes applied to the Amarok code, too. See also the KDE git tutorial for those not familiar with it.

    UPDATES: I changed the VLC installation instructions to make sure you install the 1.1 version instead of the git master branch which is the development version.

    UPDATE 2: July 4th 2010: The VLC information is updated to reflect that all distros now ship VLC 1.1 (if they don’t, talk to them, they really should, it is much better and fixes a lot of bugs.

    UPDATE 3: September 20th 2010: Development is quite fast paced for both VLC and the VLC backend, so there have been some updates: VLC 1.1.4 is now a requirement and there is an addition to the Cmake command for the VLC backend, to make sure it uses a stable phonon version: erase CMakeCache.txt in the build folder and run Cmake again, with the modifications below.

    UPDATE 4: November 30th 2010: Updated the git checkout for VLC.

    UPDATE 5: December 21st 2010: Phonon has moved the source repository to git now. Updated the git checkout for phonon-vlc.

    UPDATE 6: January 7th 2010: You now need a newer Phonon build, updated the blog accordingly.

    UPDATE 7: February 5th 2011: Please only use anongit to pull, see sections 2 and 3.

    I assume you have the environment variables set as suggested in part 3 of the above mentioned HowTo for Amarok from git. We still need to add some more lines to make sure we get a proper debug output for the phonon-vlc backend:

    Add the following lines to your $HOME/.bashrc:

    export PHONON_VLC_DEBUG=3
    export PHONON_DEBUG=1


    1. Install the VLC 1.1 stable branch

    Most distributions currently ship VLC 1.1.4, but for those who happen to run an earlier one it is still necessary to compile yourself, see the instructions below:

    You can find the source code here: http://git.videolan.org/vlc. I use a system-wide installation, but the careful amongst you can do a local installation. The steps are the following:

    use a local vlc directory, I use $HOME/kde/src/
    git clone git://git.videolan.org/vlc/vlc-1.1.git
    cd vlc

    This will get you the latest stable branch, including all the latest fixes.

    Now I am somewhat lazy, so I used the very handy build-dep command to find all the necessary dependencies for VLC. You can do this by activating the source repositories in your /etc/apt/sources.list, then type the following command:

    sudo apt-get build-dep vlc

    For OpenSuSE users, this would be:

    sudo zypper si -d vlc

    This will bring in almost all necessary dependencies, but the following did not show up, so I had to install those afterwards:

  • libxcb-shm0-dev
  • libxcb-xv0-dev
  • libx11-xcb-dev
  • To build VLC, you will also need the following packages:

  • autoconf
  • lua5.1
  • liblua5.1-0-dev
  • OK, lets build it then:

    ./bootstrap
    ./configure --prefix=/usr

    don’t forget to change this prefix for a local installation, and of course do not run make install with sudo rights below.

    make -j3 && sudo make install

    There you are, you have a brand new VLC! For those using a local installation, don’t forget to remove the distro packages to avoid any conflicts.

    2. Build a newer Phonon

    Some dependencies changed in the new backend version and we want to have a newer Phonon build than 4.4.3 which is currently shipped by most distributions in KDE 4.6, Let’s start with that before we can build the backend.

    Phonon is now located on git.kde.org.

    git clone git://anongit.kde.org/phonon
    cd phonon
    mkdir build
    cd build

    I did a system-wide installation to override the default Phonon delivered with KDE. Here comes the cmake command:

    cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull $HOME/kde/src/phonon

    All in one line, of course. The command

    sudo make install

    will build it and you have a new Phonon on your system :)

    3. Build the phonon-vlc backend

    The current code is located on git.kde.org. Keep in mind that this is still very much work in progress, so there will be changes to the code almost daily.

    Again, use a new repository for this code, I suggest $HOME/kde/src/ as usual:

    git clone git://anongit.kde.org/phonon-vlc
    cd phonon-vlc
    mkdir build
    cd build

    Everything is read to build now:

    cmake -DCMAKE_INSTALL_PREFIX=$HOME/kde/ \
    -DCMAKE_INCLUDE_PATH=$HOME/kde/include/ \
    -DCMAKE_LIBRARY_PATH=$HOME/kde/lib/ \
    -DCMAKE_BUILD_TYPE=debugfull \
    -DPHONON_VLC_NO_EXPERIMENTAL=true $HOME/kde/src/phonon-vlc/

    all in one line, of course, don’t forget to change the -DCMAKE_INSTALL_PREFIX for a non local installation.

    make -j3 && make install
    the same warning applies for a non local build, do use sudo make install

    We are almost there, now let’s activate this backend:

    kbuildsycoca4 --noincremental

    And now you can change your backend in the System Settings -> Multimedia -> Backend tab. Start Amarok and enjoy :)

    Please help us improve this backend and report any bugs you might find here: http://bugs.kde.org/enter_bug.cgi?product=phonon, component “VLC backend”. Keep in mind that this is still work in progress, so make sure your bug report is really against the latest version. For those willing to give a hand and/or submit patches, please meet us in #phonon on irc.freenode.net or make a merge request for your patch.

    Posted in Amarok, Free Software, FSFE, Git, KDE, Kubuntu, Ubuntu | Tagged , , , , , , | 44 Comments

    Show your Love on Valentine’s Day :)

    I usually boycott this marketing day of the flower business, since it is exactly that, a very well orchestrated campaign of the flower producers to guarantee their income in the bad season between Christmas and Mother’s Day, but this year the FSFE has launched a lovely campaign which I fully subscribe to.

    I love Free Software!

    Show your love of Free Software by different means:

    • donate to your favorite Free Software project
    • hug/kiss your favorite Free Software developer (don’t forget to ask permission first :-) )
    • buy your favorite Free Software developer a drink/food/flowers (and make the inventors of the Valentine’s Day happy)
    • express your happiness about Free Software by sending congratulations to your favorite Free Software project team

    Posted in Free Software, FSFE | 2 Comments

    In an ideal world…

    … every Free Software project should not only have developers, but also

    • graphical artists
    • usability experts
    • user support specialists
    • documentation writers/translators
    • software translators
    • bug triagers
    • marketing ninjas
    • community managers
    • release managers
    • website and wiki maintainers
    • unlimited funds…

    Amarok is very lucky to have most of those. No, not the unlimited funds, sadly, thats one of the reasons why we ask our dear users and Amarok lovers to support us with donations, it allows us for example to maintain our server,  which in turn can host other Free Software projects of the KDE family like Konversation.

    Linda and Valorie have started to write the handbook for Amarok 2.2.2, and Valorie is currently looking for skilled wiki writers and maintainers,  too.

    I am more active in doing user support and act as a bug triager for Amarok, and occasionally also other KDE projects like Phonon. This all started on a rainy Sunday afternoon when I tried to get rid of some of the numerous duplicate bug reports and wishes and I got hooked on it. Some 12 months later I have closed 1885+ bugs and triaged thousands of others:  Amarok went from 2.0 to 2.2.2 and got 2864 new bug reports and wishes in this time, of which 3071 could be closed. An average 5-10% only were unique bugs, all the rest were either duplicates, invalid, already solved or reported against the now unmaintained Amarok 1.4.x. Some were also reported against Amarok by error and had to be reassigned to another project.

    Bug reports and wishes are something that definitely needs triaging, since many reports have flaws. This can be

    • an incomplete or a too complicated description, sometimes not even in English
    • missing elements: version number, distribution, what were they doing when the bug occured
    • in case of crashes: incomplete backtraces
    • more than one item per report, which makes it too difficult to follow
    • duplicates
    • already implemented features or corrected code
    • Invalid reports

    All of these flaws are quite common, it is rather rare to get bug reports that can be used “as is” by the developers. And that is my point: bug triaging is not a developer task. Developers develop code, they should not have to loose their time running after users for more information about a bug or a wish. Unfortunately most of the projects don’t have their own triagers and rely on the KDE bugsquad to do this task, which is not that easy and something that needs to be addressed:

    While much of the triaging can be done by people not involved in a particular project, it gets difficult when the triager doesn’t know the application. IMHO s/he should at least be a regular user of the application and ideally also run the developer version from GIT or SVN. This is not as complicated as it sounds, most of the projects have step-by-step instructions on how to build from trunk. If it is one single application the triager is interested in, s/he can build it locally in the home directory, which can be easily removed if needed. But it is of course important that the triager is in direct contact with the developers, be this only to be able to get feedback from them if necessary.

    I encourage all larger projects to recruit dedicated triagers. This has more than one advantage:

    • it takes away an important workload and the developers can concentrate on their primary task
    • dedicated triagers know the application and can judge much better what is needed to make a report useful than somebody who occasionally triages here and there
    • it adds strength to the team, and dont’ forget, sometimes triagers become developers :) (not me, there are already too many bad coders in this world … )
    • id adds efficiency to your development cycle, and you find your way around in the bugs list since all incomplete bugs are gone

    Now how do we recruit triagers? This can be done by encouraging advanced users to give a hand from time to time, I can assure you, bug triaging can get addictive :)
    But there is a much easier way: through the BugWeeks dedicated to bug triaging in the KDE Forum. The first BugWeek has just ended, set up and lead by Darío Andrés, our “Bugs Hero” who had the initial idea and set up all the course. We plan to hold two BugWeeks per month and encourage everybody to participate and make the number of untriaged bugs much, much smaller! Also, a BugWeek on the forum has the advantage of being easier to run than a BugDay, where people need to be online at the same time and share a wiki.

    On another hand I would like to write about a particular form of invalid bug reports: those from poisonous people. Every project has sometimes to face people submitting bug reports and wishes in non-objective ways . The bug may exist, but the way these particular reporters report it and comment on it is poisonous, subjective to the extreme and sometimes quite insulting. A non-objective report is not something one can act upon in another way but by marking it as Invalid  if the reporter doesn’t change their tone. To avoid loosing the important information, IMHO the triager should make a new report with the important information, but close the original one.

    I have done this twice already and it worked out quite well, so I think this is really worth a try.

    My reason for doing this is clear: useless reports by these people, insulting and personal attacks are discouraging and demotivating for the developers. It can in the worst case lead to developers leaving a project because of this. The triagers have a unique possibility to avoid these insults to reach the developers in filtering those. Of course this can be dangerous for the triagers, too, as themselves can get wary of such posts.

    We here should all think and take action to not let this happen and make use of the wonderfully motivating and supportive network we have which is KDE: talk about around you and let the magic work. Don’t keep it in your mind alone or in your developer channel or mailing list or bug report, talk to your team, to your friends, to the bugsquad and of course the Community Working Group. And don’t forget the two last paragraphs of the KDE Code of Conduct: Support Others in the Community and Get Support from Others in the Community.

    Posted in Amarok, Free Software, KDE | Tagged , , , , , , | 7 Comments