Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (herse.apache.org: domain of craigmcc@gmail.com designates
 64.233.184.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=aeRSAN0wS0dEGM66yBN7BpxoxHWNeaqly2edvY4NSsDfysCbErfUlsT/hkhnDDU/Cjehc8BSvbcdyOgsY43ZxmFP/WklSrIgVsFMmsjythJYvhTGaH3QYgsMJRr6YUGShBCs45DTnPAA4Piu5g2T1sblOW8EIN5HeIqX4wnwCWc=
Message-ID: <f8b39ace0702191314hde9cef7pcc978a1081edfd41@mail.gmail.com>
Date: Mon, 19 Feb 2007 13:14:03 -0800
From: "Craig McClanahan" <craigmcc@apache.org>
Sender: craigmcc@gmail.com
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: s1 - 1.x "Future" Issues
In-Reply-To: <b9e663070702191303h5954edf5xd0ad9b2dd70453c5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <45D63C5C.7060201@apache.org>
	 <8b3ce3790702181655g7a8f2d07w7127c4be2a6d5fbc@mail.gmail.com>
	 <45D91367.2090909@apache.org>
	 <8b3ce3790702190523n365c7ef9x240604cb703d83fa@mail.gmail.com>
	 <16d6c6200702190951p4152d3bel1fd43ac38fb2dbb7@mail.gmail.com>
	 <b9e663070702191139v1149852ah2c639d2b1cac15fb@mail.gmail.com>
	 <16d6c6200702191154g7381c2a4k6c812dc3ee345d15@mail.gmail.com>
	 <b9e663070702191303h5954edf5xd0ad9b2dd70453c5@mail.gmail.com>

On 2/19/07, Paul Benedict <pbenedict@apache.org> wrote:
> The purpose of the Road Map is to assign issues to a release. Since "Future"
> is not a version or a release -- but just a grouping of issues for the
> "future" -- it has little use, and the way we use it tells me we're using
> the Road Map wrongly. Now, I believe that's the case, but I am not going to
> fight this issue too strongly because it is not critical to anything. I'll
> go back and look at the archives, but there's nothing wrong with
> re-examining past decisions. I haven't seen other JIRA projects slating
> things into a "Future" version -- and probably because it's not a version.
>
> Paul
>

For what it's worth, we're using a "TBD" version identifier in Shale
for the same concept that "Future" seems intended for in Struts ... to
track things that are real issues (either bugs or RFEs), but for which
no one has yet stepped up and said "I want to deal with this for a
particular release".  This is different from "Unscheduled" (the
default state when a new issue is created), because it has to be
looked at and assigned, instead of being closed as "Will Not Fix" or
"Not A Problem" immediately.

An issue tracking system should (IMHO) be useful for more than just
roadmaps and release notes.  Let's say you hear from an enthusiastic
user who wants to contribute to the project, but doesn't have a
specific idea on where to start.  Where do you send him or her to get
some ideas?  For Shale, I've got a simple answer[1].  Wouldn't Struts
like to have the same ability?

Craig

[1] https://issues.apache.org/struts/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10130&fixfor=21773

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org