Talk:Task:Getting Nokia involved in bugs.maemo.org
(Best practices for everybody) |
(→Success (and really wrong) stories: new section) |
||
| Line 8: | Line 8: | ||
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.--[[User:qgil|qgil]] 11:54, 24 July 2008 (UTC) | 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.--[[User:qgil|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.--[[User:qgil|qgil]] 12:08, 24 July 2008 (UTC) | ||
Revision as of 12:08, 24 July 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 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)