Created attachment 1291 [details]
Example of new organisation

That's not what we need. What we need is to automatically assign bugs to package maintainer according to maintdb.

CC: (none) => boklm

and for avoid duplicate (it's not really an big issue, as it's always better to make a bug instead of nothing), people should make a quick search before send a new one.

>This way we can have all the bugs triaged in the best way
what is not good currently ? (beside its doesn't work automatically)

Starting with this idea, maybe we could have an automatic cc list by rpm category, which is known from the rpm.
So there would be no need to add a field to bugzilla, which avoids a source of errors.
This would require setting up a structure similar to the maintainer list,
but a 1:n package group : cc-list.
It could be used instead of (or as well as) co-maintainers for packages.
Probably more useful than co-maintainers, as a particular category would involve a group of packages, as suggested in this bug report.

(Probably better to implement after setting up automatically assigning by maintainer.)

CC: (none) => andre999mga

in reply to comment #2

to do correctely what you think, it needs that every user know which package causes the issue, case that i don't think is common. other than this, if a package is abandoned or wrongly assigned to a person, that bug report goes lost. in my proposal the criteria of the Area that is used, prevents this issues and allows to a certain person to have a correct idea of:
- currentely reported bugs involving that area;
- priority of those bugs;
- fast duplicates closing;
- in general, better bugs management (because each person know everything involving his area of competence). 


in reply to comment #3

we should simplify the user work, we shouldn't assume that user automatically searchs for dulpicates, it is a problem of the project contributors that can be resolved manually or automatically (as for firefox, that before the filling of the bug, shows similar bugs). in plus, you say that it doesn't work automatically, that explains itself one of the reason of the opening of this bug report.

in reply to comment #4

i would avoid the corrispondence maintainer-bug resolver, even if in theory this assumption should be verified. it happens a lot of time that a maintainer of a package doesn't resolve the related issues, meanwhile if we select an active contributor as "hub" he can resolve himself the packages or managing and assign them to other contributors.


in a few words, i'm introducing the idea of "process reengineering" applied to bugzilla, that it's well known management theory to improve the work quality of a company.

(In reply to comment #5)
> in reply to comment #2
> 
> to do correctely what you think, it needs that every user know which package
> causes the issue, ...

Indeed, in many cases a user doesn't know which package causes this issue.  But part of the role of the bugsquad is to determine which package in such cases, which they do very well.
And without determining the package involved, it isn't possible to resolve the issue.


> in reply to comment #3
> 
> we should simplify the user work, we shouldn't assume that user automatically
> searchs for dulpicates, it is a problem of the project contributors that can be

When the user doesn't find duplicates (which is very frequent), this is another part of the role of the bugsquad.  Which I also think they do very well.


> in reply to comment #4
> 
> i would avoid the corrispondence maintainer-bug resolver, even if in theory
> this assumption should be verified. it happens a lot of time that a maintainer
> of a package doesn't resolve the related issues, meanwhile if we select an
> active contributor as "hub" he can resolve himself the packages or managing and
> assign them to other contributors.

My variation on your idea only uses the rpm category of the package involved  to connect to a list of parties to be cc'd.
Note that sometimes a problem can seem to be related to one factor (say sound), but in fact is related to another factor in a required package, which is the actual package to be corrected/changed.
So my variation automates your suggested process, without requiring a separate field in bugzilla, and avoids a mistaken category.
Otherwise, unless I'm mistaken, there wouldn't be a lot of difference in what is involved to implement it.
It doesn't depend at all on the reaction of the maintainer of the package.

In fact, I very much appreciate your idea, as without it I probably wouldn't have thought of my variation, which I think could help better maintain packages, particularly when the maintainer is slow to respond.  As well as providing more support to unmaintained packages.

in reply to comment #6

thank you André for appreciating my idea : ) my proposal is only a way to imoprove the bug triaging, but even using your method of the comment #4 the result is the near the same, so i will be happy the same if you could implement this whish in reality.... next step is: is it ok for everyone? is there anyone who wants care about implementing this?

How does having an extra list to choose from, work in other bugzilla's? 

Does anybody happen to know that? I would love to see some statistics :)

CC: (none) => marja11

ping

pong

any news about this wish?

no

Actually this is no good idea, or it wouldn't improve anything. We currently don't have automatic assignment, and such a list, which could not be automatically created, would not help with that.

Otherwise it's not the users task to fill out the Assignee field, or the rpm package to which this bug belongs, if he doesn't know, ultimately that's the job of the triage team, and they're doing their job quite well IMHO.

And i fail to see how introducing a new component list helps with searching duplicates for bugs that are to be reported.

Also you have not responded to the question from our current bug squad team leader, what is wrong or could be improved on the way bugs are triaged currently?
And how would your proposal help improve that, besides just overcomplicating it?

CC: (none) => doktor5000

simply it happens the most of the times that if i don't know to who assign the bug, it is completely ignored, even if it is a serious one. i'm not interested in how we implement such a system (list, component etc..), i'm interested in improving bug assignation. i can't understand why we must loose triage team time if we can make this step automatic. if a person manage only a certain type of bugs (and he's aware of the tool/program working method) i think it is clear that bugs can be managed in a better way.

(In reply to comment #14)
> simply it happens the most of the times that if i don't know to who assign the
> bug, it is completely ignored, even if it is a serious one.

the bugs you reported and that are still open, are:

https://bugs.mageia.org/buglist.cgi?query_format=advanced&emailreporter1=1&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=marcello.anni%40alice.it&emailtype1=substring

I don't see that your bugs are "completely ignored" the only bugs that are still assigned to bugsquad, are enhancement requests. 

or is it your list of closed bugs that makes you feel ignored?

https://bugs.mageia.org/buglist.cgi?query_format=advanced&emailreporter1=1&bug_status=RESOLVED&email1=marcello.anni%40alice.it&emailtype1=substring

You don't have the slightest idea how much work even a seemingly "ignored" bug often gives. It happens that 2 people work together here for several hours for one single bug report, but come to the conclusion, that there is nothing we can do and that the bug must be closed as wontfix.

(In reply to comment #14)
> i can't understand why we must loose triage team
> time if we can make this step automatic. if a person manage only a certain type
> of bugs (and he's aware of the tool/program working method) i think it is clear
> that bugs can be managed in a better way.

Could you please be more specific about how it is clear that bugs can be managed in a better way and what you mean by better? Also seems you didn't understand the purpose of the triage team, it normally does exactly what you want to automatize, and normally they do a much better job, and treat bugs individually and put them in context, which is also important. It can't really be automated, as f.ex. some packagers are listed as maintainers, but can't allocate spare time to fix bugs, so if we automatically assign some bugs to them, they will in most cases not even get any reply, and the user will get a bad perception.

Also assignation is the part which takes least amount of time, so it doesn't make any sense to automate it, because the bugs also need to be monitored steadily, and Assignee often needs to be readjusted.

@ Marcello

Because it is clear that your intentions are very good and that you really want to help, I'd like to invite you to become a Bug Squad member and/or packager :)

Also, that way you'll become an insider and have more understanding of what might and what might not help ;)


https://wiki.mageia.org/en/Bug_Squad

https://wiki.mageia.org/en/Becoming_a_Mageia_Packager

(In reply to comment #14)

@ Marcello
I agree with comment #17
No matter how much we might wish otherwise, bugs have to be surveyed for various reasons; triaging by the bug squad will always be necessary.
My variation on your suggestion was mostly to cover non-maintained packages, which are becoming fewer and fewer.  (Less than 18% at the moment, they were 55% 5 months ago.)

Your enthusiasm to help is how most contributors get more involved.
Both the bug squad and the packaging team could use more help.
It might be easier to start with the bug squad, but if you decide on packaging, I'll be glad to help you find a mentor :)

in reply to comment #17 

unfortunately i can't get involved in triage team because i study in another town and there i don't use the pc to not loose time, otherwise i would propose already to be a triage member... i can only give my help in opening bugs and translations (and marketing team if it would do what a marketing team is supposed to do).

anyway, about this bug, you're confusing the insipring principle with the method i supposed (just supposed, because i don't know many technical aspects about packaging and triaging). it's simpler than what you think, for istance: marja is the triage member who knows better than all the other the kde system and related kde-bugs, so a KDE field is added in the Componenet field and automatically Marja is cc'ed to it. Nothing prevents to reassign bugs or other, simply the automatic method allows a single person to manage all the component-related issues. what's wrong with this, what don't you understand? 


cheers,
Marcello

(In reply to comment #19)

> for instance:
> marja is the triage member who knows better than all the other the kde system
> and related kde-bugs, so a KDE field is added in the Component field and
> automatically Marja is cc'ed to it. Nothing prevents to reassign bugs or other,
> simply the automatic method allows a single person to manage all the
> component-related issues. what's wrong with this, what don't you understand? 
> 

I do understand what you mean, that has never been the problem.

The problem is, for many users having more choice is an extra barrier (which will keep some from reporting, and cause others to make more mistakes)

Besides, I can already search for bugs with "kde" somewhere in the rpm field

https://bugs.mageia.org/buglist.cgi?query_format=advanced&field0-0-0=cf_rpmpkg&bug_status=NEW&bug_status=REOPENED&type0-0-0=anywords&value0-0-0=kde

and for bugs in which kde is mentioned

https://bugs.mageia.org/buglist.cgi?field0-0-5=content&type0-0-4=substring&value0-0-5=%22kde%22&type0-0-5=matches&field0-0-0=product&type0-0-1=substring&field0-0-1=component&field0-0-4=status_whiteboard&value0-0-2=kde&type0-0-3=substring&query_format=advanced&value0-0-3=kde&field0-0-3=short_desc&bug_status=NEW&bug_status=REOPENED&value0-0-4=kde&field0-0-2=alias&value0-0-1=kde&type0-0-0=substring&value0-0-0=kde&type0-0-2=substring

and I can save those searches and get the output by clicking on the related link at the bottom of any window in bugzilla, after I logged in. It is easier for me to visit those bugs starting from the bugzilla search, than from the mails I'm cc'ed in

Your suggestion is what fedora (and I guess other distro are going) 
But have we so much users/packagers/triagers/developers/bugs/others that this organisation is needed ?

https://bugzilla.redhat.com/query.cgi?format=advanced
 => advanced > fedora > fedora > and you have all component

(In reply to comment #19)
> in reply to comment #17 
> automatically Marja is cc'ed to it. Nothing prevents to reassign bugs or other,
> simply the automatic method allows a single person to manage all the
> component-related issues. what's wrong with this, what don't you understand? 

I also try to help triage bugs, not in deciding who to assign them to,
but more in determining if it's really a bug, or an education issue,
and if it really is a bug, which rpm it should be assigned to, etc.

For this, I'm subscribed to the bugs list, so I see all bug report
messages already.  Those that are assigned to qa, I see twice.
Those that I've added a comment to, I see three times.  Getting
yet another copy of some bug reports cc'ed to me would not speed
things up.

I expect Marja is in a similar situation.

CC: (none) => davidwhodgins

(In reply to comment #19)

> unfortunately i can't get involved in triage team because i study in another
> town and there i don't use the pc to not loose time, otherwise i would propose
> already to be a triage member... i can only give my help in opening bugs and
> translations (and marketing team if it would do what a marketing team is
> supposed to do).

Even occasional contributing to triage would help ... as well as helping you to better understand Mageia.  Where-ever you would like to contribute would be appreciated.

> anyway, about this bug, you're confusing the inspiring principle with the
> method i supposed ... 

I think that most of us understand the idea.
For packages without a maintainer (and as an alternative to multiple maintainers) it could be useful.
Although the specific form you suggested would be problematic in my mind as it would require patching Bugzilla, which would make it harder to maintain.
With all the other useful enhancements to be made, I see this as lower priority, for the moment.

BTW, even though I'm not on the triaging list, I receive many bug reports at least twice as well.

But don't hesitate to present your ideas.  That is a contribution as well.

(In reply to comment #22)

> 
> For this, I'm subscribed to the bugs list, so I see all bug report
> messages already.  Those that are assigned to qa, I see twice.
> Those that I've added a comment to, I see three times.  Getting
> yet another copy of some bug reports cc'ed to me would not speed
> things up.
> 
> I expect Marja is in a similar situation.

Yes, some bugs I receive four times

but this wouldn't add other  mail duplicates, because the notification would be sent only to the person interested, instead to the mailing list. in plus, i think more to macro-areas respect of components, otherwise it would really become to technical and less usable.

(In reply to comment #5)
> we should simplify the user work, we shouldn't assume that user automatically
> searchs for dulpicates, it is a problem of the project contributors that can be
> resolved manually or automatically (as for firefox, that before the filling of
> the bug, shows similar bugs).

If Mageia was running Bugzilla 4.0 or 4.2, you would get this feature for free (i.e. the automatic search for duplicates). But as long as you run 3.6, this won't happen.


(In reply to comment #8)
> How does having an extra list to choose from, work in other bugzilla's? 
> Does anybody happen to know that? I would love to see some statistics :)

Another field won't help. More fields to set = more confusion to users. What you could do, though, is to have more components than just "RPM packages". For instance, RedHat has one component per package. This way, when you select the component/package, this automatically sets the assignee and the CC list. The problem with this solution is that this means a huge list of components, and then you have to keep your list of assignees and CC members up-to-date. Gentoo uses more generic components, such as KDE or GNOME or kernel or games or printing, which is much more manageable. OpenSUSE uses something similar.


(In reply to comment #22)
> For this, I'm subscribed to the bugs list, so I see all bug report
> messages already.  Those that are assigned to qa, I see twice.
> Those that I've added a comment to, I see three times.

What's the point to get 3 times the same email? Why don't you simply use Bugzilla capabilities to watch other users, e.g. some default assignees and QA contacts? You would get only one email.


(In reply to comment #23)
> Although the specific form you suggested would be problematic in my mind as it
> would require patching Bugzilla, which would make it harder to maintain.

Patching Bugzilla? You know you can use extensions instead? No code hacks, easy maintenance, easy upgrades.

CC: (none) => LpSolit

(In reply to comment #26)

Thanks a lot for all the explanations, Frédéric :)

> (In reply to comment #5)
> > we should simplify the user work, we shouldn't assume that user automatically
> > searchs for dulpicates, it is a problem of the project contributors that can be
> > resolved manually or automatically (as for firefox, that before the filling of
> > the bug, shows similar bugs).
> 
> If Mageia was running Bugzilla 4.0 or 4.2, you would get this feature for free
> (i.e. the automatic search for duplicates). But as long as you run 3.6, this
> won't happen.
> 

boklm said that Bugzilla upgrade is planned after Mga 2 release. (so no risk of breaking it while we need it most for beta and rc)

> 
> (In reply to comment #8)
> > How does having an extra list to choose from, work in other bugzilla's? 
> > Does anybody happen to know that? I would love to see some statistics :)
> 
> Another field won't help. More fields to set = more confusion to users. What
> you could do, though, is to have more components than just "RPM packages". 
<snip>
> Gentoo
> uses more generic components, such as KDE or GNOME or kernel or games or
> printing, which is much more manageable. OpenSUSE uses something similar.

In that case, if two persons have a crash in a certain game, and one of them observes the crash only happens in one DE, but not in the another DE, one of them will set the "game" component and the other will set the component to the DE. Will the last one of those two who tries to report the bug automatically see that the first one might be a duplicate?

> 
> 
> (In reply to comment #22)
> > For this, I'm subscribed to the bugs list, so I see all bug report
> > messages already.  Those that are assigned to qa, I see twice.
> > Those that I've added a comment to, I see three times.
> 
> What's the point to get 3 times the same email? Why don't you simply use
> Bugzilla capabilities to watch other users, e.g. some default assignees and QA
> contacts? You would get only one email.
> 

That you can filter them to different folders for easier management. In my case: I use one folder for bugs that I commented in before, because a new mail might be a reply to my comment, one folder for documentation bugs, for when I'm working for doc team, one for all bugs, mostly needed for bugsquad work and for seeing what is happening in cauldron. I should have one more folder, for someone I'm following because he accidentally messed things up in bugzilla twice, but I still need to make that filter.

(In reply to comment #27)
> Will the last one of those two who tries to report the bug automatically
> see that the first one might be a duplicate?

Yes, Because Bugzilla will look for duplicates in the same product, so if the two bugs are filed in two different components of the same product, Bugzilla will find the first bug (unless the titles of the bugs are too different, as Bugzilla is only comparing bug titles to find duplicates).

>as Bugzilla is only comparing bug titles to find duplicates).

that can be a problem with drakbug but we are not here with that :)

Closing.

Status: NEW => RESOLVED
Resolution: (none) => INVALID