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.

Comment 2 Neil MacLeod (reporter) 2006-06-27 18:26:38 UTC

(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.

Comment 3 Luc Pionchon 2006-06-28 16:01:47 UTC

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

Comment 4 Neil MacLeod (reporter) 2006-06-28 16:57:40 UTC

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

Comment 5 Neil MacLeod (reporter) 2006-08-13 15:26:08 UTC

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?

Comment 6 Luc Pionchon 2006-09-15 15:21:40 UTC

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.

Comment 8 Ferenc Szekely 2006-09-16 02:04:30 UTC

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).

Comment 9 Neil MacLeod (reporter) 2006-09-16 15:39:59 UTC

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.

Comment 11 Quim Gil 2007-08-13 06:42:43 UTC

Reassigning to me since I'm pushing this very same goal internally.

Comment 12 Quim Gil 2007-10-01 22:17:35 UTC

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.

Comment 13 Quim Gil 2007-11-23 11:10:47 UTC

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.

Comment 14 Quim Gil 2007-12-03 08:21:14 UTC

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?

Comment 15 Andrew Flegg 2007-12-20 11:16:16 UTC

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.

Comment 16 Neil MacLeod (reporter) 2008-01-14 22:16:13 UTC

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...

Comment 18 Neil MacLeod (reporter) 2008-02-15 03:06:00 UTC

(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.

Comment 19 Andre Klapper 2008-05-16 13:10:54 UTC

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.

Comment 20 Quim Gil 2008-06-11 08:27:49 UTC

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?

Comment 21 Quim Gil 2008-06-19 10:39:48 UTC

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.

Comment 22 Andre Klapper 2008-06-20 15:46:23 UTC

(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.

Comment 23 Quim Gil 2008-07-15 21:18:15 UTC

(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

Comment 24 Ryan Abel 2008-07-15 21:32:44 UTC

(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

Comment 25 Andre Klapper 2008-07-18 13:29:58 UTC

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?

Comment 27 Quim Gil 2008-07-21 08:17:54 UTC

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?

Comment 28 Ryan Abel 2008-07-21 09:19:12 UTC

(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

Comment 29 Quim Gil 2008-07-24 15:14:40 UTC

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!

Comment 31 Ryan Abel 2008-07-27 22:50:32 UTC

(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".

Comment 32 Quim Gil 2008-07-28 10:52:13 UTC

(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

Comment 33 Andre Klapper 2008-09-02 15:39:41 UTC

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.

Comment 34 Quim Gil 2008-10-22 10:06:05 UTC

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...

Comment 35 Quim Gil 2008-11-04 12:46:15 UTC

(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.

Comment 36 Quim Gil 2008-11-04 13:45:19 UTC

(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?

Comment 37 Andre Klapper 2008-11-04 14:00:10 UTC

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 :)

Comment 38 Ryan Abel 2008-11-04 16:11:09 UTC

(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?

Comment 39 Andre Klapper 2008-11-04 17:39:45 UTC

(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. ;-)

Comment 40 Quim Gil 2008-11-05 12:56:10 UTC

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.

Comment 41 Quim Gil 2008-11-19 09:58:30 UTC

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

Comment 42 Andre Klapper 2008-12-29 18:45:27 UTC

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.

Comment 43 Quim Gil 2008-12-30 17:22:39 UTC

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?

Comment 45 Neil MacLeod (reporter) 2009-12-20 00:46:04 UTC

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.

Comment 46 Andre Klapper 2009-12-21 19:46:41 UTC

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

Comment 47 Neil MacLeod (reporter) 2009-12-21 20:07:04 UTC

(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.

Comment 48 Quim Gil 2009-12-23 18:02:30 UTC

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.

Comment 50 Quim Gil 2010-02-17 22:49:36 UTC

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.

Comment 51 Neil MacLeod (reporter) 2010-11-11 04:22:03 UTC

Deja vu... http://bugs.meego.com/show_bug.cgi?id=4900

The story (saga?) continues over at b.m.c. :)