Nokia
Thanks to Nokia I had the opportunity to spend a few days at Helsinki last week, having talks, discussions and meetings with several people, especially in Maemo error management.
As I interact with Nokia’s error management by discussing/forwarding bug reports, and as there have been some confusion and misunderstandings already (Karsten‘s and my work do not fit perfectly into Nokia’s current well-defined and not easily to change workflows), I gave a small presentation about what we are doing, the problems and expectations.
I see ourselves (the maemo.org bugmasters) as a kind of bridge between the Maemo community and Nokia’s product management. Being involved in Maemo and GNOME, we’re used to open source and understand its culture, but I can also understand managers being conservative when it comes to changes and when advantages aren’t obvious at first sight.
So at the beginning of my presentation I asked the audience (Nokians involved in error management) how many of them have ever dealt with open source community, culture and practices. It was less than 15%, something I had expected. My theory is that in general, professional error management in open source projects often simply does/did not exist, hence there can’t be that many people existing already used to it – definitely not Nokia’s “fault” or whatever. I explained that 3rd party developers, power users and fans can help any company leading an open source project in producing better software by helping in testing and providing patches and feedback, but they also have expectations and want to get something back for their efforts, e.g. becoming more involved and having more transparent processes. Or to quote a fine sentence by Jaffa that I also said while having my talk: “If Nokia aren’t seen to be committed to the community, why should the community be committed to Nokia?”
In my impression Nokia has already improved in understanding, but there’s still a long way to go. There have been “bad” examples, e.g. I was told that Nokia probably publishing updates more often now is already a sign of becoming more open (Sorry, this is an internal decision and has nothing to do with community involvement). But there also have been good examples. See, Nokia is a big company with lots of different opinions and people with different backgrounds and hence different definitions of “Openness”, and talking to each other helps to understand “the other point of view” better. Some Nokians involved in error management will be present at Maemo Summit. Looking forward to continuing discussions with community folks (and input) around.
A valid argument that I can second is that developers want to have one central place to track their bug reports. This is currently Nokia’s internal Bug tracking system. Some Nokia developers also comment in Maemo Bugzilla (mostly those coming from open source too, and in my impression this number has increased a bit in the last months), but quite often you don’t have the time to track two systems. Hence I waste spend a lot of time already on keeping reports in sync (been working lately on porting a script I use in GNOME Bugzilla to quickly insert comments on bug reports to save some time).
But I also do second that in the long run we should have those components that are completely open source in Maemo Bugzilla only. Now you might ask: Why not starting this immediately? So when examining on how hard it will be to open some parts of the existing internal infrastructure, I was often told that there are legal issues to resolve first. It’s not only about Nokia’s internal Bug tracking system, there’s much more that’s part of the long tail – information that a commercial company does not want to be accessed by its competitors, such as for example policy plans, product and hardware information, information about the internal testing infrastructure and especially copyright related issues. So it’s time to identify and check those blockers one by one. But there definitely IS slow change (maybe too slow for some Maemo folks that have been expecting more changes for the last two years), probably Nokia just needs more lawyers to handle all this more quickly. ;-)
maemo.org Bugzilla stuff
Apart from the ongoing triaging of new incoming bugs, syncing between the internal Bug tracker and Maemo Bugzilla and reorganizing some components in Maemo Bugzilla to fit better with Nokia’s internal development teams, we are going to remove the deprecated bug resolution RESOLVED LATER in the next two weeks. “LATER” either means WONTFIX, or the bug should just remain in open state. This requires “fixing” the existing bugs first. After that, LATER can be removed from the Bugzilla code. We have already removed the meaningless Target Milestone “Next” and retriaged all bugs RESOLVED REMIND that also needs to be removed from the code.
I have also disabled setting the Target milestone when filing a new bug, because Target Milestones are definitely not wishlists. Setting “Fremantle” or “Harmattan” as a target milestone for a bug should really mean that a developer works on it and plans to get the issue fixed by that release. We currently also discuss on switching to the “guided” bug entry template to make it easier to file valuable bug reports, but currently that template is way too crowded and noisy to be useful, so this will take some time and changes.
Openismus really needs a designer to choose better color combinations and provides better slide’s templates :-)
Useful post. Thanks.
Good.
Continue.
Thanks!
What did you use to prepare the slides? :)
@gpoo: I think we don’t have templates. You don’t like my colors?! Wait until we meet again!
@MishaS: Openoffice.org 2.4 – all “design choices” are bugs in fact.
Thanks, andre! That’s a nice set of slides you’ve got there. ;)
I can’t overstate how much I, and others I’m sure, appreciate the hard work you and others put in “fighting the good fight” on the inside of Nokia. We need all the help we can get. :)
Argh, Nokia are such bureaucrats! As usually. Are they value their dumb copyright crap more than customers after some years?
Funny enough (I will not be at OSiM World/Maemo Summit, so you can’t beat me up for saying this :D …) I understand most of Nokia’s internal struggle and their reasons for not being as open as they should from our point of view.
But: If this is so (and it probably was even more so back when Maemo started), if they know they have to work with an internal bugtracker, can’t make it public and don’t have the time or means to keep a public and an internal tracker in sync… Why the hell did the introduce the public bugzilla at all? In other words: What were *Nokias* expectations at that time? What did they think would come out of such a system? How did they plan to use it?
We’re always talking about our (the users’) expectations and how Nokia fails to meet them. In this case, I’d be very interested in what Nokia expected of the public bugzilla and what (if anything) went wrong so that they more and more neglected it.
Andre, thanks for the update.
Agree with much of the above; but can’t help but comment that ossi1967 asks some *very* interesting questions
@OneOfTheseNastyUsers: You aren’t in the position that you could easily lose dozens of millions by getting sued of violating patents, so talk is quite cheap.
@ossi1967, Jaffa: I simply don’t know. My impression is that a few people who were convinced of getting more community feedback set this up (not backed by “management” or whatever) but probably had no plan how to manage all this afterwards. I don’t think creating Maemo Bugzilla was an official Nokia decision, but I can only guess.
Thanks for your post, Andre. It’s very informative to see how the ‘two worlds’ of bug tracking more or less co-exists.
Apart from that there exists a lot of more ‘worlds’ – nearly every garage project has it’s own bug tracker via garage.maemo.org – most of them are not or minor used. And most of these projects don’t have (and don’t need) a bugmaster for synchronisation with bugs.maemo.org or internal nokia bug tracker. That’s a big barrier for people, who wants to report their first bug without the knowledge about maemo.org. For example there is a modest bug tracker and bugs.maemo.org and the internal nokia one.
But I see there are discussions and ideas:
https://wiki.maemo.org/Task:3rd_party_bug_tracking_in_bugs.maemo.org
@jukey: You refer to Modest’s bug tracker in Garage? That one should be closed but it’s not my power to do so. Please ping the Modest maintainers if that’s what you refered to.
> what (if anything) went wrong so that they more and more neglected it.
I bet users were demanding stuff that caused their marketing ba$tard$ to feel quite uncomfortable. And few (if any) companies of closed nature are having fun fixing bugs.Fixing bugs costs something but produces no immediate income.So, sales staff (should I say “stuff”?) dislikes when it is too many bug fixing and too few new-coool-super-duper features.Probably “quota” has been exceeded. Not everyone ready to release quality products these days.Look, iPhone full of bugs, too.
After distributed version control, the world needs distributed bug tracking.
Working with two separate bug databases for a single component is just not gonna work. One of them will always be neglected.