Am 2014-11-26 um 18:05 schrieb tibor17:
Hi Michael,
I've seen that you are closing the issues in SUREFIRE according to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
Do you want to make any new regulations in closing the bugs or you suppose
this mail discussion
bor17
--
View this message in context:
http://maven.40175.n5.nabble.com/DISCUSS-Idle-bug-handling-approach-tp5815394p5817003.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-uns
thus I closed them. Except
> for one bug where I made an exception which will be categorized as an
> improvement possibly in a new JIRA ticket.
>
>
>
> -
> BR, tibor17
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/DISCUSS-Idle-bug-handling-ap
I thinks this is great. Add item 5:
5. Some judgement should be used when applying this procedure to
issues that have significant user involvement.
We should probably make 2 tags in jira for issues that are in state 2
and 4; "feedbackRequired" and "Closeable" ? :)
Kristian
2014-11-24 22:58 GMT
View this message in context:
http://maven.40175.n5.nabble.com/DISCUSS-Idle-bug-handling-approach-tp5815394p5815645.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-uns
Folks,
here is a little wrap up after the ideas and votes posted so far:
1. Ask for additional information if you think you can fix that bug or
want to help someone else to drag some attention
2. Give the reporter 30 days
3. Add a reminder after 30 days for a grace period of 10 days
4. 10 days
At m2e, we automatically close bugs that have not seen a meaningful
movement for 12+ months. This helps keep our bug backlog manageable and
m2e users seems to be content with this policy for the most part.
We don't have development resources to fix every single problem in our
projects, so we only
On 23 November 2014 at 21:33, Benson Margulies
wrote:
> >
> >
> > > > I am also slightly sceptical of carpet-bombing jira with this stuff;
> > > > once we request more test data we're also giving the expectation that
> > > > someone /will/ be looking at the additional data that the user has
> > >
Am 2014-11-23 um 20:48 schrieb Kristian Rosenvold:
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
There are some bugs that have very well written bug reports with
detailed descriptions on reproduction and
Am 2014-11-23 um 22:33 schrieb Benson Margulies:
I am also slightly sceptical of carpet-bombing jira with this stuff;
once we request more test data we're also giving the expectation that
someone /will/ be looking at the additional data that the user has
supplied. So I would be expecting whoev
Am 2014-11-23 um 22:32 schrieb Stephen Connolly:
On 23 November 2014 at 19:48, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
There are some bug
>
>
> > > I am also slightly sceptical of carpet-bombing jira with this stuff;
> > > once we request more test data we're also giving the expectation that
> > > someone /will/ be looking at the additional data that the user has
> > > supplied. So I would be expecting whoever triages with this metho
On 23 November 2014 at 19:48, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> I think this is a very good idea. But I have seen this mis-used a few
> times in other projects, and I think we want to avoid this scenario:
>
> There are some bugs that have very well written bug reports wit
+1
Le dimanche 23 novembre 2014 21:34:31 Karl Heinz Marbaise a écrit :
> Hi,
>
> +1 from me to...
>
> On 11/23/14 8:48 PM, Kristian Rosenvold wrote:
> > I think this is a very good idea. But I have seen this mis-used a few
> > times in other projects, and I think we want to avoid this scenario:
Hi,
+1 from me to...
On 11/23/14 8:48 PM, Kristian Rosenvold wrote:
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
There are some bugs that have very well written bug reports with
detailed descriptions o
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
There are some bugs that have very well written bug reports with
detailed descriptions on reproduction and/or quite a few watchers too.
I've seen this "rule" m
+1
Good idea. I err on the side of expunging to reduce the foot print. If the
person cares enough they will come back. There's a lot of gorp in JIRA.
On Nov 23, 2014, at 2:05 PM, Michael Osipov wrote:
> Hi folks,
>
> this has been itching me for quite some time now. Once in a while, I check
+1
On Sunday, November 23, 2014, Michael Osipov wrote:
> Hi folks,
>
> this has been itching me for quite some time now. Once in a while, I check
> our JIRA projects for open issues and try to evaluate them for fixability,
> etc. While some reporters respond after a question, some never do.
>
>
Hi folks,
this has been itching me for quite some time now. Once in a while, I
check our JIRA projects for open issues and try to evaluate them for
fixability, etc. While some reporters respond after a question, some
never do.
I'd like to propose to close a ticket as *Incomplete* when the re
19 matches
Mail list logo
