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 triaging what really matters.
However, the real step is to proof 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 ther importance of public bug trackers are clear, don't need further explanations. 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 nt 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 that is almost pure noise for the average Nokia guy working on Maemo software.
- Visualizing the progress: now we get a picture every week, but we rely on our own memory to judget 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 rationalised argumentations.
- 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 prodicts 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 opposit 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)