The ALERT Project
As reported on the Dot last year, KDE is taking part in the ALERT Project, a European Union funded research project aimed at providing better bug tracking and resolution software for free software development.
Some people in KDE (mainly Dario and Ade – who attended the previous plenary meeting in Madrid in January – and myself) have been helping ALERT define the problems with existing bug tracking systems and bug resolution and this week I attended ALERT’s second plenary meeting in Bled, Slovenia.
It was quite fascinating to meet everyone and see presentations on how the various parts should come together. The final software should include extracting data from structured sources such as bug trackers and unstructured sources such as forums and mailing lists. The ultimate aim is to give developers more relevant information about bugs – for example allowing them to be notified about bugs with high activity or information relating to bug reports found in other sources.
Lake Bled, Slovenia, venue for the ALERT meeting
There are also possibilities to provide some automation of detection of duplicate bugs (a major problem in KDE’s and other bug trackers) and even to try and match developers to bugs – say you have a bit of time on your hands (I know – when does that ever happen?) perhaps the system can suggest potential bugs for you to work on based on your previous bug and commit activity. This could be particularly useful for helping to find things for relatively new contributors to get their teeth into, as long as they have some contribution history.
Of course, this is all at an early stage and the project partners implementing the software have many large challenges ahead of them. The job of KDE representatives is to communicate our needs and to provide some testing and feedback on the software as it is developed.
Many (in fact most) of the people working on the project have little experience with free software. It was strange to hear some of them talk about managers assigning tasks to members in the community and using the system to evaluate their performance. There were also questions about how KDE is funded and why people would contribute for free. The involvement of KDE and the other free software case study partners is therefore important to try and make sure that the solutions developed are relevant to us.
The software will of course be open source. However, development is still being discussed and the final licence is not yet determined – initial delivery of a working system for testing purposes is expected in about a year’s time, with another year for testing, feedback, refinement and wider deployment. Reassuringly, the partners seem to be making extensive use of existing free software rather than re-inventing the wheel, but the presence of many partner organisations working on different aspects of the software means there are a lot of independently developed parts that will all need to work well together.
Bled itself is a beautiful place – on the edge of a lake with mountains around it is a quiet place (at this time of year) and ideal for an intense two-day meeting with plenty of opportunity to relax in the evening.
Hey Stu:
Sounds like a good project. I like the idea of possible matching of developers with bugs. It can be quite daunting and difficult to do any actual development, but bug reporting and fixing (minor ones) is a good way to contribute to the open source projects.
Morning 🙂 Yep, I’ll tell you all about it soon – it’s an interesting thing to be involved with.
Hi Stuart
perhaps I’m not making sense, but while half reading this, I was wondering if bugtrackers have trackback technology used in weblogs?
There may be relationships between projects (upstream/downstream or a whole piece of software is used as a submodule in another), which would make bugs posted in one bugtracker be relevant in another. I figure that trackback and other weblog features could enhance the cooperation between the different bugtrackers that have the same bugs or the same software (automatic cross posting bugreports to another bugtrackers? would that be useful?)
Cheers
Simon
PS, sorry for offloading my random ideas here, I hope it’s relevant 😉
They don’t, really 🙁 Normally if you find an issue should be up or downstream you have to manually report it in the other project’s bug tracker and add links in the bug reports to where the other reports are located.
So that would be very useful, but maybe out of scope for the current project – although I think it could be fairly easily extended to at least allow a developer to monitor multiple bug trackers in one place.
It’s funny, we have so many suggestions for problems with the current bug trackers. The ALERT partners ask us what the problems are and then they have to try and work out which ones can be realistically dealt with in this project.
I was a bit surprised when I read that this was in Bled … who would have thought that something productive can happen in our country 🙂
It’s just a bit sad that there were no news about this (even in technical forums/news sites).
Hehe, well actually one of the main project partners IJS/JSI are based in Ljubljana and apparently they often hold meetings in Bled because it’s nice and away from the distractions of the institute.
It is a shame that there wasn’t more information. The project has quite a low profile at the moment, but hopefully that will change when the software starts to be delivered.
*cough* *cough* SQO/OSS *cough*…
Ade I know you’ll understand that one 😉
Absolutely. I hope so. Now we are talking about this issue.