• Intro
• Downloads
• Community
• Development
• News
• TALK

Talk:Task:Getting Nokia involved in bugs.maemo.org

Revision as of 14:02, 4 November 2008

Best practices for everybody

There is one assumption that not always becomes true: Bugzilla users know how to deal with bug tracking. This might apply both to users (poor reports, wrong severity/priority, reopening of wontfixes/invalids just because, bad behavior...) and maintainers (harsh resolving, lack of explanations, little knowledge of the possibilities of the tool, bad behavior too...). We see this in most free software projects and bugs.maemo.org is not exempt of this risk.

In fact, having @nokia guys around makes things a bit more difficult sometimes: certain users take the chance to establish a personal war against "Nokia", others might simply ignore the complexity behind a simple bug and a simple Nokia developer commenting on that bug. On the other hand, Nokia employees are busy enough with an internal bug tracker that counts in their internal process, and communicating to the outside makes things more complex: because of wearing the Nokia shirt you can be quoted anywhere and because some (actually many) bug resolutions are related to confidential information.

Also, Maemo gets many newcomers not familiar with free software development practices, both in the user and developer side, which makes the own concept of a public bug tracker strange for some.

For all these reasons it would be good to have a concise 'for dummies' guide for users and maintainers that everybody could refer to when learning how to get involved.--qgil 11:54, 24 July 2008 (UTC)

Success (and really wrong) stories

Putting the pressure on single developers doesn't help actually. The reality of the average Maemo SW developer is: busy with Nokia internal processes (including automated and human testing) and reporting to a project manager (directly) and a release manager (indirectly) that most probably don't follow the activity in bugs.maemo.org. Considering this setting, the public Bugzilla brings more work in exchange of an unclear outcome. This is why good triaging by the maemo.org bugmasters and the Bugsquad is good, because they help triage what really matters.

However, the real step is to prove that good usage of bugs.maemo.org results in less work and better quality, not more work resulting in worse performance/quality. I'm not saying that this is *the* position of Nokia. What I'm saying is that Nokia processes have been evolving during years and just recently they had to consider something like a public Bugzilla. Coming from an open source background the importance of public bug trackers is clear, and doesn't need further explanation. But on the other hand, device programs and non-free software development programs can also show good success rates with test and error management process done internally, getting user feedback from surveys, controlled tests, etc.. The Maemo SW is in between, affected by device & closed source software development and also by pure open source development.

There are many things that are being changed internally to adapt to this situation, but there is one task where the Maemo community can help: bring the success stories happening in Maemo and elsewhere with a similar setting (e.g. public bugtrackers efficiently handled by companies shipping software preinstalled in devices). Equally useful would be clear stories of things that went wrong or could have gone clearly better if Nokia would have made a better use of bugs.maemo.org.

Being specific and objective, showing statistics and trends, helps a lot convincing not one or two developers but whole teams and management structures.--qgil 12:08, 24 July 2008 (UTC)

Improvements in the weekly reports

The weekly Bug Jar is just fantastic. It is also a very visual proof about the community capacity to get organized and help. Even if unrelated, it came more or less at the same time than the maemo.org bugmasters joined the team. Both things have cause a very good impact in the internal bug management people and process. Some ideas for improvement in the weekly reports:

• Website bugs out of the Jars. The Website bugs are reasonably well tracked and managed mostly at a community/public level. There are many and they add too much data to the Jars. Data like that is almost pure noise for the average Nokia guy working in Maemo Software.
• Visualizing the progress: now we get a picture every week, but we rely on our own memory to judge whether there is progress or not, small progress or big. Ideally there would be statistics and graphs showing the progress. A very good discovery and proofpoint would be to find out that before bugmasters and jars the lines were pointing trend A, and after that the lines point to much cooler trend B. This might sound stupid but those lines might convince more people inside and outside Nokia, more users and developers and managers, than the most rationalized arguments.
• Bug Jars in this wiki? Forget about this if it's too much extra work, but documenting the reports in the wiki would be useful. It could even be the default interface and then send updates to maemo.org lists and ITt.

--qgil 07:57, 25 July 2008 (UTC)

Karsten is also working on porting some weekly summary/overview to Maemo Bugzilla, see [1]. This is on the map for 100Days/Sprint4. Stephen is CC'ed and I naively hope that some code (or at least ideas) can be shared. --andre 18:08, 12 August 2008 (UTC)

Better organization of products and components

If you look inside components like System Software, System Management or Multimedia you will see that there is a bit of inconsistency aka mess in the components. This is not only poor usability for the bug reporters. It also makes life harder for Nokia developers to track where are the reports that affect to their work. Specially if you consider that developers work on teams, and many times teams are mapped to certain products and components. It is easier for Team A to know that they have to follow Product A and forget safely about the rest. This is now clear for e.g. Connectivity or Development Platform, which happen to be products that are reasonably well maintained. System Software would be the opposite case.--qgil 10:09, 30 July 2008 (UTC)

I'm going to work on improving this in 100Days/Sprint4, see [2]. --andre 18:14, 12 August 2008 (UTC)

The organization is mostly my fault*, I didn't particularly like the organization used in the internal bug tracker and was trying to aim for something which more closely mapped to what users would see when they used their device. In the n800, that's basically: 1. Browser, 2. Communications, and 3. Desktop. After those come distinct blobs: A. Connectivity, B. Multimedia and C. Games. Then comes a section which is harder to divide. I chose to map things that appeared in/near control panel as "System management" and everything else into "System software". Note that mozilla.org is currently experiencing a similar growing pain, the current bugzilla.mozilla.org organization is built around functionality that only the engineers who work on an area understand. This means that if you're an end user, or even an engineer from a different area you have a terrible time trying to find the right place to file a bug. * Except for Internet Tablet Video Converter which someone added on behalf of a different Nokia group. --timeless 18:51, 3 September 2008 (UTC)

Hi, I have been thinking and my conclusion is that we need a structure mapping platform areas and components down to the packages level. This would serve a much better purpose for generating reports and finding out the bugs in a way the Maemo teams at Nokia can process and handle better.--qgil 06:50, 22 October 2008 (UTC)

Package level? That'd be (for example) having components for dsme, bme and mce? Or breaking down "Browser" into microb-eal, microb-engine, tablet-browser-ui, tablet-browser-dialogs, tablet-browser-widgets, tablet-browser-controls, etc, etc? That sounds (to me, and assuming I'm actually reading "packages level" correctly) like hell for triagers and a good way to scare off reporters. —GeneralAntilles 07:01, 22 October 2008 (UTC)

Ok, ok, don't take the package level literally always. I agree they make less sense at the application level, where most end users will probably land. My main concern is not the package level but the fact that bugzilla products reflect better platform structure and (as a happy coincidence) Maemo SW team structure. For instance, now "Applications" list in fact "Rest of applications", since Browser or Media Player are elsewhere. At the same time, "Multimedia" is handling both application and platorm components. The Maemo SW team has a clear divide between applications and platform. Users probably will be happier too if they would have an easy way to access the whole application level without having to mess with more obscure platform components. By doing this we can go to deeper levels in the platform since now there is a single component for e.g. "Multimedia Framework" when actually it would be good to know whether a bug is in GStreamer, PulseAudio or some Nokia closed component (for instance, upstream developers could track better what is going on there). No need to go down to the full list of GStreamer related packages, agreed. Let me start drafting a structure... Don't look at the components so much, I have concentrated on the products in this first round. --qgil 06:08, 23 October 2008 (UTC)

Draft structure

The 3 levels respond to Classification, Product and Component. What is today "Maemo Software" would be split in Official Applications and Official Platform.

• Official Applications (respond to a structure evident from a user point of view)
  • Browser
    • Bookmarks
  • Chat & Internet Call (was: Communication/IM/Chat and SIP etc - I'd prefer to have Chat and Internet Call in the same category, otherwise I'm running into problems here e.g. with Presence bugs - it's too tied. - TODO: rtcomm? what's the status? Never understood that...)
    • Chat
    • General (was: Communication/General (9 bugs))
    • Internet Call (was: Communication/Internet Call)
    • Presence (was: Communication/Presence)
    • SIP (was: Communication/SIP)
    • XMPP (was: Communication/XMPP)
  • Contacts (was: Communication/Contacts)
  • E-mail (was: Communication/Email)
  • Games
    • Blocks
    • Chess
    • Mahjong
    • Marbles
  • Home applets
    • Battery
    • Clock
    • Connection
    • Contacts
    • Display
    • Getting started
    • Internet radio
    • Internet search
    • RSS feed reader
  • Images & Camera (fits better to also have Cam bugs somewhere)
    • Camera (was: Multimedia/Camera)
    • Image viewer
  • Map (see bug 2566)
  • Media Player (was: Multimedia/Media Player)
  • RSS feed reader (was: Applications/RSS feed reader)
  • Settings & Maintenance
    • Application manager (was: System management/Application manager)
    • Backup/Restore (was: System management/Backup/Restore)
    • Connection manager UI (was: System management/Connection manager)
    • Control panel (was: System management/Control panel)
    • Startup wizard (was: System management/Startup Wizard)
    • Software updater (NEW, see e.g. bugs 3750, 3764)
    • Teach handwriting (was: System management/Teach handwriting)
  • Utilities
    • File manager (was: System management/File manager)
    • Calculator
    • Clock
    • Help
    • Notes
    • PDF reader
    • Sketch
    • Search
    • X Terminal (was: System software/X Terminal)
  • X-Discontinued
    • Audio player (770) (was: Multimedia/Audio player)
    • FM Radio (N800) (was: Multimedia/FM Radio)
    • "Misdirected" product bugs
    • osso-email (was: Communication/osso-email)
    • python (was: System software/python)
    • Video player (770) (was: Multimedia/Video player)

• Official Platform (respond to an architectural structure)
  • Desktop platform
    • Device lock (was: Desktop/Device lock) ???, TODO: KILL? current bugs are partially in fact hildon widget bugs)
    • File System UI (was: System software/File System UI)
    • Finger keyboard (was: System software/Finger keyboard)
    • Fonts (was: System software/Fonts)
    • gconf (was: System software/gconf)
    • glib (was: System software/glib)
    • gnome-vfs (was: System software/gnome-vfs)
    • gtk (was: System software/gtk)
    • hildon-libs (was: System software/hildon-libs)
    • hildon-theme (was: System software/hildon-theme)
    • hildon-thumbnail (was: System software/hildon-thumbnail)
    • Home (was: Desktop/Home) TODO: KILL and move to hildon-*?
    • Icons (was: Desktop/Icons)
    • Input method framework (was: System software/Input method framework)
    • libosso (was: System software/libosso)
    • sapwood (was: System software/sapwood)
    • startup-shutdown (was: System software/startup-shutdown)
    • Task navigator (was: Desktop/Task navigator)
    • Themes (was: Desktop/Themes) ???
    • User interaction (was: Desktop/User interaction) TODO: Must die!
    • Virtual keyboard (was: System software/Virtual keyboard)
    • window-manager (was: System software/window-manager)
  • Connectivity
    • Bluetooth
    • DUN (??? - I miss understanding...)
    • ICD (??? - I miss understanding...)
    • Networking
    • Operator Setup Wizard (was: System management/Operator Setup Wizard)
    • WiFi
  • Core
    • Kernel (was: System software/Kernel)
    • X Server (was: System software/X Server)
  • Data
    • Meta Tracker
    • SQLite
  • Development platform
    • Documentation
    • general
    • installer
    • rootstrap
    • SDK
    • Tools
  • Flasher
  • Location (was: Connectivity/Location Framework)
  • Multimedia (TODO: split into more subcomponents - e.g. Gstreamer, Real, DSP?)
    • Media streamer
    • Multimedia framework
  • Real Time Communication
    • Telepathy
  • System software
    • application-killer
    • Busybox
    • dbus
    • dsme (was: System Software/dsme AND System Software/Watchdog, TODO: merge)
    • File system
    • general
    • glibc
    • iconv
    • libxml
    • maemo-launcher
    • mmc-and-usb
    • OHM
  • Translations
  • UI Specification
  • User guide & Help content (should get rid off vague "Docu" term)
    • Help content
    • User guide

• Nokia
  • Internet Tablet Video Converter
  • Webmail Notifier (was: Applications/Webmail Notifier, 8 bugs)

User:Andre: Getting rid of the "Applications" product is very good. It was often confused with Desktop (e.g. mixing up Applets and Apps with the same name). But having Desktop now in Platform might also be confusing if you're used to the old structure so I changed this to "Desktop Platform". What I have already done: I've moved Developer Docu from Website to Dev Platform (because it's out of community scope, see bug 3562). Removed ancient Games/Startscreen subcomponent (only 2 bugs), Removed Desktop/PC connection (1 wrong bug), Desktop/Tableteer Info (0 bugs), Desktop/Desktop Info applet (0 bugs). Removed Communication/Accounts (3 bugs, 2 wrong). Removed System software/libcommon-error (0 bugs).