New "INCOMPLETE" resolution in Bugzilla

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
Gervase Markham wrote:
> If the code running on b.m.o. were a branch in an SCM instead of a big
> tarball patch, people could check it out, get it working for them, write
> patches and test them with much greater ease. It would also make it much
> easier for b.m.o. to be upgraded (and downgraded again if necessary) to
> take safe incremental improvements - because there would not be manual
> patching and merging steps involved.

preed (who is responsible for maintaining the b.m.o. codebase) tells me
that there are no plans for this to happen until a better SCM than CVS
comes along in which to put the code. If there was a b.m.o. branch, he
would want to restrict checkins to it, and CVS doesn't allow that.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Gervase Markham
Gervase Markham wrote:
> If the code running on b.m.o. were a branch in an SCM instead of a big
> tarball patch, people could check it out, get it working for them, write
> patches and test them with much greater ease. It would also make it much
> easier for b.m.o. to be upgraded (and downgraded again if necessary) to
> take safe incremental improvements - because there would not be manual
> patching and merging steps involved.

Reed Loden (who is responsible for maintaining the b.m.o. codebase)
tells me that there are no plans for this to happen until a better SCM
than CVS comes along in which to put the code. If there was a b.m.o.
branch, he would want to restrict checkins to it, and CVS doesn't allow
that.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Christopher Aillon
In reply to this post by Gervase Markham
Gervase Markham wrote:
> Vladimir Vukicevic wrote:
>> I very much agree here -- I think that the way the Red Hat bugzilla
>> works is exactly the functionality that we want here: a bug in the
>> NEEDINFO state reverts to NEW as soon as a comment is added, without the
>> commenter explicitly needing to set anything.
>
> If people are interested in making it easier to have b.m.o. take
> functional enhancements of this sort, they need to be aware of how
> things work at the moment.

I just talked to dkl who maintains our bugzilla.  Sadly he doesn't have
a patch that is upstreamable right now because of some dependencies on
RH-bugzilla-specific stuff.  We're going to port to bugzilla 3.0 though
in the near future and this will need to happen.  Expect a patch in the
next two months for NEEDINFO support which can be submitted to both
upstream bugzilla and it could probably be used in ours as well,
hopefully with minimal merge conflicts (I've not seen either patchsets).
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Mike Connor-4
In reply to this post by Mike Shaver

On 27-Mar-07, at 7:51 PM, Mike Shaver wrote:

> On 3/27/07, Mike Connor <[hidden email]> wrote:
>>
>> On 27-Mar-07, at 3:53 PM, Dan Mosedale wrote:
>>
>> > On 2007-03-26 14:47:57 -0700, [hidden email] said:
>> >
>> >> The other problem with NEEDS INFORMATION is that it implies  
>> that more
>> >> information is desired, which we want to avoid.
>> >
>> > Why do we want to avoid that?  Isn't that, in fact, exactly what we
>> > want to express?
>>
>> This is unclearly stated, but my thinking is that we want to avoid
>> reopening that particular bug, instead encouraging the reporter to
>> file a clean and detailed report.
>
> If the bug is a bad report, maybe, but telling them that they should
> file a new bug because we want them to tell us more about which
> version of something they're using, or if they have a given extension
> installed, etc. seems like the wrong path.  We lose all the cc: state
> and such when the reporter does that, so I think we should generally
> avoid it unless the bug is so messed up as to be a significant
> impediment to actually fixing it.

I think that there are many bugs that are filed in such a state that  
they're unfixable.  The amount of time and comments it takes to get  
to a useful bug report is inversely proportional to the odds it will  
get fixed, which is why I have argued that such a bug is typically  
not worth significant effort.  NEEDINFO is an added intermediate step  
for the grey areas, I would argue that bugs needing more info that  
don't get another comment after a given time should automatically  
change to INCOMPLETE in time.  If we need more info from the  
reporter, and we don't get that info in a reasonable amount of time,  
the odds are slim at best that we'll ever get the needed information.

In terms of what we've been doing with triage in the last 3-4 years,  
the guideline has been to resolve as INVALID or WORKSFORME anything  
that is lacking the info needed to fix it, rather than commenting and  
leaving as UNCONFIRMED, based on the low (< 3-4%) rate of responses  
to triager questions.  This is just adding another potential state  
that is less inflammatory and more correct (INVALID is overloaded, as  
we use it for both "this is not a bug, this is expected behaviour"  
and "this bug lacks the required information.")

So NEEDINFO -> INCOMPLETE for the grey areas, and INCOMPLETE for  
obviously poor bugs, with links to the right ways to follow up on  
their issue.

-- Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Mike Shaver
Mike Connor wrote:
> I think that there are many bugs that are filed in such a state that
> they're unfixable.  The amount of time and comments it takes to get to a
> useful bug report is inversely proportional to the odds it will get
> fixed, which is why I have argued that such a bug is typically not worth
> significant effort.  

Mike makes an important point. We need to accept at this stage that we
do not have the resources to exhaustively investigate every bug report
or complaint we get. (That's one reason Hendrix exists.) Therefore, we
should focus on those which are well-reported - because they give the
most bang for the buck.

If there's a problem affecting multiple people, there will be good and
bad bug reports of the same issue. As long as one of the good ones gets
dealt with, then we are OK. Recognising and closing out the bad ones
quickly is just good use of scarce resources.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Gervase Markham
Christopher Aillon wrote:
> I just talked to dkl who maintains our bugzilla.  Sadly he doesn't have
> a patch that is upstreamable right now because of some dependencies on
> RH-bugzilla-specific stuff.  We're going to port to bugzilla 3.0 though
> in the near future and this will need to happen.  Expect a patch in the
> next two months for NEEDINFO support which can be submitted to both
> upstream bugzilla and it could probably be used in ours as well,
> hopefully with minimal merge conflicts (I've not seen either patchsets).

I would point out that the last time we discussed the Bugzilla workflow,
the agreed "ideal workflow" didn't include a NEEDINFO state. Instead, it
had a READY state.
http://steelgryphon.com/testcases/bugzilla-workflow-9.png

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Stephanie Erin Daugherty-3
In reply to this post by majken@gmail.com
[hidden email] wrote:

> On Mar 28, 1:02 am, "Stephanie" <[hidden email]> wrote:
> Stephanie - I might not be catching on to what you're meaning, but how
> I'm understanding it, I don't see how it makes any difference to how
> things are now.  I'm not sure why the bugs have to be examined
> repeatedly, and so maybe this is the heart of why I'm not getting it.
> Even so, how would NEEDINFO change that?  The way I'm grasping it,
> you're watching the bug for more information either way.
>
> The missing info state would mean you do one pass on the bug, see that
> you can't simply ask a question like "do you have extensions
> installed?" or "what version are you using?"  Mark the bug as
> INCOMPLETE (ideally this adds a canned response directing the reporter
> to seek support who can either help solve their issue, or help them
> troubleshoot the issue so they can file a complete bug) and then move
> on.
>
Not really. Putting the bugs in NEEDINFO gets them out of UNCONFIRMED or
NEW, therefore making everything in the UNCONFIRMED state ready for some
form of triage - it will either go from UNCONFIRMED to NEW or from
UNCONFIRMED to NEEDINFO, or from UNCONFIRMED to RESOLVED.

There'd no longer be a wait in UNCONFIRMED for the reporter to reply to
comments - basically just making sure that the workflow clearly
indicates who needs to move the bug forward, instead of just a
UNCONFIRMED busy loop for the triagers of seeing the same bugs over and
over again until we realize they are old enough without further comment
to just RESOLVED INVALID.








_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Stephanie Erin Daugherty-3
In reply to this post by Gervase Markham
Gervase Markham wrote:
>
> I would point out that the last time we discussed the Bugzilla workflow,
> the agreed "ideal workflow" didn't include a NEEDINFO state. Instead, it
> had a READY state.
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png
>
> Gerv

Then either theres a need to change the guide for triagers and the
bugzilla process to say that it's ok to ruthlessly close bugs without
enough info on sight (ie, such bugs go directly to RESOLVED INCOMPLETE
right away, without trying to prod the reporter), or the "ideal"
workflow needs to better reflect the realities of bugs being filed
without enough information, and how we go about getting enough information.

Regardless, if bugs are sitting in UNCONFIRMED, we need somewhere to
send them as they are triaged, rather than have them sit there waiting
for enough information to trickle in to confirm them.

There's a major problem to be solved though, and the unconfirmed bug
lists aren't getting any smaller :(

--Stephanie


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

signature.asc (260 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Andrew Schultz-2
In reply to this post by Gervase Markham
Gervase Markham wrote:

> Christopher Aillon wrote:
>> I just talked to dkl who maintains our bugzilla.  Sadly he doesn't
>> have a patch that is upstreamable right now because of some
>> dependencies on RH-bugzilla-specific stuff.  We're going to port to
>> bugzilla 3.0 though in the near future and this will need to happen.  
>> Expect a patch in the next two months for NEEDINFO support which can
>> be submitted to both upstream bugzilla and it could probably be used
>> in ours as well, hopefully with minimal merge conflicts (I've not seen
>> either patchsets).
>
> I would point out that the last time we discussed the Bugzilla workflow,
> the agreed "ideal workflow" didn't include a NEEDINFO state. Instead, it
> had a READY state.
> http://steelgryphon.com/testcases/bugzilla-workflow-9.png

That workflow may be ideal, but it makes quite a few assumptions that
are unrealistic

1. A bug that was once considered NEW will not end up WORKSFORME (this
happens all the time).
2. A bug that was once considered READY will not end up a DUPLICATE,
INVALID, WONTFIX or WORKSFORME.

In reality bugs that seem valid have to be re-evaluated occasionally,
mostly to catch the ones that have become WORSFORME and DUPLICATE due to
being fixed elsewhere.

We have a clean-report keyword in b.m.o that basically mimics the READY
status.  benc pushed for it a long time ago and nobody uses it (except
him while he was still active).

Anyway, I don't see a big difference between NEW/READY and NEEDINFO/NEW,
except that NEEDINFO more precisely describes the status of many bugs
that are waiting on feedback from someone specifically (usually the
reporter).

--
Andrew Schultz
[hidden email]
http://www.sens.buffalo.edu/~ajs42/

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Stephanie Erin Daugherty-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Schultz wrote:
> Anyway, I don't see a big difference between NEW/READY and NEEDINFO/NEW,
> except that NEEDINFO more precisely describes the status of many bugs
> that are waiting on feedback from someone specifically (usually the
> reporter).
>

I see NEEDINFO more useful to UNCONFIRMED than it is to NEW, although, I
would expect that a transition from NEW to NEEDINFO and back wouldn't be
all that  uncommon either.

Really, the only big difference is that we'd basically be able to ignore
bugs while we're waiting for feedback from the reporter, and
periodically clean those bugs out by querying for NEEDINFO bugs that
haven't been changed in a long time.

Most importantly, as I said in another branch off this thread, this
would eliminate the need to periodically poll UNCONFIRMED bugs to see if
they are ready to be sent elsewhere, and would provide triagers a place
to send every unconfirmed bug - they would all be able to be confirmed,
needinfo, or resolved from the unconfirmed state, so we only need to
look at them once for each time they enter UNCONFIRMED.

- --Stephanie




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGC9k6sUIV80N+s8sRAu2bAKCe7zZkQmsthZrK2f36+s+G8dNhcwCfYpeW
W4kAL4Mg34j0bCKOZhT9eTI=
=51jc
-----END PGP SIGNATURE-----
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Tony Mechelynck
In reply to this post by Gervase Markham
Gervase Markham wrote:
[...]
> If there's a problem affecting multiple people, there will be good and
> bad bug reports of the same issue. As long as one of the good ones gets
> dealt with, then we are OK. Recognising and closing out the bad ones
> quickly is just good use of scarce resources.
>
> Gerv

If there are good and bad reports for a single issue, then one of the good
ones should stay open and get the patches etc. as attachments, and all others
should be RESOLVED DUPLICATE shouldn't they? Or is there something I missed?

Best regards,
Tony.
--
Anxiety, n.:
        The first time you can't do it a second time.

Panic, n.:
        The second time you can't do it the first time.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

majken@gmail.com
>
> If there are good and bad reports for a single issue, then one of the good
> ones should stay open and get the patches etc. as attachments, and all others
> should be RESOLVED DUPLICATE shouldn't they? Or is there something I missed?
>
> Best regards,
> Tony.
> --
> Anxiety, n.:
>         The first time you can't do it a second time.
>
> Panic, n.:
>         The second time you can't do it the first time.

If something is a bad report, you usually can't tell which bug it
falls under.  "My bookmarks are missing" or "my clipboard is broken"
can each be duped to at least 3 different bugs depending on the root
cause.  There will be the case where someone is trying to track down a
particular issue, so they can search the incomplete bugs for the
symptoms and contact the reporters (via email or the bug report, I
don't know which is ideal) for more info and dupe it and there will be
savvy users who will watch bugzilla for similar bugs and let us know
when they see a proper report that describes their issue.  Also, if
users do seek support and do enough troubleshooting to figure out that
their issue is a duplicate, they can comment back.  The idea with
INCOMPLETE is to give a better place for these bugs to live (instead
of UNCONFIRMED) until they can be duped, and a better place to live
(instead of INVALID) if they can't be.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by Andrew Schultz-2
Andrew Schultz wrote:
  > That workflow may be ideal, but it makes quite a few assumptions that
> are unrealistic
>
> 1. A bug that was once considered NEW will not end up WORKSFORME (this
> happens all the time).
> 2. A bug that was once considered READY will not end up a DUPLICATE,
> INVALID, WONTFIX or WORKSFORME.

I don't think it makes those assumptions; I just don't think it's
absolutely exhaustive in enumerating the possible transitions.

> Anyway, I don't see a big difference between NEW/READY and NEEDINFO/NEW,
> except that NEEDINFO more precisely describes the status of many bugs
> that are waiting on feedback from someone specifically (usually the
> reporter).

It's be interested in getting mconnor's feedback on whether he thinks
the two are equivalent. If they are, perhaps we should go in the
NEEDINFO direction, for process compatibility with other projects.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

majken@gmail.com
Not trying to stifle discussion at all, just trying to make sure we
don't lose what we're doing with INCOMPLETE while discussing the whole
process.

I want to check on two things,
a) are we all on board with INCOMPLETE at this point?  I think
everyone is, and some would like to add NEEDSINFO as well (when it's
possible).
b) are we ok with calling it INCOMPLETE or do we want to go back to
discussing alternate names to make it more clear it's the report
that's incomplete and not work on the bug?

-Majken

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Tony Mechelynck
[hidden email] wrote:

> Not trying to stifle discussion at all, just trying to make sure we
> don't lose what we're doing with INCOMPLETE while discussing the whole
> process.
>
> I want to check on two things,
> a) are we all on board with INCOMPLETE at this point?  I think
> everyone is, and some would like to add NEEDSINFO as well (when it's
> possible).
> b) are we ok with calling it INCOMPLETE or do we want to go back to
> discussing alternate names to make it more clear it's the report
> that's incomplete and not work on the bug?
>
> -Majken
>

The principle (with NEEDINFO in addition to UNCONFIRMED/NEW/RESOLVED/REOPENED
and some new resolution type) seems well-described enough. What about RESOLVED
LACKSINFO to make it clearer that the bug was resolved for want of sufficient
information?

Best regards,
Tony.
--
Whom the gods wish to destroy they first call promising.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Christopher Aillon
In reply to this post by majken@gmail.com
[hidden email] wrote:
> Not trying to stifle discussion at all, just trying to make sure we
> don't lose what we're doing with INCOMPLETE while discussing the whole
> process.
>
> I want to check on two things,
> a) are we all on board with INCOMPLETE at this point?  I think
> everyone is, and some would like to add NEEDSINFO as well (when it's
> possible).

I'm okay with the general principle of it,

> b) are we ok with calling it INCOMPLETE or do we want to go back to
> discussing alternate names to make it more clear it's the report
> that's incomplete and not work on the bug?

but not the name per my earlier posts.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Gervase Markham
In reply to this post by majken@gmail.com
[hidden email] wrote:
> I want to check on two things,
> a) are we all on board with INCOMPLETE at this point?  I think
> everyone is, and some would like to add NEEDSINFO as well (when it's
> possible).

Why are INCOMPLETE and NEEDSINFO not synonyms? Or is one a resolution
and another a status?

The current plan of record, should we ever change the statuses, is to
add a READY instead of a NEEDSINFO. A lot of discussion went into that;
I wouldn't want to change the plan until the original participants have
at least commented.

So I'm on board for a new INCOMPLETE resolution but not for status changes.

> b) are we ok with calling it INCOMPLETE or do we want to go back to
> discussing alternate names to make it more clear it's the report
> that's incomplete and not work on the bug?

I can't think of a better name.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Andrew Schultz-2
Gervase Markham wrote:
> The current plan of record, should we ever change the statuses, is to
> add a READY instead of a NEEDSINFO. A lot of discussion went into that;
> I wouldn't want to change the plan until the original participants have
> at least commented.

I don't remember any discussion of READY... where did that happen and
who participated?

--
Andrew Schultz
[hidden email]
http://www.sens.buffalo.edu/~ajs42/

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

Christopher Aillon
In reply to this post by Gervase Markham
Gervase Markham wrote:
> [hidden email] wrote:
>> I want to check on two things,
>> a) are we all on board with INCOMPLETE at this point?  I think
>> everyone is, and some would like to add NEEDSINFO as well (when it's
>> possible).
>
> Why are INCOMPLETE and NEEDSINFO not synonyms? Or is one a resolution
> and another a status?

Yes.


> The current plan of record, should we ever change the statuses, is to
> add a READY instead of a NEEDSINFO. A lot of discussion went into that;
> I wouldn't want to change the plan until the original participants have
> at least commented.

Certainly, but AIUI, there's not much different between adding one
status vs another statuses.  The reasons we opted to go for something
other than READY is because ready is a state that unfixed bugs are
almost always in.  It doesn't really buy much to say a bug is ready.  A
bug can be both ready to be fixed and properly triaged and assigned to
the proper person, or it can be ready to be fixed but not triaged or
assigned, etc.   The reporter might say, "great, my bug is ready but
nobody's working out."  But I guess I should be holding this discussion
elsewhere.

Who were the original participants so I can have another conversation
another day?

>
> So I'm on board for a new INCOMPLETE resolution but not for status changes.
>
>> b) are we ok with calling it INCOMPLETE or do we want to go back to
>> discussing alternate names to make it more clear it's the report
>> that's incomplete and not work on the bug?
>
> I can't think of a better name.
>
> Gerv
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: New "INCOMPLETE" resolution in Bugzilla

majken@gmail.com
In reply to this post by Gervase Markham

> > Why are INCOMPLETE and NEEDSINFO not synonyms? Or is one a resolution
> > and another a status?

NEEDSINFO would be a status for a valid bug, so there are clear steps
to reproduce, but there is still something missing for the developer
to track down what the problem is.  Maybe there are more steps
necessary than first reported, or like our Mozilla apps using 100%
cpu, it turns out it depends on hardware.   It would be very handy for
people who like to do QA, they could just search for bugs with that
status and get testing.  Sounds like this is very interesting as well
and should get its own discussion.

Caillon - the READY thing, I believe mconnor based it off of how
another team, which I forget (QA?) wanted to use it and he liked it.
That was a while ago though, probably time to review and see what's
still a good idea.

Ok - so the suggestions for the *resolution* are so far: INCOMPLETE,
LACKS_INFO, and INSUFFICIENT_DATA.

IMO I don't like using info or data because it can imply that
providing the info or data makes it better.  I'd want to use the word
REPORT. INCOMPLETE_REPORT (or something shorter) although I'm also for
consistency, and since someone already uses INCOMPLETE and someone
else already uses INSUFFICIENT_DATA I'd want to consider them first.
Keep in mind we'd also use this for support requests, which is why I
like something a little more open ended, or focusing on the idea that
the report is just off altogether, rather than implying that there are
a few pieces of info missing.  Again, what's actually wrong with the
report should be explained to the reporter wherever possible so that
they can refile properly, so there may or may not be a need to make
that clear in the resolution's name.

-Majken

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345