Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of castagna.lists@googlemail.com
 designates 209.85.210.41 as permitted sender)
Message-ID: <4EBD192F.6000207@googlemail.com>
Date: Fri, 11 Nov 2011 04:46:39 -0800
From: Paolo Castagna <castagna.lists@googlemail.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: jena-dev@incubator.apache.org
Subject: Re: JIRA issues and "Fix Version/s"...
References: <4EBBE9FA.904@googlemail.com>	<4EBBEE6B.8050008@googlemail.com>
 <CAJjdaOGJ=emkUQhtQLP4rD8Qq7PdVZj-BURJRvfJKjARN55UXQ@mail.gmail.com>
 <4EBCF1F5.4060201@apache.org>
In-Reply-To: <4EBCF1F5.4060201@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Andy Seaborne wrote:
> On 10/11/11 22:52, Leo Simons wrote:
>>> What do you think?
>> Lots of things.
>>
>> For open source projects I prefer to not set fix versions at all until
>> an issue is actually fixed. When you do set it, match the version
>> number to the actual number in the associated artifact(s) that users
>> download, and nothing else. That way, the jira release notes are
>> accurate.
> 
> +1
> 
>> Similarly, I don't think due date is useful in our context.
>>
>> Jira is great for project planning and scheduling and tracking
>> commercial software delivery. But for community open source projects,
>> it is better not to measure or promise or schedule as precisely as you
>> do in the commercial environment. The dynamic is different.
>>
>> My advice would be not to focus too much on capturing intentions and
>> roadmaps and long-term plans in jira or in documentation. Discuss
>> plans on the mailing list, make sure you have consensus on the general
>> direction and goals, and then everybody works towards those goals as
>> they have time and energy available. Don't publish long term schedules
>> out to your user community, only announce things when they are
>> actually implemented.
> 
> +1
> 
> Actions speak louder than words.
> 
>> If you do want to do some kind of scheduling/metrics using jira,
>> there's a bunch of stuff you can look at beyond the roadmap. I'd
>> suggest an important one would be average age and resolution time of
>> bugs (and only bugs), and another one is average age and resolution
>> time for issues that have a patch submission, but that one is a bit
>> harder to do a report on.
>>
>> In other words, do things pretty much like jena has always done
>> them...but hey, you asked
> 
> +1
> 
> I see no point setting expectations (e.g. saying when things will be 
> done) without a mechanism to reflect costs and trade-offs.All that 
> happens is that there will be a growing pile of guilt.  At which point 
> either release get pushed out or expectations are not met.  Both are bad.

Ok.

Thank you Leo and Andy, you convinced me.

I've just removed all the forward looking "Fix Version/s" for the currently
open bugs. If I left any there for an open bug is a mistake and I'll fix it
when I find it.

I left "Fix Version/s" for the closed bugs.
Do you see value on those or you want me to remove them as well?
I still see there is some value on having a "Fix Version/s" field on
closed bugs, but if there isn't agreement on that I am going to remove
those as well.

Related to this... keeping a ChangeLog.txt file, such as ARQ for example:
http://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/trunk/ChangeLog.txt
is very useful (but it's also easy to forget to update it when an issue
is closed... it happened a couple of times or probably more to me...
I closed an issue and I forgot to update the ChangeLog.txt file).

Cheers,
Paolo

> 
>     Andy