cc-list: co-assignee vs. co-reporter

RESOLVED WONTFIX

Status

()

Bugzilla
Query/Bug List
--
enhancement
RESOLVED WONTFIX
13 years ago
10 years ago

People

(Reporter: Oswald Buddenhagen, Unassigned)

Tracking

Details

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (compatible; Konqueror/3.3; Linux) KHTML/3.3.92 (like Gecko)
Build Identifier: 

i have configured two queries for "my" bugs: bugs assigned to me and bugs 
reported by me. but this does not cover bugs where i don't play a main role. 
for those i can query by cc-entry, but unfortunately this gives no separation 
between the possible roles. 
not sure what a proper solution would look like, but two cc-lists seem most 
appropriate. 
 

Reproducible: Always

Comment 1

13 years ago
people here just setup two email accounts (or more)

i have timeless-qa and timeless-assi

jesse has jruderman+whenresolved which i suppose matches up w/ burning edge but
to me seems to be a qa role.

you mention co-reporter, that'd be a third role, no? complaintant, dev, qa.
(Reporter)

Comment 2

13 years ago
> people here just setup two email accounts (or more) 
>  
how ugly. :} 
 
> you mention co-reporter, that'd be a third role, no? complaintant, dev, qa. 
> 
uhm, dunno. at kde we do no real qa for most "products", so this question 
didn't even come to my mind. :} 
you guys will certainly come up with a brilliantly generic 
makes-everyone-happy solution. :) 
 
(In reply to comment #0)
> for those i can query by cc-entry, but unfortunately this gives no separation 
> between the possible roles. 

I don't understand what you mean by "this gives no separation between the
possible roles". You say you can query by cc entry, which is what I'd suggest,
too -- what is missing or unwanted if you do?

Comment 4

13 years ago
if the reporter cannot be more explicit, I suggest to close this bug.
(Reporter)

Comment 5

13 years ago
i really wonder how you manage not to understand, given that 'timeless' showed  
a workaround that pretty explicitly points out the issue. 
anyway, let's try again: 
for some bugs i'm the reporter, for some i'm the assignee. those cases are 
fine for listing; i can just use the respective fields as a search criterion. 
but then there are those bugs where i'm a "co-reporter" (i found my bug to be 
already reported) or a "co-assignee" (i'm not the responsible one, but want to 
see how things progress). for both cases i can put myself in the cc-list - 
which sucks for listing *only one of the groups at a time*, as there is only 
one cc-list. 
 

Comment 6

13 years ago
It is going to be hard to justify the added UI overhead of an extra CC: list for
such a niche request. What you want could be handled by CC: "types", where you
indicated what sort of CC: subscription you had; however, the complexity that
this beckons (extra forms or radio-buttons for each existing subscription) also
makes our current UI look better and better. 

I found the "co-assignee" use case you gave to be rather obscure (I mean, anyone
on the CC: list is in theory "interested on the progress of the bug").

The description of "co-reporter" is interesting, and we could actually implement
a feature that allows filtering by reporter but that follows duplicates marked
-- if you filed a dupe you would be specially treated in this search. I don't
have a good idea of whether the complexity added would make the user model
significantly more confusing that it currently is.

Comment 7

13 years ago
Ahh, I totally understand the problem here. I've also experienced that,
somewhat. I think the best solution is to have two accounts, if you want that
separation. I'd guess that the majority of users just use the CC field as "I
want to know about this bug, for one reason or another." For some bugs I'm
neither the co-assignee or co-reporter.

Perhaps there's some more generic solution to the problem, but we'd probably
want to come up with one that didn't add any complexity to Bugzilla.
(Reporter)

Comment 8

13 years ago
yeah ...  
one problem is, that multiple accounts sort of defeat form autocompletion at 
login time. 
it's also not particularly convenient to have to change accounts in the first 
place (impossible to have the two accounts open at the same time, right?). 
 
complexity ... well, make it a per-user option and disable it by default. even 
if enabled, the role would default to an unspecified catch-all, both when 
adding and when searching. 
 
i guess a role combo next to the cc-add field and in the list the role in 
parentheses is simplest. assignments of myself by 3rd parties happen often and 
they probably would not (bother to make|see) the role assignment, so a 
sensible (and atomic) way of changing the role in necessary, too - maybe a 
second checkbox near the "delete marked cc:s": "change role of marked cc:s". 
 

Comment 9

10 years ago
You can now tag bugs, which gives you an even better way to keep track of bugs you are the "co-reporter" or co-anything.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.