On 10/03/2012 04:00 PM, Eduard Moraru wrote:
On Wed, Oct 3, 2012 at 9:23 PM, Vincent Massol
<vincent(a)massol.net> wrote:
On Oct 3, 2012, at 6:49 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
I agree with Edy. For me "Future" means
"reviewed and not planned for
any time soon".
The problem is not the meaning; we understand why we introduced it...
Can you explain to me how you've been using it?
If you check current stats you'll see some marked "future" and the vast
majority not scheduled. The reason is that we're not using it and honestly
I have no clue how to use it properly because once you mark one as future
what do you do with it?
I imagined that, before Roadmap meetings for the next release/cycle, you
go trough the (publicly available) list of issues marked as 'Future' and
consider them to be high priority since they are in the "queue". If you did
not do that until now and do not plan to do it, then sure, it's useless.
How else do you/we keep track of important issues across time/versions? I
don`t imagine that a personal list would be the solution for the whole
(public) open source project.
The current approach (with the 'Future' marker) still seems to me to be an
uncomplicated solution to this problem. I don`t even feel the need for the
NEW and OPEN markers as Sergiu suggested, since we have "In Progress" and
"Future" to differentiate between actively or "passively" working on
an
issue. Also, there is the "Assigned" field that represents the fact that a
*committer* is engaged to fix the issue (can be at his own will) and there
is the 'Future' version that represents that the *community/project* is
engaged in fixing the issue as soon as possible, even if there is currently
no assigned committer. Without such a marker, our reporters might get a
sense of abandonment if they see no activity on their issue.
Anyway, that's all I had to say on the matter. Maybe your experience with
issue/roadmap management is more likely to be correct compared with my
above judgement.
Almost any solution for the problem will work, better or worse, but in
order for such a solution to work it requires sticking to some rules.
The problem isn't that much that the current solution is bad. We haven't
been applying the rule consistently, and there are issues marked as
Future that we're not putting any effort into, and there are issues that
we're considering to have priority but aren't marked in any way. In
short, we're terrible at following this rule, so we're just proposing to
remove it since it doesn't bring any _perceived_, _real_ value.
The alternative is to decide that we do want to follow this rule, like
we do with other stricter rules, but this will require time and
discipline from all the committers.
Thanks,
Eduard
> And since we don't have more visibility than the current release there's
> no way to decide further than that if it's planned for the current release
> then we set the fixfor for the current release...
>
> Thanks
> -Vincent
>
>> Thanks,
>> Marius
>>
>> On Wed, Oct 3, 2012 at 7:29 PM, Eduard Moraru <enygma2002(a)gmail.com>
> wrote:
>>> I don`t know, for me it`s good to be able to see which issues are in our
>>> "queue", besides the great sea of not yet processed issues :) I
agree
> that
>>> we don`t use it much, but I would not go as far as to remove it, so I`m
> -0.
>>>
>>> What happens to issues we discuss/tackle, but don`t manage to
>>> finish/implement them on time? Do we throw them back into the sea
> (instead
>>> of putting them aside for 'Future')?
>>>
>>> Thanks,
>>> Eduard
>>>
>>> On Wed, Oct 3, 2012 at 6:44 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
>>>
>>>> Hi devs,
>>>>
>>>> It seems we've never really used the "future' version in
jira. I'd like
>>>> like to propose to remove it.
>>>>
>>>> The idea was that issues that had been reviewed and marked for later
> were
>>>> supposed to use "future" but in practice we are not doing it.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks
>>>> -Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu/