Talk:Task:Getting Nokia involved in bugs.maemo.org
Contents |
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)
- 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)