maemo.org Bugzilla – Bug 630
Increased Bugzilla transparency - get the developers involved!
Last modified: 2010-11-11 04:22:03 UTC
You need to log in before you can comment on or make changes to this bug.
Have assigned this report to Nokia 770 as this is a report about the currently flawed bug reporting process - however it's not a bugzilla defect! There seems to be only one person responding to or actioning defects - Maemo QA. Why aren't the "upstream maintainers" or "product owners" responding directly? All we ever see is that problems are passed to these "upstream maintainers" but we have no idea who these people are, or if they are actually intending to resolve the issue. Getting the developers involved would greatly speed defect resolution as more precise details could be requested from the reporter of the defect, or dialog entered into that would help to resolve whatever issue is being discussed. Using a third party such as Maemo QA communicate updates (rare) does not help the process, although it does at leas give the impression the defect is being addressed - how true this actually is I have no idea. The defect reporting process is fundamentally broken. There should be more transparency in this process - the developers should be interfacing directly with the bug reporters, that's the point of Bugzilla. I don't find the "proxy" method whereby Maemo QA responds on behalf of the developers helpful at all. Having developers respond in Bugzilla would help improve the "community spirit" - currently the Nokia developers are remote, distant and disconnected from the community when it comes to the bugs raised in Bugzilla.
Confirming. The internal Nokia BTS is apparently the default choice for developer participation. Additionally, I suggest not using the impersonal usernames like "Maemo QA", but real names or nicks with a title, like "Veijo Nokia (Maemo QA)". Reasons: 1. Impressions count and currently the impression has a dose of bureocracy in it. 2. It's not clear whether QA is always the same person or not, this leads to a communication problem.
(In reply to comment #1) > Confirming. The internal Nokia BTS is apparently the default choice for > developer participation. Unfortunately, an internal system isn't appropriate for a project based on open source principles, or with an external community of users that are willing to test and report on defects. If there are two defect tracking systems I suggest that Nokia developers involve themselves with both the internal and external systems, or use the external system exclusively. Other major open source prjects - Mozilla - succeed with the latter approach, I'm sure Nokia can too. If Nokia wish to restrict the developers to the internal system only, this gives the impression that the external system is a poor (and even unwelcome) relation. As a user willing to test and report defects on Nokia's behalf I'm not sure I can be bothered continuing if that's the attitude. One way communication is not going to build this community. > Additionally, I suggest not using the impersonal usernames like "Maemo QA", but > real names or nicks with a title, like "Veijo Nokia (Maemo QA)". > Reasons: > 1. Impressions count and currently the impression has a dose of bureocracy in it. > 2. It's not clear whether QA is always the same person or not, this leads to a > communication problem. I entirely agree, I have no idea who "Maemo QA" really is, or if s/he is even more than one person. Perhaps if "Maemo QA" included his/her name in their profile it would help personalise future communication, and enforce the impression of "ownership". Overall, the lack of communication from Nokia is extremely poor as there seems to be little interest in the defects raised here. Other than mass assignments to "upstream maintainers" there is generally no feedback on defects, not even those that are reproducible or have patches attached (eg. 2GB MMC, bug #621) I find the current process very frustrating - it needs to change, or I suspect this process will fail.
Hi Neil, Jussi, your points are very valid, and I really understand your frustration. We are aware of the situation. One thing you probably do not know is the number of persons involved, and their work load. Be sure that all the guys are working very hard here. There is clearly a lack of resources to handle the reports. Maybe this bugzilla was open too early? Or with wrong communication? Would have been better to wait too have the resources to open it? If you attended, remember what Ari said at GUADEC 2005 when announcing maemo.org: this is what we have, it is not perfect, we are opening it, we are learning. We are working on having enough resources to handle the feedback. It will still take some time, so please be patient. I am following personally the issue. Contact me anytime (I may be a bit slow to answer ;) I assign this report to myself -- luc
Hi Luc Many thanks for your response - it helps a lot! :) I genuinely don't want to be perceived as overly critical here, I really appreciate what Nokia are trying to achieve with the 770 and with Maemo - it's a fantastic device and can only get better. Opening Bugzilla to the public before the resources were available to maintain it was probably not wise, but better than nothing - not being able to report defects _at all_ would have been terrible. There's a willing group of testers around the world, many playing with Beta OS 2006, and we all want to help improve the product whatever way we can. I know it can't be easy communicating with us when you are short on resources, and I realise that "Maemo QA" is doing his/her best to provide feedback under the circumstances. Perhaps a quick fix would be the personalisation of "Maemo QA"? :) I hope you can acquire your resources quickly - I'd really like to see the Bugzilla for Maemo become as lively and free flowing as the Bugzilla for Mozilla (although maybe with fewer entries than Mozilla!) Neil
Hi Luc Any updates? Unfortunately this Bugzilla is at serious risk of becoming a waste of our time. There are few if any updates from Nokia (other than the usual mass assignments by the still annoyingly anonymous Maemo QA), and fewer and fewer new bugs being reported, confirmed or updated with relevant test cases. In short, a total lack of interest from Nokia is leading to dwindling interest from your community - we're trying to help you, how about Nokia holding up their end of the bargain? The total lack of real activity in this Bugzilla should by now be a major cause for concern; this is Nokia's direct link to serious users and developer alike within the 770 community. What message are Nokia trying to give here?
Hi Neil, there is no messages except the ones you want to read. About "qa@maemo.org" after long investigation, I finally found out the truth, which I feel I should share with you: this bugzilla is running under emacs OS, and "maemo QA" is bind to the great emacs psychoanalyst. Which explains lot of things :) Joke apart, on my side (HAF) we created hafqa@maemo.org which is a mailing list and shall never be used for comments, and all subcomponents of HAF are assigned to specific persons who shall take care of them - although you have to understand that they have limited time, and must handle different priorities. I can say also that such message like yours is not very encouraging for them either. Pointing at the obvious generally does not help much. What is your own personal issue, by the way? What do you try to achieve? What are you missing? To my point of view things are going ahead, slowly but surely. Two months ago it was a pain to gather all the latest bits. Now a large part of the very latest code is available into a coherent set through the Sardine distribution http://repository.maemo.org/sardine/. Did you give it a try? Does it help? Or is this a waste of effort? I reiterate my previous comment #3, and call for your patience.
(In reply to comment #6) > there is no messages except the ones you want to read. When did you first know that the ones I want to read? > About "qa@maemo.org" after long investigation, I finally found out the truth, > which I feel I should share with you: this bugzilla is running under emacs OS, > and "maemo QA" is bind to the great emacs psychoanalyst. Which explains lot of > things :) It seems to me that you have anxieties with emacs.
Guys, why the hell we just do not explain things instead of doing this silly fights behind the curtains? We needed 'maemo qa', because the team -who was busy implementing the 770 software- could not handle all the bugs over here. There is an other team -I am member of that; taking care of maemo SDKs, the web services, public repos etc- who decided to introduce 'maemo qa' until the real development team will free up resources and can assign someone for each software component. There are two guys behind 'maemo qa'. One of them is active and investigating every single report people file here and tries to find the best person inside Nokia, who will proceed with the bug. The other one is myself, who is really lazy, just observing stuff from a distance, but will stand behind the current process as long as it lasts. So I hope the 'personalization' of 'maemo qa' can be considered done with this. I take all the blames, my colleague takes care of the real job. I know, we know that there is an issue with handling bugs over here. We -inside Nokia- have more hands now to take care of these, so hope that the situation will change for the better. See Luc's comment on HAF stuff. Until you see an improvement in the error management process and want to blame 'maemo QA' just send mails to me (me != /dev/null, I promise).
Guys - apologies if my emails have discouraged anyone, my point is simply that communication between Nokia and the general user community is poor. I'm comparing Nokia here with other open source projects, where the developers get involved directly with the bug reports - this isn't happening in this case, hence my complaint. This bugzilla is pretty much a black hole. :( I don't know what other 770-related initiatives Nokia have going on elsewhere, but this bugzilla is the only real oppurtunity that users of the Nokia 770 device have on feeding back information, enhancement and bugs. And it's a pretty flawed process. My personal issue isn't with any specific bug, it's with this defect tracking process and the near total lack of worhwhile feedback coming from Nokia - does Nokia want our help to identify and fix bugs? The message I'm getting is "Nah, not really interested thanks". Maybe you think I'm overreacting, but look at it from our point of view - ie. those users who wants to help improve the software but end up wonder why they should bother after the first few bug reports get no worthwhile response from Nokia. I appreciate you're all trying your best to rectify the situation, and my patience will no doubt last for many more months as I love my 770, but I do wonder how much better it all could be if Nokia just communicated with their users more often - ironic really, considering Nokia is a communications company...
communities are hard. maybe this one will grow. from my perspective it helps if people file good bugs that enable developers to query for useful things and enable reports to quickly get pushed to developers who look at them. Engineers always hate playing ping pong, and the more need there is for ping pong, the more likely it is that one side or another (you have at least four: reporter, qa gateway, qa, engineer) lose the ball. probably the most important thing is to make the public bugzilla more appealing than the private one (the less reasons engineers working on open source have to use a private thing, the more likely they'll use the public thing, but the current reason would presumably be management and requirements and planning things). I think that netscape (home of Bugscape) managed the transition because they were able to have more and better bugs from contributors and had QA they could use externally to file public bugs and such. Unfortunately at the moment it seems that the QA available here really is the two people identified by reference. If volunteers (1) helped clean up bugs to make them more palatable, (2) checked bugs that were claimed to be fixed, and perhaps (3) picked up some of the QA work for whichever pieces are open, that'd be a series of steps in the right direction. Perhaps it might even draw more developers to this bugzilla. Certain kinds of people can't be allowed to disclose some information.
Reassigning to me since I'm pushing this very same goal internally.
I'm looking forward to report specific improvements on this "bug" reported pretty soon, as soon as Chinook is out of the way and we start a new release cycle.
I will be posting updates here since this is not a bug you fix in one go. - Jake Kunnari (bugs.maemo.org error manager) and I (maemo product manager) are responsible of sorting this out. Priority = High. - We just made a call to have all the components assigned directly to the developers dealing with the corresponding components internally. This will leverage the current bottleneck that Jake and his team has to deal with as middlemen. - In fact this started a but more informally some weeks ago, and components like the Media Player or the RSS feed reader have improved since then. - The objective of the current sprint is to have all the components either covered or detected as real orphans, and then look at these cases one by one.
Progress done: - We will concentrate on the platform related components and whatever has to do with development. This is the core maemo focus and here is where we get better quality reports as an average. End user applications to follow next when they are open source. Closed source Nokia applications to the queue. Closed source, non-Nokia shouldn't be handled in bugs.maemo.org. - Jake is sending a weekly report internally about bugs.maemo.org activity. Perhaps it could be also sent to maemo-developers? Would this make sense?
Quim wrote: "Jake is sending a weekly report internally about bugs.maemo.org activity. Perhaps it could be also sent to maemo-developers? Would this make sense?" Yes, I think it's exactly the kind of rigourous, open approach needed; and maemo-developers is exactly the right place for it.
A ton of new bugs have been opened since the release of OS 2008, yet barely a single post from @nokia.com during that period (I say barely to cover myself, as I'm pretty sure it's zero posts from @nokia.com). It appears this Bugzilla is being ignored by nokia.com more than ever. Please don't treat it as a read-only resource, but post updates, comments, feedback, resolution, etc. ie. enter into some dialog with the community. The lack of communication over the last month has been an utter disaster for maemo.org, it's sad to see that Bugzilla has been affected too. Someone with a big stick needs to manage this project if the developers can't be arsed to communicate with the community better.
To Neil's point above: I have been making a point today to go through my unresolved bugs (including those I did not originate, but voted on) and add comments-- if nothing else than to jar someone awake. ; ) Essentially a "hello, is anyone home? any news?" In the process I see several stagnant bugs with no updates or (even worse) assignments, which is a little scary. I have a better idea than the average user what sort of constraints might bind the maemo guys, but it seems to me that bugzilla content alone can be a powerful business case for additional resources. To that end I have faith that Quim is pulling every string he can grasp... and the question above about including more detail in the developers' email list is a great start. Hopefully the current low-volume static is temporary and we (Nokia employees and outside devotees alike) can re-energize and overcome current status quo...
(In reply to comment #17) > To Neil's point above: I have been making a point today to go through my > unresolved bugs (including those I did not originate, but voted on) and add > comments-- if nothing else than to jar someone awake. ; ) Essentially a > "hello, is anyone home? any news?" > Thanks Randall for the comment - and I thought it was just me! Recently I have begun to disengage myself from this project by spending far less time reading and helping out on ITT (I haven't visited for over a week, and don't intend to any time soon) and the mailing lists. I can't avoid the impression that this project is fatally holed below the waterline, and the continued lack of any significant involvement from Nokia/Maemo in Bugzilla only serves to reinforce this impression, along with the generally poor Maemo communication (ie. few if any blog posts or announcements of any kind whatsoever in the last 6 weeks) and the fact that most Maemo developers continue to have one hand tied behind their back thanks to Nokia corporate politics means there is no truly open discussion about anything of any worth - as soon as a technical subject gets interesting the Nokians clam up as they can't discuss certain topics. This project demonstrates to me that Nokia simply can't "do" open source properly while still trying to maintain total control over the project along with elements of closed source code and undocumented functionality. Improvements have been promised time and time again yet the situation remains the same. Maemo still couldn't even produce a changelog for Chinook despite numerous suggestions that it would be made available, and nobody seems willing to discuss it. Good luck to everyone who continues with this project but personally I think it's doomed, not through the fault of any individual but simply because of the oppressing corporate bureaucracy and the inability for anyone to change that. It could have been fun, instead it's a frustrating cluster fuck. And seeing that Ferenc has now left the project fills me with dread as he was the only guy who seemed to have a clue about the infra... :( I'll respond to any Bugzilla emails I receive for the foreseeable future but that's going to be the extent of my involvement for now - like Nokia, I just can't be arsed.
this bug report and its comments were very interesting to read, because it described the problems quite well. in general, Karsten and me now are responsible to improve this current situation, see http://maemo.org/news/announcements/view/introducing_andre_and_karsten-bugmasters.html for more information about us. please contact us when you feel like that! > There seems to be only one person responding to or actioning defects - Maemo QA. > Why aren't the "upstream maintainers" or "product owners" responding directly? > All we ever see is that problems are passed to these "upstream maintainers" but > we have no idea who these people are, or if they are actually intending to > resolve the issue. i've read a lot of maemo bug reports in the last two weeks and lots of reports have a "forwarded upstream" comment without EVER reporting back any kind of progress on these issues, and often also without any reference to the upstream ticket which makes it even harder to track. hiding under the "Maemo QA" means that nobody from the Maemo QA team must feel responsible for his/her work. using "team names" for comments will not happen anymore in maemo bugzilla. *if* anybody gets aware of this happening again, please do contact me so i can stop this. > There should be more transparency in this process - the developers should be > vinterfacing directly with the bug reporters, that's the point of Bugzilla. this did and does happen though i'd be lucky to see it happen more often. but the general concept of all the bug tracking systems i have worked with so far is to triage (prioritize, organize, ask follow-up questions) the incoming bugs first by a bugmaster or a triage team, and *after that* the developers take a look at the important ones (yes, in reality manpower is limited, but patches are of course always welcome for the open source components). the reason for this is easy: let developers code and *fix* reported bugs instead of also improving not-yet-useful bug reports. > If there are two defect tracking systems I suggest that Nokia developers involve > themselves with both the internal and external systems, or use the external > system exclusively. whenever possible issues should be handled in the open. only if any kind of non-disclosure stuff is affected issues should be handled in internal bugzilla, but still the maemo bug report should be kept in sync.
One essential difficulty is to aim for same process and expectations on software components that have a very different setting, from open source packages basically taken from upstream without changes to closed source applications produced mostly by subcontracted developers, with all the range of combinations in between. One way to start solving problems at a structural level would be to redefine the scope of this bugzilla and concentrate on the platform (mostly open source + some well followed exceptions) plus the open source applications i.e. browser. Zero confidentiality, roadmap disclosure, open development and other process elements needed to have developers transparently involved are mostly possible in this area. This would imply that process and expectations for the rest would be different. This affects basically the applications, and therefore the software most end users are concerned about. What to do with this feedback, especially if the user base increases and starts to get in the usual numbers of Nokia devices? Anyway it is probably not a good idea to throw pure end users with problems to a bugzilla... This would also help defining the definition and scope of maemo itself (see https://wiki.maemo.org/Task:Defining_maemo ). Is maemo a software platform based mostly in open source? Are then the apps preinstalled in a device, "maemo compatible applications", a different layer sitting on top?
No comments? Do you want to discuss this somewhere else? The almost approved https://wiki.maemo.org/Task:Maemo_brand is defining the Maemo platform as "The software stack from the Linux Kernel to the SDK. It's mostly open source code originated in upstream projects plus some open components developed by Nokia. Some exceptions of Nokia and third party proprietary software are included in order to provide a fully functional stack." This is the area that would make sense to cover in bugs.maemo.org offering good open source development standards. Additions to that (from Nokia apps to third party stuff) would be added to this quality level just after having a clear commitment from the bugzilla product owners.
(In reply to comment #20) > One way to start solving problems at a structural level would be to redefine > the scope of this bugzilla and concentrate on the platform (mostly open source > + some well followed exceptions) plus the open source applications i.e. > browser. Zero confidentiality, roadmap disclosure, open development and other > process elements needed to have developers transparently involved are mostly > possible in this area. This sounds good and will be an interesting challenge, especially for (some) developers to also comment and update here in Maemo Bugzilla. > This affects basically the applications, and therefore the software most end > users are concerned about. What to do with this feedback, especially if the > user base increases and starts to get in the usual numbers of Nokia devices? > Anyway it is probably not a good idea to throw pure end users with problems to > a bugzilla... Yes and no. You can solve this by intuitive and bugfree software (heh, now am I naive or not? ;-), FAQs and forums, and increasing the initial quality of incoming reports by having a nice template (in my opinion, this is already the case) asking explicitly for the information that we want to have. Most of the current Maemo bugzilla reporters and users are power users that have advanced technical knowledge. Current amount of incoming bugs is low, too. If you increase the user base you also increase the base of people willing to help (it's not 1:1 though). The (very early and not yet worked out) plan is to set up a Bugsquad of interested people, see https://wiki.maemo.org/Bugsquad for the first rough thoughts. > This would also help defining the definition and scope of maemo itself (see > https://wiki.maemo.org/Task:Defining_maemo ). Is maemo a software platform > based mostly in open source? Are then the apps preinstalled in a device, "maemo > compatible applications", a different layer sitting on top? Uff, that's a definition I'd prefer leave for the experienced community with opinions and impressions based on the last three years of Maemo. :) From my point of view Maemo Bugzilla shall be the main bugtracking place for all "Maemo platform" related products. We currently have the Garage tracker (that should die) for non-official products - if Garage developers and maintainers are fine with the current situation, then okay. It may be only my personal opinion that Bugzilla is easier and much better to handle than Garage tracker is. :) I'm fine with also being able to report bugs against closed source products in Maemo Bugzilla so users do have the chance to give feedback. We can always forward important issues. What I definitely want to see is a list describing whether Maemo products and components are Open Source or not, so interested (code) contributors now where to start hacking and can get involved. > The almost approved https://wiki.maemo.org/Task:Maemo_brand is defining the > Maemo platform as "The software stack from the Linux Kernel to the SDK. It's > mostly open source code originated in upstream projects plus some open > components developed by Nokia. Some exceptions of Nokia and third party > proprietary software are included in order to provide a fully functional > stack." > > This is the area that would make sense to cover in bugs.maemo.org offering good > open source development standards. Additions to that (from Nokia apps to third > party stuff) would be added to this quality level just after having a clear > commitment from the bugzilla product owners. Sounds good to me.
(In reply to comment #22) > From my point of view Maemo Bugzilla shall be the main bugtracking place for > all "Maemo platform" related products. Ok, we could have "Maemo Platform" and "Nokia applications" as separate categories containing everything Nokia developes and ships. Then "Community" for those applications willing to play the extras game (no chance for the rest imho). "Commercial" only if we have commercial apps whose owners explicitely commit to maintain their bugzilla product. The "get the developers involved!" effort would be concentrated in the Maemo Platform category and the open source Nokia applications. > We currently have the Garage tracker (that should die) for non-official > products - if Garage developers and maintainers are fine with the current > situation, then okay. Those in extras could be invited to join here. No enforcement, though. > What I definitely want to see is a list describing > whether Maemo products and components are Open Source or not, so interested > (code) contributors now where to start hacking and can get involved. You should have this soon according to https://wiki.maemo.org/Task:Components_and_packages and https://wiki.maemo.org/Maemo_package_source_status
(In reply to comment #23) > (In reply to comment #22) > > From my point of view Maemo Bugzilla shall be the main bugtracking place for > > all "Maemo platform" related products. > > Ok, we could have "Maemo Platform" and "Nokia applications" as separate > categories containing everything Nokia developes and ships. Then "Community" > for those applications willing to play the extras game (no chance for the rest > imho). "Commercial" only if we have commercial apps whose owners explicitely > commit to maintain their bugzilla product. > > The "get the developers involved!" effort would be concentrated in the Maemo > Platform category and the open source Nokia applications. > Definitely. There is absolutely no reason something like Tinymail/Modest should be tracking bugs internally (bug #3419 see Alias). The code is open, and the bug tracking and development should be too. Personally, I'm of the belief that the only software _allowed_ to use the internal tracker should be Nokia proprietary stuff (though there are probably exceptions like MicroB, seeing as how it's half-proprietary (why is that again. . . . )). As for community tracking on Bugzilla, this is something that timeless, Andre and myself have been pushing a bit. I've put together the beginnings of a proposal on the wiki.[1] It still needs some work though, as a lot of the details need closer consideration. Extras seems like a rather perfect barrier to entry, too (though there will have to be additional consideration for non-tablet software like mediautils). [1] https://wiki.maemo.org/Task:Garage_bug_tracking_in_Bugzilla
Quick update with regrad to getting the developers involved: We have some slight progress here, convinced a few developers to also create accounts in Maemo Bugzilla and take a look and comment in here instead of waiting to get things copied to the internal bug tracker first. (And of course some of the developers have been always doing like this, Kudos to them.) However this is all on a "volunteer" basis, I want to have some real agreements that people feel bound to, and hope to improve this in August when I have some face-to-face meetings planned.
(In reply to comment #25) > Quick update with regrad to getting the developers involved: We have some > slight progress here, convinced a few developers to also create accounts in > Maemo Bugzilla and take a look and comment in here instead of waiting to get > things copied to the internal bug tracker first. (And of course some of the > developers have been always doing like this, Kudos to them.) > However this is all on a "volunteer" basis, I want to have some real agreements > that people feel bound to, and hope to improve this in August when I have some > face-to-face meetings planned. > At least it's a step in the right direction. As for volunteer, it is my belief and the belief of most of the OSS community that development and bug tracking should be as transparent to the public as possible. Ask Richard Stallman. He'd have a few words about how this particular project is handled, but that's just me blowing smoke. Maybe we should make some sort of incentive to get the devs to start using this and change over to the actual bug tracking system instead of a closed-source style system like it is currently. As for what kinds of incentives, I don't know. Maybe a lock on all non-IP related bugs and force them to use this tracker? That would certainly work, but who would enforce something like that?
I think it would help to document a plan in a Task: wiki page defining the steps to solve this problem, being each step achievable in a single sprint. For instance, what about defining today/tomorrow what we want to solve during the Sprint3 at http://wiki.maemo.org/100Days/Sprint3 - and committing to it in tomorrows planning meeting?
(In reply to comment #27) > I think it would help to document a plan in a Task: wiki page defining the > steps to solve this problem, being each step achievable in a single sprint. > Just did exactly that. Very basic at the moment, will continue to improve. http://wiki.maemo.org/Task:Getting_Nokia_involved_in_Bugzilla
Since this bug as defined is impossible to attack in a single sprint, I propose to put it as permanent MEDIUM and push specific tasks in sprints. Sprint3 didn't get any task related to this bug. We should avoid this in following sprints. The "First steps" listed at https://wiki.maemo.org/Task:Getting_Nokia_involved_in_bugs.maemo.org don't look to me actually as first steps. They assume that Nokia developers have the time and the confidence to go and pick components when in fact is not just like that. I have proposed a couple of potential first tasks achievable in sprints at https://wiki.maemo.org/Talk:Task:Getting_Nokia_involved_in_bugs.maemo.org And this now belongs to https://wiki.maemo.org/Objective:One_place_to_track_feedback Hopefully Andre & Karsten and getting a better grasp on how the maemo SW team works internally and they can also help finding specific tasks to move developers, users and tools in a convergent direction. Triaging bugs is one visible task they do but hopefully they work on more deeper aspects too.
Quim, I think the issue with no discussion on the sprints is that Average Joe doesn't know that they even exist. In fact, the only way I know about them is that you mentioned them to me after I started making a racket. Simple suggestion: Make them more visible, I.E. post a blurb on the maemo.org front page. While it is nice that the Wiki has information on them, the Wiki is still immature from being reset and from years of neglect. It is hard to work one's way around it to find what you are even alluding to. I'm sure if more people knew about the Sprints without having to order their super-secret decoder rings, they would participate. But as it stands, only those who extremely-well versed in the maemo universe know about them. And remember, be sure to drink your Ovaltine!
(In reply to comment #30) > Quim, > > I think the issue with no discussion on the sprints is that Average Joe doesn't > know that they even exist. In fact, the only way I know about them is that you > mentioned them to me after I started making a racket. > They're announced in #maemo, maemo-community, the wiki and here and there on maemo.org proper. Anybody who will actually be interested in the content of the sprints is more than enabled to find and attend. They really aren't something that would interest the "Average Joe".
(In reply to comment #30) > I think the issue with no discussion on the sprints is that Average Joe doesn't > know that they even exist. My comment above was basically for Andre and Karsten, who know about the sprints. > Simple suggestion: Make them more visible, I.E. post a blurb on the maemo.org > front page. Yes, http://maemo.org/news/events/archive/view/maemo-org_sprint3_irc_planning_meeting/ was announced for a few days in the home prior to its celebration and https://maemo.org/news/events/maemo-org_sprint4_irc_planning_meeting/ (just created) is in the home now. > I'm sure if more people knew about the Sprints without having to order their > super-secret decoder rings, they would participate. Hopefully this will happen, yes. Back to topic: what are the tasks that you want to commit in the next sprint? They don't need any meeting to be proposed and started. I put some more ideas at https://wiki.maemo.org/Talk:Task:Getting_Nokia_involved_in_bugs.maemo.org
As most of you can imagine, this is a big long-term task I am working on, and it's not easily and quickly to fix. It's been broken up into several tasks, see https://wiki.maemo.org/Talk:Task:Getting_Nokia_involved_in_bugs.maemo.org . Hence I'm going to set the priority to Medium which does not mean that it's a lower priority for me or that this is not ongoing work.
fyi, I have just proposed at http://wiki.maemo.org/Talk:Task:Getting_Nokia_involved_in_bugs.maemo.org#Better_organization_of_products_and_components that we reorganize products and components in a way that maps the platform up to the packages level. For the sake of end user friendlyness we have sacrificed this level of detail in the platform side. The counter-effect is that it is difficult for team X to track all the bugs & feature requests related to them. According to this proposal, bugs.maemo.org would map platform areas and components in the same way that the Maemo SW team does. Most end users would file bugs only in the Applications & Desktop levels anyway. Some triaging will be needed to move sume bugs submitted under Applications / Desktop to the real responsible packages in the platform, but this is just business as usual. What about starting this task in the November sprint with the aim of having it completed by the end of the year. The Fremantle alpha release would benefit from the new structure and, beimng an alpha, we could fine tune the structure as Fremantle approaches the final release. Once Maemo 5 is released, users and developers should find a much friendly and efficient bugs.maemo.org...
(In reply to comment #29) > Since this bug as defined is impossible to attack in a single sprint, I propose > to put it as permanent MEDIUM and push specific tasks in sprints. What taks can be committed for the sprint to be defined in few hours? I have the feeling that Andre is too focused triaging individual bugs. Perhaps it is more sustainable to invest more hours addressing thse problems more structural, at the exense of not having such good short term stats. In the last sprint there was a first version of the Feature Jar + some feedback, that could be discussed and implemented in a second iteration this month. I proposed https://wiki.maemo.org/Talk:Task:Getting_Nokia_involved_in_bugs.maemo.org#Better_organization_of_products_and_components - what about agreeing on a plan during November? Also, what about attacking the "Visualizing the progress" https://wiki.maemo.org/Talk:Task:Getting_Nokia_involved_in_bugs.maemo.org#Improvements_in_the_weekly_reports All these tasks can be completed without needing to have any NDA or Nokia relationship. It is a good chance for the Bugsquad to get more discussion and perhaps contributors.
(In reply to comment #35) > I proposed > https://wiki.maemo.org/Talk:Task:Getting_Nokia_involved_in_bugs.maemo.org#Better_organization_of_products_and_components > - what about agreeing on a plan during November? Ooops, I had forgotten that "Better organization of bugs.maemo.org components" is a commited task since 2008-08-12. It says 30% done. Andre, how are you working on this though? Wouldn't it be better to agree first on a structure for products and components (something that can be done in one month) and then proceed in following sprints?
Right now I'm merging your (quite good) draft with my concept here (the app and platform split is basically what I've also written down, plus an "Discontinued" product for osso-email etc, plus e.g. moving "Webmail notifier" to the "Nokia" category, and so on). Also need to add those components that currently exist in Bugzilla but aren't perfectly covered by the concept - e.g. getting Camera out of Multimedia and putting into the Imaging category makes sense to me. Will definitely update the wiki page in a few hours - you'll see :)
(In reply to comment #35) > (In reply to comment #29) > > Since this bug as defined is impossible to attack in a single sprint, I propose > > to put it as permanent MEDIUM and push specific tasks in sprints. > > I have the feeling that Andre is too focused triaging individual bugs. Perhaps > it is more sustainable to invest more hours addressing thse problems more > structural, at the exense of not having such good short term stats. > Unfortunately Andre is practically the only response we get from "Nokia" on many issues. Getting Nokia involved in Bugzilla is dependent on Andre spending less time doing Nokia's job, and Andre spending less time doing Nokia's job is dependent on getting Nokia involved in Bugzilla? Bit of a Catch-22, eh?
(In reply to comment #35 by Quim) > I have the feeling that Andre is too focused triaging individual bugs. I must admit that I've spent a lot of time in the last two weeks to triage old bugs (reproducing, moreinfo'ing, forwarding). But I feel a lot better now - less entropy, "only" 410 open (non-moreinfo, non-enhancement, non-sdk) bugs left, 130 of them already having an internal reference. On a good way. (In reply to comment #36 by Quim) > Andre, how are you working on this though? Wouldn't it be better to agree > first on a structure for products and components (something that can be done > in one month) and then proceed in following sprints? Yes, see the wiki page. ( -> bug 3562) Though changing the components in Bugzilla will trigger lots of bugmail, so I prefer to shutdown Bugzilla mail notification for one day and get this done at once. Less annoying for everybody crawling through all the bugspam I'd trigger. But this needs good planning and review first, of course. (In reply to comment #38 by Ryan) > Unfortunately Andre is practically the only response we get from "Nokia" on > many issues. Getting Nokia involved in Bugzilla is dependent on Andre spending > less time doing Nokia's job, and Andre spending less time doing Nokia's job is > dependent on getting Nokia involved in Bugzilla? > > Bit of a Catch-22, eh? In a kind of way you're right. I have to admit that I sometimes just wait for two days to see if devs comment themselves (if they already have an account). Sometimes this happens, but if bugs are urgent I of course can't act like this. I also encourage people in emails (lots of stuff also happens in private emails to contact internal Nokians for the first time) to get a Maemo Bugzilla account and add a comment themselves. Users normally don't bite, they just rant a bit. ;-) Sometimes they get an account, sometimes not. Probably also a question of which culture you come from (Open Source vs. closed Symbian, to oversimplify it). But it does happen I assure you. The barrier will decrease if we have more similar structures, hence restructuring Bugzilla (bug 3562). If you're a dev and are really willing to watch bugs in Maemo Bugzilla and work with the community it's an obstacle to "pick up" your working/coding area from very different products and components in Maemo Bugzilla. Long term comments, again: To really have Nokia using only one Bugtracker, IMO Bugzilla field level security is required. This sounds like a contradiction to "more transparency", but I think (hope?) we all *understand and accept* that Nokia does not want to see secret info like e.g. new hardware or confidential testing infrastructure information in public. Currently it's possible to mark comments and attachments as "only visible for a certain group". We do not use that feature in Maemo Bugzilla. It's still kind of transparent because everybody will see that something is hidden: If comment 2 is "only visible for a certain group", a non-member will see Comment 1 followed by Comment 3. Novell/openSuse is using this feature in their Bugzilla. Having this also for other fields than comments & attachments is what https://bugzilla.mozilla.org/show_bug.cgi?id=372017 is about. Brave volunteer hackers welcome. Uhm, I wrote lots of text here. I hope it made some sense. ;-)
I think I have commented this already somewhere, but summarizing: - Let's have open source level of expectations on open source components - the rest is a different battle. This requires reorg. - Let's understand that developers have nowadays SEVERAL sources of feedback, also internally. They all converge in a same place where the quality of the product is measured. This is why no real progress can be done here unless there is a cloning work done in the internal bugzilla. - Let's also understand that a prerequisite for this bugzilla to get primary attention is to deal with fresh code. This is why the SDK pre-releases are so important and this is why anything out of the SDK content is a different battle.
A proposal to measure how well Maemo SW is doing handling Fremantle bugs would be to show the performance by products (and therefore by teams according to he new reorg). See http://wiki.maemo.org/Talk:Task:Getting_Nokia_involved_in_bugs.maemo.org#Status_of_projects
For everybody's interest: Bug 3562 (reorganizing components in Bugzilla so the categories fit better to Nokia's software teams) plus setting all (virtual) QA contacts correctly so that interested developers can receive bugmail on a per-component basis has been done. See http://blogs.gnome.org/aklapper/2008/12/18/watching-products-in-maemoorg-bugzilla/ for elaboration.
Also an update from my side: - "maemo.org Feature Jar" sliced out of the Bug Jar and distributed every monday to all the Maemo product managers, since enhancement requests are owned more by then then by the developers alone. - Consequent cleaning of old enhancement requests. Still a way to go but improving every week. - Next step started is to introduce check points in the internal roadmapping and planning processes to product/project managers have to review the reports relative to their projects to go ahead with the plans. - Another next step started is to change the current policy that limits the possibility of subcontractors to handle the communication and decision of the products tey are developing. A noticeable % of the "get the developers involved" affect actually non-Nokia professional developers. - There is also http://wiki.maemo.org/Task:Open_Development - a very rough start at the moment. One day the products listed there should be the ones having excellent performance in bugs.maemo.org, followed by the rest of platform components. Applications not related to open development might use this bug tracker or might go for different approaches to get user feedback e.g. http://www.nokia.com/pilots
This bug hasn't seen an update in almost a year. From my perspective as a user, it seems basically done. Bugs in Bugzilla generally seem to get responses from developers, including those labeled as "(Nokia)" and "(maemo.org)". Responses don't come from a generic user account anymore. While participation could always improve, I don't see any point in keeping this bug open perpetually; the problem seems addressed to me. I do think a separate issue exists, that as many apps as possible should move to using bugs.maemo.org rather than some internal Nokia bug tracker, to allow for more transparency; it does seem like some issues only get fixed once someone files them in the internal bug tracker. However, that seems like a separate issue from this bug. Any objection to my closing this bug?
There has been a partial improvement, but with the continued existence of two defect tracking systems and the public system playing second fiddle to the internal system there is still significant room for improvement. The internal developers can still become a lot more involved with the community than they are at present, but despite that I agree progress has been made. Should this bug be closed? Not yet IMHO, there's still more that can be done.
What has to happen to set this report to "FIXED" (or it's evil brother "WORKSFORME")? Just wondering. I can definitely second that way more Nokians are active in maemo.org Bugzilla compared to for example September, even though it's sometimes not visible. I don't think that "have only one bugtracker" is a threshold for this report. > Not yet IMHO, there's still more that can be done. Can you specify this a bit? Would also help me to see where to push harder (though I'm a bit afraid that this report might end up in a big out-of-scope wishlist for all those areas Nokia could become better). :-P
(In reply to comment #46) > > > Not yet IMHO, there's still more that can be done. > > Can you specify this a bit? Would also help me to see where to push harder > (though I'm a bit afraid that this report might end up in a big out-of-scope > wishlist for all those areas Nokia could become better). :-P > I know I'd like the moon on a stick, but more involvement would be better. Some bugs still receive no input from Nokia developers, the risk being they will be ignored for 18 months then closed as WONTFIX. Before we close this bug I'd like to see the recent increased involvement continue for more than just a couple of months, and ideally increase further. I appreciate Nokia/Maemo need to juggle limited resources, and taking time to post in the public bugzilla is time spent not fixing other bugs but I think we would all benefit from more direct involvement in this bugzilla before we consider this a done deal.
Leave it still open, please. :) Most of Comment #14 and Comment #20 still applies. Basically it is good to expect Nokia developers involved here for OSS components. In practice this means a big bunch of Platform and a smaller bunch of Applications. This is a logical step together with open development at http://maemo.gitorious.org We can close this bug when it is perceived that open source components maintained by Nokia have a decent level of developer involvement in public bug reporting. We are progressing and working to progress more, but still not there. Anything happening here around closed source components it's something like a premium. As said somewhere above, we can't set open source expectations on closed source development. It's not that these developers are not interested engaging in discussion and collaboration here. The ground reason in many cases is that a closed source components is usually developed in a closed manner for a reason. By the way, at this point Andre has little to no control over the resolution of this problem. Feel free reassigning to me again. I think you have done and you are doing a great job "connecting people" and getting in the quite decent situation we are now.
(In reply to comment #48) > Most of Comment #14 and Comment #20 still applies. Basically it is good to > expect Nokia developers involved here for OSS components. In practice this > means a big bunch of Platform and a smaller bunch of Applications. This is a > logical step together with open development at http://maemo.gitorious.org This much makes sense; certainly any open applications ought to have open development processes. That seems a lot broader than just the use of Bugzilla, though, but it certainly includes that much. > We can close this bug when it is perceived that open source components > maintained by Nokia have a decent level of developer involvement in public bug > reporting. We are progressing and working to progress more, but still not > there. Fair enough. Speaking as an unaffiliated community member and Maemo-based device owner, I can say that it seems to steadily improve. > Anything happening here around closed source components it's something like a > premium. As said somewhere above, we can't set open source expectations on > closed source development. It's not that these developers are not interested > engaging in discussion and collaboration here. The ground reason in many cases > is that a closed source components is usually developed in a closed manner for > a reason. Or, as seems relatively common, for a lack of someone making the case for "open". Sadly, it does sometimes seem like components default to closed and need explicit justification for opening them, rather than the other way around. I say that primarily because I think many small components exist that Nokia doesn't particularly care about (and for which no real reason from http://wiki.maemo.org/Why_the_closed_packages applies). Consider getbootstate, for instance, per bug #7019. However, that seems like an entirely different discussion, and one not suited for this bug report, as much as it seems to have become a discussion forum. :) > By the way, at this point Andre has little to no control over the resolution of > this problem. Feel free reassigning to me again. I think you have done and you > are doing a great job "connecting people" and getting in the quite decent > situation we are now. Alright, per your request I've reassigned back to you.
And now http://meego.com/community/bugzilla comes to the picture. MeeGo is an open platform project hosted by the Linux Foundation. Therefore the standards of reference in the MeeGo bugzilla are in the lines of http://bugzilla.kernel.org We have learned that open bug tracking goes together not only with open source but also with open development. The fact that Nokia platform developers will be able to develop openly in the MeeGo context (as opposed to the context of whatever next confidential product and release) will make their life a lot easier dealing with public bugs. Also note that different components will have different maintainers, from different companies, independent developers, etc. MeeGo will not deal with bugs related to Nokia closed apps available in MeeGo devices by Nokia. At this point I really don't know what will happen with those. We haven't discussed this yet. If you read my comments above, I'm tending to think that you it is very difficult to meet open source bug management standards for closed source projects.
Deja vu... http://bugs.meego.com/show_bug.cgi?id=4900 The story (saga?) continues over at b.m.c. :)