37613 - "Accept bug" or "Take bug" functionality

Status: VERIFIED DUPLICATE of bug 35195

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Description

[Seth Landsman]

"Take bug" is a radio button on the bug form, which reassigns the bug to the
userid you are currently logged in as.  The patch for this is attached.

Comment 1

[Seth Landsman]

Attachment: Take bug patch.

Comment 2

[Mark Hamby]

I do not like the "Take bug" idea very much.  In my mind, "accepting" a bug is
the same as "taking it".  The current Bugzilla operation of "accept for someone
else"
seems to be feature few would (or should) use.

I suggest altering the "Accept bug" to assign to the acceptor as well.
If you insist on adding anothe button to retain the old functionality,
add a "Accept on behalf of assignee".

IMHO (as always),

Mark Hamby

Comment 3

[Seth Landsman]

I disagree with Mark.  I think that Accept and Take provide two different
functions.  To me, Accept assigns the bug to the current owner and Take
reassigns the bug to me.  Perhaps a compromise is a seperate ability to either
customize the associated labels with each function and / or specify which
funtions are available in an installation.

However, I don't think the solution is to change what Accept means, or to drop
the concept of Take, because I know that in some installations one or both of
those functions are used with their current meanings.

Comment 4

[Dave Miller [:justdave]]

I do agree with Mark.  Look up "accept" in the dictionary and see what it says. 

:)  I rest my case.   Someone who's new to bugzilla will think they're taking the 

bug for themselves if you click that button.  (I did until I found out the hard 

way).  I think maybe a good compromise would be to leave Accept there, but double 

it up and clarify it.  i.e.:



(*) Leave as NEW

( ) Accept bug for yourself

( ) Accept bug on behalf of $current_owner



etc.

Comment 5

[Seth Landsman]

This is a different statement than what Mark said.  I do not want to remove the
functionality that already exists (i.e., I want to keep the ability to assign a
bug to someone else), which is what (I think) Mark wanted to get rid of.

I agree that Accept Bug is misnamed.  My preference would be :

<> Mark bug as assigned to $current_owner
<> Reassign bug to yourself
  [] and accept bug (Change status to Assigned)

Or something along those lines.

Comment 6

[Dave Miller [:justdave]]

That is acceptible to me.  It gets the point across and adds functionality 
without removing any.

Comment 7

[Stephen Rasku]

Is it an appropriate for someone to be able to assign the bug to the correct
owner?  Should there be permissions?  Personally, I don't think so.  ASSIGNED is
supposed to mean that the bug is assigned to the "proper person".  I know I
wouldn't be that happy if some yahoo on the Internet assigned a bunch of bugs to
me.

There is a patch for bug 25273 that will allow you to accept the bug for
yourself.  I consider this to be the proper behaviour and have implemented it
for our in house bugzilla.

Comment 8

[leger]

Adding myself to cc.  Tara, we need to hook up with Netscape folks too on this. 
 If this is - every bug assigned to a person has to get accepted by that person, 
 and sits in a que until then, this is bad.  Spam-a-rama :-(

Comment 9

[Matthew Barnson]

Seth: I suggested to Tara an alternate method of making this work, and she
concurred.
Rather than a new radio button on the form (which just adds more complexity),
have the "accept" button be configurable via params to EITHER allow accepting
bugs for others, OR reassign but to yourself on accept.  I've begun working on a
patch to do just this.  The name is "reassigntoselfonaccept", and defaults to
"off" (or 0).
Like the idea, or hate it?

Comment 10

[Seth Landsman]

I think it is a decent idea, but I *REALLY* want to have the capacity to do
both.  There are times where I want to mark a bug assigned to someone else, and
times where I want the shortcut to reassign a bug to myself.

The solution I'd propose is to have buttons themselves configurable.  i.e., I
want a new button called Accept Bug For Me (or something like that), which
changes ownership and sets it as assigned.  Params would turn this button on or
off.  Furthermore, the current Accept bug button would be configurable in the
same manner.  This would allow one or both of these options to be available. 

Comment 11

[Stephen Rasku]

I guess the question comes down to:

Is it reasonable for someone else to set your priorites in this way? Since
ASSIGNED bugs should be worked on before NEW bugs, you are giving this bug a
higher priority then every other NEW bug that assignee has.  If this is
acceptable, then you should be able to ASSIGN bugs that don't belong to you.  If
it's not, then accepting a bug should ASSIGN it to you instead of the current owner.

Comment 12

[Ben Bucksch (:BenB)]

I know, I read somewhere that the idea of "NEW" was not priority, but "unseen",
similar to REOPENED (otherwise, REOPENED bugs could just go to ASSIGNED). This
would mean that nobody else than the assignee can move a bug to ASSIGNED. This
is the behaviour I observed at mozilla.org's bugzilla as well.

Comment 13

[Dave Miller [:justdave]]

Updating the summary to make this bug easy to search for and avoid duplicates.

Comment 14

[Dave Miller [:justdave]]

*** Bug 25273 has been marked as a duplicate of this bug. ***

Comment 15

[leger]

FYI - please don't ever have a REOPENED bug fo directly to Assigned.  I keep 
metrics on how many bugs we fix per week vs. reopen.  Knowing the reopen rate 
assist in project schedule planning.

Comment 16

[Chris Yeh]

chomp

Comment 17

[Allan Miller]

I'd actually like to use a minor variant of this function.  I'm using Bugzilla 
to manage a group of people, both bug fixes and small tasks (it works quite 
well for that).  For the task assignments, it would be convenient to enter 
tasks directly as ASSIGNED.  An easy hack is to just change enter_bug.cgi at 
line 358 to add "ASSIGNED" to the pulldown, conditional on a new parameter in 
defparams.pl called eg. "letsubmitterchoosestatus".  Would this be a general 
fix or is it too counter to the philosophy of Bugzilla in general?

Comment 18

[Dave Miller [:justdave]]

Allan, I think that's just enough different from what's being suggested here 
that it should probably go in its own bug report.

Comment 19

[Dave Miller [:justdave]]

See also bug 35195.

Comment 20

[Allan Miller]

Dave:  OK, thanks for the pointer to bug 35195 (it's good to see that I'm not 
the only one using it like this).  It looks like I'm going to really need this 
functionality, so I'll make a "real" fix (rather than the kludge I have now) 
that incorporates the patch in 35195, and post a patch here after I've had a 
few days to shake out any problems that come up.

Comment 21

[Zach Lipton [:zach]]

Attachment: patch to make the accept bug line assign it to the person doing the accepting

Comment 22

[Zach Lipton [:zach]]

I have just posted a patch that will make the accept bug line change the 
accept buttton to change the owner to the person doing the accepting, and 
to change the status to assigned. I don't think that one should be able to 
force a bug into the assigned state, because that state indicates that one 
is fixing or has plans to fix that bug. When I am doing queries for bugs to 
fix (like for the bugzilla component), I want to see only new bugs, because 
the assigned bugs are already being worked on by someone else. If you 
want to reassign a bug, you can use the reassign bug to or the reassign 
bug to owner field, but there is no easy way to reassign a bug to yourself. 
Adding patch and approval keywords for approval escalation.

Comment 23

[Seth Landsman]

I do *NOT* think the solution here is to make it so the accept button accepts
for the user.  Mozilla, amoung others, has a practice already in place in which
the accept button does what it currently does.  It might not be the best
practice and you may consider it incorrect, but I believe that changing its
meaning to suite your practice is not any more correct.

The solution I advocate (and haven't had the round tuits to implement) is to
allow this (and these) behavior(s) to be customizable.

Comment 24

[Ben Bucksch (:BenB)]

On bugzilla.mozilla.org, I have not seen managers or similar accept bugs on
behalf of others. How would the engineer look for new bugs, then? Isn't
"CONFIRM" what you want?

Also, nobody has the right to accept bugs on my behalf.

I agree with Zach's proposal.

Comment 25

[Dave Miller [:justdave]]

Provide the capability to do both, and make the wording obvious, and people will 
figure it out.  These are the QA Contacts and Developers we're talking about 
here, I would assume they would have enough brains to figure out what the button 
does. :)

As for new people installing bugzilla, the current behavior is counterintuitive, 
and has to be learned the hard way usually.

Comment 26

[Seth Landsman]

I'm not arguing that mozilla's practice is right or wrong, I'm just saying that
mozilla has an *ESTABLISHED* practice.  It would be pretty problematic if all of
the sudden you see a whole lot of bugs assigned to managers on
bugzilla.mozilla.org.

I would argue that the mozilla people need to sign off on this before it is
checked in or approved.

I do think the right approach is to allow this behavior to be customized on a
per-installation basis.

Comment 27

[Ben Bucksch (:BenB)]

Seth,
you say, the established practice for Mozilla were that managers accept bugs on
behalf of their employees. I disagree - I have seen this rarely, if at all -,
but let's assume, this were true, then to

> allow this behavior to be customized on a per-installation basis

would be wrong, because nobody (other than myself) can accept bugs on *my*
behalf, and nobody should even have this option.

Comment 28

[Seth Landsman]

Ben: I think you are incorrect.  Your established practice may be that only you
can accept bugs for me.  However, that is not my established practice and that
is not mozilla's established practice, I believe.  The fact of the matter is not
YOUR practice is not more or less correct than MY practice.  I'd rather that we
not get into the "my way is better than your way" argument and allow both to be
possible.

Comment 29

[Ben Bucksch (:BenB)]

Seth, I don't understand your last comment.

Comment 30

[Ben Bucksch (:BenB)]

To be clear: You being able to accept bugs on bugzilla.mozilla.org on my behalf
*is* wrong. You don't have the right to do that. *If* that is a policy question,
then the mozilla.org policy is "don't do that", and it should IMO be enforced by
software.

Zach's patch does this and also adds the feature to conviently reassign bugs to
myself and accept them in one step.

Comment 31

[Seth Landsman]

Ben: First off, the policy that only the owner of the bug can transition the bug
into the accepted state is not the policy for my installation of bugzilla.  

Second, I appologize, but I'm unfamiliar with your relationship to the mozilla
project.  Before saying "yeah, that's mozilla's policy", I'd like to hear from
people on [e-mail], who can say "mozilla's policy is for it to work
this way".  If you are one of them, great.  However, I have a feeling that there
are people at mozilla who use the functionality as is.  There is no such thing
as "correctness" in a bugtracking system like this, there is only established
patterns of behavior, and it is important that changes to bugzilla do not change
the patterns that work, regardless of how incorrect you think they might be.

I do not see why you are unwilling to accept the possibility that the way
bugzilla works now is useful to some people.  I'm arguing to start making these
bits configurable, because *I* do use the accept button as is.  In fact, if you
look at the first patch attached to this bug, you'll see the change that I made,
which leaves the functionality alone, but let's me make the transition to
ASSIGNED and ownership change via commit.

All I would like to see is for the accept bug functionality to REMAIN A
POSSIBILITY FOR THOSE WHO USE IT.  I do not want you to use it, and I don't care
of bugzilla.mozilla.org has it (it isn't up to me, and I'm not sure if it is up
to you), but I want it to be configurable enough so that you aren't making the
decision for me, and I'm not making the decision for you.

Grok?  Feel free to take this off bugzilla and email me personally.

Comment 32

[Ben Bucksch (:BenB)]

Seth, I think, we should make the discussion here on .mozilla.webtools, so
others can follow it.

No, I'm not from mozilla.org, but I am a Mozilla developer.

> I do not see why you are unwilling to accept the possibility that the way
> bugzilla works now is useful to some people.

I do undnerstand and accept that your proposed behaviour is useful in some
situations. However, it is also very problematic in some cases, and I argue that
this outweights the usefulness of the way you describe. So, if we have to
choose, we should IMO follow Zach's and my suggestion, at least for
bugzilla.mozilla.org.

So a a per-installation pref might help your installation, but would make no
difference for bugzilla.mozilla.org.

What would be reqired for bugzilla.mozilla.org is a complex rights hierarchy,
which basically stores the management hierarchies. Above me, there is only
mozilla.org, so only mozilla.org people (if at all) and I should be able to
accept bugs on my behalf. Above Netscape employees, there are their managers,
and they would be allowed to accept bugs on the behalf of their employees. (Is
there any other situation you have in your mind?) Obviously, this is non-trival
to implement.

So, right now, we have to choose, and we should IMO choose Zach's suggestion,
because it does IMO less harm.


Can you explain *why* you want to accept bugs on the behalf of others?

Comment 33

[Seth Landsman]

Ben: Any change made to the bugzilla tree affects all users of bugzilla, not
just you and not just bugzilla.mozilla.org.  Making this change should not be
made because you think the behavior is incorrect, but should be made by
consensus of all users of bugzilla, as this is changing a fundemental behavior,
that, while it is not optimial, is already in practice.

A patch which lets us configure this behavior is not that much more complex and
overcomes this issue.  bugzilla.mozilla.org has been working this way for a very
long time.  Holding off for a patch which doesn't break existing practices is
worth it.  What about a simple change which makes two buttons, an "Accept and
take bug" and an "Accept bug for existing assignee"?

My installation uses the "accept-for-others" functionality to help partition
bugs among developers.  We use the concept of ASSIGNED as a suggestion of "I
think the bug is in the code you are responsible for".  I'm unwilling to debate
whether or not this is a good practice.  This works well for us, and that is
enough.

Comment 34

[Ben Bucksch (:BenB)]

> A patch which lets us configure this behavior is not that much more complex
> and overcomes this issue.

OK, then submit a patch, let's check it in, and set it to Zach's proposed
behaviour for bugzilla.mozilla.org.

> What about a simple change which makes two buttons, an "Accept and
> take bug" and an "Accept bug for existing assignee"?

You still don't seem to get me. I don't want the second option to at all exist
on bugzilla.mozilla.org, at least not on bugs I own.

> We use the concept of ASSIGNED as a suggestion of "I
> think the bug is in the code you are responsible for".

We#re talking about ACCEPT, not ASSIGN. ASSIGN is used that way in
bugzilla.mozilla.org, too, but it goes into NEW, so the new owner sees that
there is a bug he might not have looked at yet. ACCEPT means, "Yes, I will look
into the bug" or "Yes, this is indeed my bug, and I intend to fix it" or similar.

> This works well for us, and that is enough.

Sure, but not, if it doesn't work for us.

Comment 35

[Seth Landsman]

Ben: I'm not claiming that you should accept my particular behavior, but I'm
saying that the behavior you want excludes the behavior that *I* want.  A
configurable patch is ideal, and I hope to find time to write it this weekend. 
The behavior which the current patch implements, though, kills my group's
current practice.

It feels like I keep saying the same thing and you reply with the same
arguement.  I would like to hear from some other people.

(BTW, I meant ASSIGNED in how my group works.  It is too early in the morning
and I've had way too little caffeine).

I propose that the choices which can change the state of the bug be
configurable.  We have a list of state transitions and all of us want a
different set to be available.  *I* want a choice to reassign a bug to me, a
choice to set the bug as ASSIGNED to the current owner and a choice to both
REASSIGN the bug and set it as ASSIGNED to me.  *YOU* want a choice to both
reassign the bug to yourself and set it as assigned, but no choice to just
ASSIGN the bug to the current owner.  Ideally, bugzilla should be able to 
configure itself to do either.

Would a system like that be acceptable to you?  Would a system like this be
acceptable to both the mozilla and bugzilla people?

Hmm, maybe I'll do battle with this after lunch.

Comment 36

[Ben Bucksch (:BenB)]

> Would a system like that be acceptable to you?

Yes.

Comment 37

[Stephen Rasku]

Seth,

What is the purpose of a user ASSIGNING (NEW -> ASSIGN) to the current owner?  I
don't understand the logic behind this.

Comment 38

[Allan Miller]

Wow.  I just came back to look here.  I didn't intend to start such a big 
discussion.  However, it is certainly a NECESSITY for me to accept bugs for 
others, because they work for me, and I'm the one making the decisions about 
what they work on.  I certainly understand that this isn't the way Mozilla is 
organized, and that's why my original suggestion was to make these features 
conditional on a new parameter in defparams.pl.  The main goal for me is to 
reduce the amount of email (as it stands right now, the engineers get two 
pieces of email every time I submit a task for them or assign one that someone 
else submitted: the first piece when it gets assigned to them, and the second 
piece when it changes status from NEW to ASSIGNED).  I'll eventually get around 
to implementing this, and post a patch (no promises on delivery dates).

Comment 39

[Dave Miller [:justdave]]

This is going to be a long post, so bear with me here...

I think the confusion here is one of ASSIGNED vs. ACCEPTED.

Some sites are using ASSIGNED to mean ASSIGNED, that the person named is supposed 
to take care of it.

Other sites are using ASSIGNED to mean ACCEPTED, that is, the person named has 
seen the bug and intends to work on it.

What I would like to see done is to completely parameterize the entire status/
resolution system so it can be customized on each site (not just with accept vs 
take, but the whole thing).

What would need to be done is to have a way to define what bugzilla will do with 
any given state.  We would need to create a flowchart, if you will, that is 
machine readable.  Here's kind of what I envision:

Table "bug_states"

state_now      varchar(24),
avail_states   varchar(24) not null,
privs_required tinytext,
req_resolution varchar(1) not null  (abbrev. below so it won't wrap),

unique         (state_now,avail_states)

+-------------+--------------+--------------------------------+-----+
| state_now   | avail_states | privs_required                 | r_r |
+-------------+--------------+--------------------------------+-----+
| (null)      | UNCONFIRMED  | (null)                         | N   |
| (null)      | NEW          | (canconfirm|editbugs)          | N   |
| UNCONFIRMED | NEW          | (canconfirm|editbugs|owner|qa) | N   |
| UNCONFIRMED | ASSIGNED     | (editbugs|owner|qa)            | N   |
| UNCONFIRMED | ACCEPTED     | (editbugs|owner)               | N   |
| UNCONFIRMED | RESOLVED     | (editbugs|owner|qa|reporter)   | Y   |
| NEW         | ASSIGNED     | (editbugs|owner|qa)            | N   |
| NEW         | ACCEPTED     | (editbugs|owner)               | N   |
| NEW         | RESOLVED     | (editbugs|owner|qa|reporter)   | Y   |
| ASSIGNED    | NEW          | (editbugs|owner|qa)            | N   |
| ASSIGNED    | ACCEPTED     | (editbugs|owner)               | N   |
| ASSIGNED    | RESOLVED     | (editbugs|owner|qa|reporter)   | Y   |
| ACCEPTED    | NEW          | (editbugs|owner|qa)            | N   |
| ACCEPTED    | RESOLVED     | (editbugs|owner|qa|reporter)   | Y   |
| RESOLVED    | REOPENED     | (editbugs|owner|qa|reporter)   | C   |
| RESOLVED    | VERIFIED     | (editbugs|qa|reporter)         | K   |
| RESOLVED    | CLOSED       | (editbugs|owner|qa)            | K   |
| REOPENED    | ASSIGNED     | (editbugs|owner|qa)            | N   |
| REOPENED    | ACCEPTED     | (editbugs|owner)               | N   |
| REOPENED    | RESOLVED     | (editbugs|owner|qa|reporter)   | Y   |
| VERIFIED    | REOPENED     | (editbugs|owner|qa|reporter)   | C   |
| VERIFIED    | CLOSED       | (editbugs|owner|qa)            | K   |
+-------------+--------------+--------------------------------+-----+

The required_privs field is text to make it easy to edit.  You could use 
parentheses, | (or), and/or & (and) to create privilege sets, so for example, you 
could require more than one groupset BOTH be set in order to change a particular 
state.  You could for example, create a groupset called "managers" and add all of 
your management people to it, so you could then make a particular state change 
only allowed to be used by a manager.

The req_resolution column letters would have the following meaning:
N = no resolution, ignore resolution setting
Y = prompt for a new resolution when making this state change
K = keep the existing resolution when making this state change
C = clear the resolution field when making this state change

This would, of course, necessitate that the status fields be changed from enums 
to text fields, but I believe that's the plan these days anyway.

I'm thinking it might also need an additional column to state which resolutions 
are available (handle it the same as avail_states - one row for each state/
resolution combination), and a column to specify if that particular state change 
belonged to a predefined bugzilla action (such as marking a bug as a duplicate, 
or moving a bug), but for space reasons (geez, this is getting long already) it's 
a little hard to demonstrate here.

Any comments?

Comment 40

[Chris Yeh]

The ability to customize the state definitions, names, and state flow would be 
very good to have. You'll probably want to store off this information into some 
kind of static file so that you don't query the database each time you want to 
find out what the next state is. 

I'm not sure that the req_resolution field makes sense, it seems to me that 
there should be a better way of storing that state information in a better 
format. Everything else looks great.

Comment 41

[Chris Yeh]

I think there's enough discussion here that we should shelve this for 2.12 and 
drop it off the list.  Removing 2.12 from the whiteboard.

Comment 42

[Ben Bucksch (:BenB)]

> The required_privs field is text to make it easy to edit.

Not a good reason. If you want easy edit, then build an editor. Don't adjust the
database format to humans.

Comment 43

[Dave Miller [:justdave]]

How would you suggest storing it then?  Actually, it's text because it needs to 
contain more than one value, and they're not all included in the groupset.  It 
also allows you to use things like AND and OR (&/|) and parentheses for a little 
better control over what combination of privs is really required.

Comment 44

[Dave Miller [:justdave]]

BTW, I'm not trying to be defensive here, I was just more clearly explaining what 
I had in mind, and I really do want to see other ideas if anyone has any.

Comment 45

[Ben Bucksch (:BenB)]

Dave, I have no better suggestions how to store it - I don't know Perl. Just
requiring humans to edit the database is IMO a bad idea. You'd need fancy
error-recovery in bugzilla, then.
Also, if you have to make is it text-based, make sure to "compile" it anyhow
(interpret it once during startup and cache the result), so you don't have to
interpret the text for each showed bug.

Comment 46

[Dave Miller [:justdave]]

Oh, I was never intending for humans to be able to edit the database directly 
with this. :-)  Of course there will be an editor that will do error checking on 
the human input before storing it in the table.  And since this would usually be 
a semi-permanent setup once it's done on a given site, I have no arguments 
against caching the data for easy retreval when displaying bugs.  It could be 
added to the existing versioncache with very little effort, I'm sure.

Comment 47

[Andreas Franke (gone)]

Myk, you may be interested in this bug ;-)

Comment 48

[Hixie (not reading bugmail)]

(if it is ever implemented, my version of bugzilla 3.0 will have the ability 
described by Dave Miller on 2000-09-16 04:02)

Comment 49

[Eric Hanson]

It seems to me (sorry but this whole thing does seem a little silly), that the
functionality should change so only someone who has been ASSIGNED a bug can
ACCEPT a bug.  Managers can assign bugs, then the coders accept and report
status on them.  
It does not make any sense to have a button labled wrongly simply because that
is how it was.  It is a bug, it should be fixed.  If people have missused this
feature in the past it is thier concern.  No one should be accepting bugs for
anyone else.  ASSIGNING yes, ACCEPTING no.  It isn't a matter of opinion, but of
how the bug process works.
The MySql table stuff might be suited to another bug since it seems to address a
slightly larger issue.  This should have been fixed a year ago.

Comment 50

[Seth Landsman]

This is an old and annoying argument.  In my bug tracking practice, I need the
ability to mark a bug as accepted for someone else.  i.e., to keep track of what
other people are doing who don't change the bugzilla status themselves.  Perhaps
the button in bugzilla is mislabelled.  Perhaps in YOUR INSTALLATION you would
rather have different functionality.

However, I don't think it is acceptable to change FUNCTIONALITY THAT IS IN USE
regardless of whether or not you disagree with it.

I'm much happier with the proposed system of letting the buttons and assigned
functionality be based on a table and / or template.  I'd rather not lose the
functionality that I require.  

Comment 51

[Matthew Tuck [:CodeMachine]]

I figure there's no need to specify the resolution behaviour on the transition
table, instead you define on the status table whether a status is open or not. 
Then:

open -> closed = Y
open -> open = N
closed -> open = C
closed -> closed = K

I'm pretty sure that the open/closed distinction would be necessary for other
things too, for example bug #24496, which asks to disallow RESOLVED FIXED when
there are open bugs blocking this.

Comment 52

[Dave Miller [:justdave]]

hmm, yeah, could make queries simpler, too, by allowing a pseudostatus of "OPEN" 
to be used which would match any open status.  I'd say the same for CLOSED, but 
we already have a status named that....  hmm.

Comment 53

[Matthew Tuck [:CodeMachine]]

Well VERIFIED and CLOSED bugs are also resolved, but that doesn't help either. 
Maybe we should replace CLOSED with a decent regression checking system (that
allows you to check it more than once) and nuke it. =)

Comment 54

[Dave Miller [:justdave]]

for the way most places use it, maybe CLOSED should be RELEASED, then CLOSED can 
be a pseudo status that applies to RESOLVED, VERIFIED, and RELEASED.

Comment 55

[Dave Miller [:justdave]]

Taking all of cyeh's Bugzilla bugs.

Comment 56

[Christopher Aillon (sabbatical, not receiving bugmail)]

-> New product Bugzilla.

Comment 57

[Matthew Tuck [:CodeMachine]]

Customisable statuses now lives at bug #101179.

Comment 58

[Gervase Markham [:gerv]]

Changing this would confuse too many people to be worth the incremental benefit.

Gerv

Comment 59

[Dave Miller [:justdave]]

I disagree, Gerv.  It would only confuse people who are already used to it, and
I would bet it doesn't confuse them for long, since the proposed way is so much
more intuitive.  If it helps, we could even put some instructional text right
next to the new buttons to explain how they changed.  There's a lot of new
people using Bugzilla all the time (even on b.m.o, new people reporting bugs,
new people joining the development efforts, etc).  The way it is now confuses a
good portion of the new people until they get trained.  So the choice here is
retraining all of your existing people once, or having to train all the new
people every time you get someone new involved.

The way it is now also confuses most of the people who set up new Bugzilla sites
(just look at all the postings we keep getting to the newsgroup complaining
about it).  If b.m.o is *that* opposed to it, we should make it the clear way by
default, but make it a param so people can have it the old way if they want, and
let b.m.o set the param if they don't want to change.  Although I really think
b.m.o should change, too, for the reasons stated in my first paragraph.

Comment 60

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 61

[David D. Kilzer (ddk)]

See also Bug 94247 - Allow reporters to ABANDON bugs.

Comment 62

[Kai Bartels]

I strongly second Seth's comment from 2000-05-01 12:13 . It would be really
helpful to have both functionalities available.

Comment 63

[Veda Larson Palmer]

I would also really like to have both functionalities available.

I think that bug 35195 (request for "and accept bug" checkbox under reassign 
radio button) addresses this very nicely, with a minimal addition to the UI.  
(An alternative would be to have a checkbox under the "accept" radio button to 
reassign the bug to yourself.)

(Also, all of this wording will be much less confusing if/when the "ASSIGNED" 
status is renamed to "ACCEPTED" - bug 104049.)

Comment 64

[Dave Miller [:justdave]]

*** Bug 185040 has been marked as a duplicate of this bug. ***

Comment 65

[Dave Miller [:justdave]]

OK, since this bug really encompases two things, which are both being handled on
other bugs, I'm resolving this bug to consolidate the discussion.

The "Accept bug" issue as a reassignment option is being handled on bug 35195.

The "ACCEPTED" state as a separate entity from ASSIGNED is being handled on bug
101179.


*** This bug has been marked as a duplicate of 35195 ***

Comment 66

[Dave Miller [:justdave]]

clearing target on bugs with resolution other than FIXED so they'll show up as
untriaged if they get reopened.