Problems ahead – splitted bug tracking

By Jarkko Moilanen On August 19, 2011 · 13 Comments · In Android, community, Ecosystem, MeeGo, nokia, open source, Uncategorized

Bug tracking is a powerful tool for developers. It is one of the most important communication methods. In app development developer has to know where to file a bug. Let’s take an example. In MeeGo ecosystem there are multiple bugtrackers for different purposes: Qt / IDE, MeeGo project (several categories), multiple internal-only trackers. Also having Harmattan as developer device (N950) and as market device (N9), more trackers are involved since bugs related to Harmattan are not submitted MeeGo project bug tracker, but in a separate Nokia developer tracker (see also discussion round bug 4900 about closed bugtrackers on open source project). Even the latter caused some misplaced bug reports before developers were adviced to submit Harmattan related bug reports to correct tracker.

In the future this becomes even more complex. There exists multiple community driven apps already and more will come. What about when multiple device vendors push more MeeGo devices into markets (IVI solutions, tablets, handhelds, embedded systems, Smart-TV)? How to handle bugs in apps used in those devices? Of course commercial apps can have own ‘bug trackers’, but those are normally company internal trackers, where public has no access. Even at the moment some bug reports that should be in public MeeGo project bug tracker, are in internal/closed bug trackers for various purposes (cases where confidential information and security issues are involved). Yes, there is a need for internal trackers, but providing links from public tracker to internal tracker is not good. All the above leads to different problems such as:

bug known by some, not all that are affected,
hidden, because related to internal development and business secrects
misplaced links to company (internal access only) bugtrackers
situation leads to cases where filing a bug becomes harder; finding correct place/tracker is harder. More when multiple device vendors push more MeeGo devices into markets (IVI solutions, tablets, handhelds, embedded systems, Smart-TV)
developers and users might file bugs to wrong trackers. That causes extra work since bug report must be moved to corrent tracker. That is not ideal situation, but it is better than leaving the known bug filed at all.
where to file bugs related to apps created by community members?

Evidently developers and users might file bugs to wrong trackers. As it was stated above, that causes extra work. That is not ideal situation, but it is better than leaving a known bug filed at all. In this post I will concentrate on question: “where to file bugs related to apps created by community members?”

Android’s solution

In Android ecosystem situation is pretty much as problematic as in MeeeGo ecosystem. Yet Android has created some ‘tools’ for filing bug reports. In Android users/developers are encouraged to submit bug reports to “a public issue tracker where you can report bugs and request features for the Android software stack”[1]. What about bugs related to applications (which are not part of the stack) feature requests? Android ecosystem does not seem to have any good solution for those. Instead they say “Android Open Source Project (AOSP) issue tracker is intended only for bugs and feature requests related to the Android software stack. Because many users find their way here looking for the Google apps for Android (such as Gmail and so on), we have components set up for their convenience. However, these apps are not part of Android, and any issues reported on these components are not guaranteed to to receive attention. Most notably, to report issues related to Android Market, you should visit the Android Market Support Forum.”[2] At the Android Market Support Forum you get the below view, which does not convince me, but it’s a start.

Android Help Forum

That solution seems to have a few problems. First of all, I can’t find any discussions related to some app developed by the community. I didn’t bother to look too deep since the opening view for example “‘Appy’ Talk: All about Apps”[3] is just a big list of topics with more or less describing topics. Where can I simply say that I want to discuss about some specific app created by a member of this community? Let me know if you find a way to do that without using so called ‘advanced search’. The same applies to other categories too. Just take a look at “Technical Help”[4].

But let’s return to apps related bugs. I approached the Android community in IRC (#android) and asked: “Hi, I’m new to Android stuff and I have a simple question. Where should I file bug reports related to some app created by community member?”. First answer/advice was to contact the developer directly. Second answer was that

most will have a ‘report bugs’ option in their app.

That sounds good to me, but why only in the apps? Why not also in the Market site? (this was also noticed by one IRC discussion participant “strange there is no option to ‘report a bug’ on the market site :/”). In the Market site you can add comments to apps, but using commenting in Market is not the preferred way to ‘file a bug report’ because

we [developer] have no way of responding to the comment, asking for more information, etc.

So it seems that community app developers might setup own bug tracking and might add bug reporting functionality to his/her app. It would be interesting to see some statistics how many developers add such link/’file a bug’ functionality into their app and which bugtracking solution they use. Ok, but back to bug tracking. In Android ecosystem, bugs related to community apps are filed to different trackers (apparently, I haven’t tested any since I don’t have android device), not so great. Bugs are often related to each other and linking two bugs becomes a bit hard if separate trackers are used. Yes, linking bugs with URLs can be done, but not as simply as it would be if all bugs were in the same tracker system (keyword and number based linking). There are some other problems too with having multiple trackers (please, add your viewpoints and ideas/experiences as comment).

Solution – shared bug tracker for community apps.

This raises a question: why can’t there be a shared bug tracker for all contributor apps? For MeeGo that would be in formeego.com domain (or equivalent, some domain which is maintained by the community == contributors). Apparently there will be multiple ‘app stores’ in some ecosystems and in MeeGo ecosystem most likely there will be ‘community app store’ and some vendor-run ‘app stores’. Having a shared bug tracker would make filing bugs and working with bugs easier. Furthermore it would be more ‘open and transparent’ way to do bugs management. With shared tracker, it would be easier to find if bug has already been filed or not, users could more easily find the place to file bugs, maintaining one bug tracking system would make thigs easier and -last but not least – it would look more coherent since there would be only one ‘UX’ for bugs.

It might not be such a bad idea to take some of the practices from Android and develop those a bit further. For example it might be a good idea to encourage all app developers to add ‘Bug reporting’ functionality in their app. Better yet, someone should make a library for that purpose and developers could just include that into their app. Or perhaps all that exists already. Also in the future ‘community app store’ should have possibility to file bug reports to any app and links to bugs related to that specific app (some filtering of bugs listed in shared bug tracker).

Does that make any sense to you?

EDIT 21.8.2011

Another solution is to ‘allow’ different kind of bugtrackers in apps. This might make sense, since a lot of people have accounts in different repositories, which also offer at least some kind of bugtracking services. In that case is would be great to have aggregating view to those hundreds of different bugtrackers in various systems and domains. Choosing this seconds approach does not make the ‘community-apps-bug-functions-library’ any less needed or justified. Oh and yes! If such library is created, nothing really prevents corporations to use it too