Re: JIRA Smackdown
On 15 Jun 07, at 9:58 AM 15 Jun 07, Henri Yandell wrote: On 6/14/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 6/14/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > I created a "Documentation" version so that > technical issues wouldn't be polluted by documentation issues. Documentation is neither a version nor pollution. :) Given the general 'the docs suck' view; this seems like an important point that doesn't seem to have had an answer. I didn't at all mean that. The docs are equally important. The default view of issues skews and obscures the technical issues when I'm trying to focus on them. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JIRA Smackdown
I agree with that. Normally if I intend to fix it later, I just assign it to myself right away. -Original Message- From: Kenney Westerhof [mailto:[EMAIL PROTECTED] Sent: Friday, June 15, 2007 7:27 AM To: Maven Developers List Subject: Re: JIRA Smackdown Hi, I'd like to ask that issues reported by PMC members and core developers get less strict reviews. When I find an issue that's rather complex I usually describe how to reproduce it, but I lack the time to write sample projects, at least when reporting. When i get around to it I reproduce the issue and fix it in svn - I normally don't attach tests since I can commit in core, and i think that goes for more developers. Anyway, the incomplete resolution is fine, but closing them will make them rather hard to find back. Maybe we could just assign these issues to the reporters instead, status to 'feedback' or 'incomplete', 'on hold' or whatever. In the future I'll try to attach the tests as I create the issue, though that'll take me 30 mins more and when I'm in time pressure I feel it's better to report the issue so it doesn't slip my mind, than to not do it at all because of the high overhead. wdyt? -- Kenney Jason van Zyl wrote: > Hi, > > The 2.0.7 release will go out tomorrow, and in order to get some decent > vote feedback it would be good to clean up JIRA so that we have an > accurate 2.0.x list people can vote on for issues they would like fixed > in 2.0.8. I created a "Documentation" version so that technical issues > wouldn't be polluted by documentation issues. I also created a "Reviewed > Pending Version Assignment" where I put everything that's probably been > looked at (probably not entirely true) so that anything coming in from > now on in the unscheduled we can process. I think between all of us we > can probably keep that empty most weeks by assigning a version, closing > if duplicated, or closing due to being incomplete. > > Some simple things you can do if you have a few minutes to spare: > > - look in the reviewed pending version assignment and try to put the > issue in 2.0.x or 2.1.x > - pick your favorite component and look for duplicates > - issues describing a remotely complicated problem without a sample > project get close as incomplete > - look at issues you've reported and check and see if they have been > resolved > - linking issues up that look similiar so we can close issues together > if they are resolved. > > Even if we get rid of the complete cruft like already resolved, dupes, > and incomplete issues that will greatly help. > > Thanks, > > Jason > > -- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > -- > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Smackdown
On 6/14/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 6/14/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > I created a "Documentation" version so that > technical issues wouldn't be polluted by documentation issues. Documentation is neither a version nor pollution. :) Given the general 'the docs suck' view; this seems like an important point that doesn't seem to have had an answer. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Smackdown
On 15 Jun 07, at 9:06 AM 15 Jun 07, Brett Porter wrote: Everything has a component now, and I did a whole bunch of versions while I was at it. The components really need to be adjusted (review/approve the taxonomy and migrate towards that), since I found I had a hard time picking the right one, especially in relation to the project builder, apis and artifacts vs dependencies. I was probably horribly inconsistent. Anyway, even as is that should help to identify dupes/groupings (eg, line up all the requests in the artifacts/repositories component against the upcoming artifact spec). Yah, no worries this will only get better making more and more passes. That's why I don't care if I close a few by mistake, reassign them wrong. The volume in there just has to drop or it's a completely ineffective way of trying to track anything. General approach I've been taking for versions: - if it may work but needs testing, 2.0.x - if it looks fixable without architectural changes, 2.0.x - if it is a feature/bug related to existing architectural goals for 2.1.x, then it goes with that - otherwise, 2.2.x Maybe we should just pool those generally as "Future" as who knows where along the road they will come. As long as it's additive it could go anywhere in the future until we actually have a plan for 2.2.x and can schedule things. But 2.2.x is good enough for "Future" for now. Can always move things back. This doesn't meant 2.*.x are actually "scheduled" - I'd expect the next step is to go through 2.0.x and pull things into 2.0.8 that make sense, clean out things that work, etc. Right, that's why the cleanup is necessary so that we can ask for users to vote, then ask on the dev list for favorites and go from there. Then repeat for 2.0.9 after the 2.0.8 release is done. Same process would apply for 2.1.x, etc. This is going to be a bit more brutal this time around due to the volume, but I think that's an appropriate flow for the future as we just bring in new issues. I expect if we do that for all the review, 2.1.x is going to be too big. We'll need cut that right back to what the core goals are there (the arch. goals page looks to me like "everything we want to fix in Maven", not what the next minor release should be too). That's fine - we can get the big picture together and then start to carve it up. Hope this is suitable to everyone. I'll write it up early next week. Please do spend 30 minutes with it, as Jason has suggested - especially if you haven't looked at your own reported/assigned bugs. It'll make this task a whole lot easier. I think we really could eliminate 10-15% of the issues just getting rid of dupes and incomplete and things that have already been fixed. Cheers, Brett On 16/06/2007, at 12:02 AM, Brett Porter wrote: Quick note - I've added a 'shared components' version for assigning the stuff that isn't in core's versioning scheme (we need to ship them out of the project later on - have added that to my notes). I'm assigning components where they are missing so that it might be easier to identify dupes. - Brett On 15/06/2007, at 3:28 PM, Brett Porter wrote: Heh, my mail was trying to tell me something as it rejected a message asking about these at the same time this arrived :) MPA-90 and 91 came up to the top of my iGTD box today and I was going to work on them this afternoon - but noticed things had been changed. This sounds good to me, and I'll get started on the 'reviewed' bucket. If I understand you correctly, these aren't actually reviewed yet, and this bucket should go away over time (with things going straight into an expected roadmap, right?) So no new issues go in there, and we try and break it down, but get more vigilant on the unscheduled bucket. I strongly disagree with the Documentation 'version'. I've found it to be problematic, and the components should be sufficient. Just exclude those from the filter to get the technical issues. I understand we don't currently distribute and version the documentation, but I think we are all of the opinion now that we should, right? I've no problem keeping it for clean up purposes, as long as (again) no new things are going in there. So I'll continue by reviewing some jiras and documenting this. Thanks, Brett On 15/06/2007, at 3:18 PM, Jason van Zyl wrote: Hi, The 2.0.7 release will go out tomorrow, and in order to get some decent vote feedback it would be good to clean up JIRA so that we have an accurate 2.0.x list people can vote on for issues they would like fixed in 2.0.8. I created a "Documentation" version so that technical issues wouldn't be polluted by documentation issues. I also created a "Reviewed Pending Version Assignment" where I put everything that's probably been looked at (probably not entirely true) so that anything coming in from now on in the unscheduled we can process. I think
Re: JIRA Smackdown
Everything has a component now, and I did a whole bunch of versions while I was at it. The components really need to be adjusted (review/approve the taxonomy and migrate towards that), since I found I had a hard time picking the right one, especially in relation to the project builder, apis and artifacts vs dependencies. I was probably horribly inconsistent. Anyway, even as is that should help to identify dupes/ groupings (eg, line up all the requests in the artifacts/repositories component against the upcoming artifact spec). General approach I've been taking for versions: - if it may work but needs testing, 2.0.x - if it looks fixable without architectural changes, 2.0.x - if it is a feature/bug related to existing architectural goals for 2.1.x, then it goes with that - otherwise, 2.2.x This doesn't meant 2.*.x are actually "scheduled" - I'd expect the next step is to go through 2.0.x and pull things into 2.0.8 that make sense, clean out things that work, etc. Then repeat for 2.0.9 after the 2.0.8 release is done. Same process would apply for 2.1.x, etc. This is going to be a bit more brutal this time around due to the volume, but I think that's an appropriate flow for the future as we just bring in new issues. I expect if we do that for all the review, 2.1.x is going to be too big. We'll need cut that right back to what the core goals are there (the arch. goals page looks to me like "everything we want to fix in Maven", not what the next minor release should be too). That's fine - we can get the big picture together and then start to carve it up. Hope this is suitable to everyone. I'll write it up early next week. Please do spend 30 minutes with it, as Jason has suggested - especially if you haven't looked at your own reported/assigned bugs. It'll make this task a whole lot easier. Cheers, Brett On 16/06/2007, at 12:02 AM, Brett Porter wrote: Quick note - I've added a 'shared components' version for assigning the stuff that isn't in core's versioning scheme (we need to ship them out of the project later on - have added that to my notes). I'm assigning components where they are missing so that it might be easier to identify dupes. - Brett On 15/06/2007, at 3:28 PM, Brett Porter wrote: Heh, my mail was trying to tell me something as it rejected a message asking about these at the same time this arrived :) MPA-90 and 91 came up to the top of my iGTD box today and I was going to work on them this afternoon - but noticed things had been changed. This sounds good to me, and I'll get started on the 'reviewed' bucket. If I understand you correctly, these aren't actually reviewed yet, and this bucket should go away over time (with things going straight into an expected roadmap, right?) So no new issues go in there, and we try and break it down, but get more vigilant on the unscheduled bucket. I strongly disagree with the Documentation 'version'. I've found it to be problematic, and the components should be sufficient. Just exclude those from the filter to get the technical issues. I understand we don't currently distribute and version the documentation, but I think we are all of the opinion now that we should, right? I've no problem keeping it for clean up purposes, as long as (again) no new things are going in there. So I'll continue by reviewing some jiras and documenting this. Thanks, Brett On 15/06/2007, at 3:18 PM, Jason van Zyl wrote: Hi, The 2.0.7 release will go out tomorrow, and in order to get some decent vote feedback it would be good to clean up JIRA so that we have an accurate 2.0.x list people can vote on for issues they would like fixed in 2.0.8. I created a "Documentation" version so that technical issues wouldn't be polluted by documentation issues. I also created a "Reviewed Pending Version Assignment" where I put everything that's probably been looked at (probably not entirely true) so that anything coming in from now on in the unscheduled we can process. I think between all of us we can probably keep that empty most weeks by assigning a version, closing if duplicated, or closing due to being incomplete. Some simple things you can do if you have a few minutes to spare: - look in the reviewed pending version assignment and try to put the issue in 2.0.x or 2.1.x - pick your favorite component and look for duplicates - issues describing a remotely complicated problem without a sample project get close as incomplete - look at issues you've reported and check and see if they have been resolved - linking issues up that look similiar so we can close issues together if they are resolved. Even if we get rid of the complete cruft like already resolved, dupes, and incomplete issues that will greatly help. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com ---
Re: JIRA Smackdown
Quick note - I've added a 'shared components' version for assigning the stuff that isn't in core's versioning scheme (we need to ship them out of the project later on - have added that to my notes). I'm assigning components where they are missing so that it might be easier to identify dupes. - Brett On 15/06/2007, at 3:28 PM, Brett Porter wrote: Heh, my mail was trying to tell me something as it rejected a message asking about these at the same time this arrived :) MPA-90 and 91 came up to the top of my iGTD box today and I was going to work on them this afternoon - but noticed things had been changed. This sounds good to me, and I'll get started on the 'reviewed' bucket. If I understand you correctly, these aren't actually reviewed yet, and this bucket should go away over time (with things going straight into an expected roadmap, right?) So no new issues go in there, and we try and break it down, but get more vigilant on the unscheduled bucket. I strongly disagree with the Documentation 'version'. I've found it to be problematic, and the components should be sufficient. Just exclude those from the filter to get the technical issues. I understand we don't currently distribute and version the documentation, but I think we are all of the opinion now that we should, right? I've no problem keeping it for clean up purposes, as long as (again) no new things are going in there. So I'll continue by reviewing some jiras and documenting this. Thanks, Brett On 15/06/2007, at 3:18 PM, Jason van Zyl wrote: Hi, The 2.0.7 release will go out tomorrow, and in order to get some decent vote feedback it would be good to clean up JIRA so that we have an accurate 2.0.x list people can vote on for issues they would like fixed in 2.0.8. I created a "Documentation" version so that technical issues wouldn't be polluted by documentation issues. I also created a "Reviewed Pending Version Assignment" where I put everything that's probably been looked at (probably not entirely true) so that anything coming in from now on in the unscheduled we can process. I think between all of us we can probably keep that empty most weeks by assigning a version, closing if duplicated, or closing due to being incomplete. Some simple things you can do if you have a few minutes to spare: - look in the reviewed pending version assignment and try to put the issue in 2.0.x or 2.1.x - pick your favorite component and look for duplicates - issues describing a remotely complicated problem without a sample project get close as incomplete - look at issues you've reported and check and see if they have been resolved - linking issues up that look similiar so we can close issues together if they are resolved. Even if we get rid of the complete cruft like already resolved, dupes, and incomplete issues that will greatly help. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Smackdown
On 15 Jun 07, at 4:27 AM 15 Jun 07, Kenney Westerhof wrote: Hi, I'd like to ask that issues reported by PMC members and core developers get less strict reviews. Well, you would most likely assign them to a version/component and possibly assign them to yourself so they wouldn't end up in the review pile. That category is really for incoming issues. When I find an issue that's rather complex I usually describe how to reproduce it, but I lack the time to write sample projects, at least when reporting. When i get around to it I reproduce the issue and fix it in svn - I normally don't attach tests since I can commit in core, and i think that goes for more developers. If you're keeping track that's fine but if you want anyone else to work on it you need to be able to reproduce it. And you need to take the sample project and turn it into tests or and IT. Anyway, the incomplete resolution is fine, but closing them will make them rather hard to find back. Maybe we could just assign these issues to the reporters instead, status to 'feedback' or 'incomplete', 'on hold' or whatever. The reporters will get email when it's closed and see the message. In the future I'll try to attach the tests as I create the issue, though that'll take me 30 mins more and when I'm in time pressure I feel it's better to report the issue so it doesn't slip my mind, than to not do it at all because of the high overhead. It makes you think about it. If you don't report with a project then it's going to take someone else an hour to guess at the exact project structure that caused the failure. I think what they do in Mylar where creating a context is mandatory, and providing some form of test so that the whole environment is setup to deal with the issue. We're not quite there but trying to look at complete issues I now feel is a waste of my time, and waste of anyone else's time trying to fix an issue. The users who get attention will be those that make the effort to provide us with tests. It's that simple. We don't have infinite free time and at least will help those who make the effort right now because we need the information. Could we make this easier in the future? Absolutely, taking a standard stack trace or specially formatted "core dump" that we can read with a utility we could do at some point which might help us pinpoint a problem very quickly but ultimately we need a project as a basis for a test. Are we going to be more productive taking 10 issue in a month with good samples and use cases, or a 100 crap issues that provide almost nothing except a stack trace and a one liner. If someone can't take the time to write a couple sentences and provide a project I'm not looking at it. wdyt? -- Kenney Jason van Zyl wrote: Hi, The 2.0.7 release will go out tomorrow, and in order to get some decent vote feedback it would be good to clean up JIRA so that we have an accurate 2.0.x list people can vote on for issues they would like fixed in 2.0.8. I created a "Documentation" version so that technical issues wouldn't be polluted by documentation issues. I also created a "Reviewed Pending Version Assignment" where I put everything that's probably been looked at (probably not entirely true) so that anything coming in from now on in the unscheduled we can process. I think between all of us we can probably keep that empty most weeks by assigning a version, closing if duplicated, or closing due to being incomplete. Some simple things you can do if you have a few minutes to spare: - look in the reviewed pending version assignment and try to put the issue in 2.0.x or 2.1.x - pick your favorite component and look for duplicates - issues describing a remotely complicated problem without a sample project get close as incomplete - look at issues you've reported and check and see if they have been resolved - linking issues up that look similiar so we can close issues together if they are resolved. Even if we get rid of the complete cruft like already resolved, dupes, and incomplete issues that will greatly help. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscr
Re: JIRA Smackdown
On 15/06/2007, at 9:27 PM, Kenney Westerhof wrote: When I find an issue that's rather complex I usually describe how to reproduce it, but I lack the time to write sample projects, at least when reporting. When i get around to it I reproduce the issue and fix it in svn - I normally don't attach tests since I can commit in core, and i think that goes for more developers. If we're fixing it immediately - sure, because the sample goes into the tests. But if not, I think we need to hold ourselves to the same standards since sometimes they sit there for a year or two and you have no idea what they meant :) Anyway, the incomplete resolution is fine, but closing them will make them rather hard to find back. Maybe we could just assign these issues to the reporters instead, status to 'feedback' or 'incomplete', 'on hold' or whatever. Absolutely agree. We can't assign to user under the current set up (though maybe allowing assign to anyone is a good idea), but I think an addition of "need info" to the workflow is a good idea. In the future I'll try to attach the tests as I create the issue, though that'll take me 30 mins more and when I'm in time pressure I feel it's better to report the issue so it doesn't slip my mind, than to not do it at all because of the high overhead. Maybe assign it to yourself to either finish reporting or finish fixing? wdyt? Seems to make sense. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Smackdown
Hi, I'd like to ask that issues reported by PMC members and core developers get less strict reviews. When I find an issue that's rather complex I usually describe how to reproduce it, but I lack the time to write sample projects, at least when reporting. When i get around to it I reproduce the issue and fix it in svn - I normally don't attach tests since I can commit in core, and i think that goes for more developers. Anyway, the incomplete resolution is fine, but closing them will make them rather hard to find back. Maybe we could just assign these issues to the reporters instead, status to 'feedback' or 'incomplete', 'on hold' or whatever. In the future I'll try to attach the tests as I create the issue, though that'll take me 30 mins more and when I'm in time pressure I feel it's better to report the issue so it doesn't slip my mind, than to not do it at all because of the high overhead. wdyt? -- Kenney Jason van Zyl wrote: Hi, The 2.0.7 release will go out tomorrow, and in order to get some decent vote feedback it would be good to clean up JIRA so that we have an accurate 2.0.x list people can vote on for issues they would like fixed in 2.0.8. I created a "Documentation" version so that technical issues wouldn't be polluted by documentation issues. I also created a "Reviewed Pending Version Assignment" where I put everything that's probably been looked at (probably not entirely true) so that anything coming in from now on in the unscheduled we can process. I think between all of us we can probably keep that empty most weeks by assigning a version, closing if duplicated, or closing due to being incomplete. Some simple things you can do if you have a few minutes to spare: - look in the reviewed pending version assignment and try to put the issue in 2.0.x or 2.1.x - pick your favorite component and look for duplicates - issues describing a remotely complicated problem without a sample project get close as incomplete - look at issues you've reported and check and see if they have been resolved - linking issues up that look similiar so we can close issues together if they are resolved. Even if we get rid of the complete cruft like already resolved, dupes, and incomplete issues that will greatly help. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Smackdown
On 6/14/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: I created a "Documentation" version so that technical issues wouldn't be polluted by documentation issues. Documentation is neither a version nor pollution. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Smackdown
On 14 Jun 07, at 10:28 PM 14 Jun 07, Brett Porter wrote: Heh, my mail was trying to tell me something as it rejected a message asking about these at the same time this arrived :) MPA-90 and 91 came up to the top of my iGTD box today and I was going to work on them this afternoon - but noticed things had been changed. This sounds good to me, and I'll get started on the 'reviewed' bucket. If I understand you correctly, these aren't actually reviewed yet, and this bucket should go away over time (with things going straight into an expected roadmap, right?) So no new issues go in there, and we try and break it down, but get more vigilant on the unscheduled bucket. Yup. Just to keep an eye on incoming while we clean up. I strongly disagree with the Documentation 'version'. I've found it to be problematic, and the components should be sufficient. Just exclude those from the filter to get the technical issues. I understand we don't currently distribute and version the documentation, but I think we are all of the opinion now that we should, right? I've no problem keeping it for clean up purposes, as long as (again) no new things are going in there. I think the vast majority of those issue span versions, and the most commonly looked at view is the dashboard with versions. This is really just a deficiency with the dashboard but I want to see the technical issues. Maybe we can get filters to show as the default view but given the complexity in trying to change the way anything is viewed in JIRA I picked the version for documentation. So I'll continue by reviewing some jiras and documenting this. Thanks, Brett On 15/06/2007, at 3:18 PM, Jason van Zyl wrote: Hi, The 2.0.7 release will go out tomorrow, and in order to get some decent vote feedback it would be good to clean up JIRA so that we have an accurate 2.0.x list people can vote on for issues they would like fixed in 2.0.8. I created a "Documentation" version so that technical issues wouldn't be polluted by documentation issues. I also created a "Reviewed Pending Version Assignment" where I put everything that's probably been looked at (probably not entirely true) so that anything coming in from now on in the unscheduled we can process. I think between all of us we can probably keep that empty most weeks by assigning a version, closing if duplicated, or closing due to being incomplete. Some simple things you can do if you have a few minutes to spare: - look in the reviewed pending version assignment and try to put the issue in 2.0.x or 2.1.x - pick your favorite component and look for duplicates - issues describing a remotely complicated problem without a sample project get close as incomplete - look at issues you've reported and check and see if they have been resolved - linking issues up that look similiar so we can close issues together if they are resolved. Even if we get rid of the complete cruft like already resolved, dupes, and incomplete issues that will greatly help. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA Smackdown
Heh, my mail was trying to tell me something as it rejected a message asking about these at the same time this arrived :) MPA-90 and 91 came up to the top of my iGTD box today and I was going to work on them this afternoon - but noticed things had been changed. This sounds good to me, and I'll get started on the 'reviewed' bucket. If I understand you correctly, these aren't actually reviewed yet, and this bucket should go away over time (with things going straight into an expected roadmap, right?) So no new issues go in there, and we try and break it down, but get more vigilant on the unscheduled bucket. I strongly disagree with the Documentation 'version'. I've found it to be problematic, and the components should be sufficient. Just exclude those from the filter to get the technical issues. I understand we don't currently distribute and version the documentation, but I think we are all of the opinion now that we should, right? I've no problem keeping it for clean up purposes, as long as (again) no new things are going in there. So I'll continue by reviewing some jiras and documenting this. Thanks, Brett On 15/06/2007, at 3:18 PM, Jason van Zyl wrote: Hi, The 2.0.7 release will go out tomorrow, and in order to get some decent vote feedback it would be good to clean up JIRA so that we have an accurate 2.0.x list people can vote on for issues they would like fixed in 2.0.8. I created a "Documentation" version so that technical issues wouldn't be polluted by documentation issues. I also created a "Reviewed Pending Version Assignment" where I put everything that's probably been looked at (probably not entirely true) so that anything coming in from now on in the unscheduled we can process. I think between all of us we can probably keep that empty most weeks by assigning a version, closing if duplicated, or closing due to being incomplete. Some simple things you can do if you have a few minutes to spare: - look in the reviewed pending version assignment and try to put the issue in 2.0.x or 2.1.x - pick your favorite component and look for duplicates - issues describing a remotely complicated problem without a sample project get close as incomplete - look at issues you've reported and check and see if they have been resolved - linking issues up that look similiar so we can close issues together if they are resolved. Even if we get rid of the complete cruft like already resolved, dupes, and incomplete issues that will greatly help. Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
