On Mon, Sep 26, 2016 at 11:39 AM, Guillaume Delhumeau
<
guillaume.delhumeau(a)xwiki.com> wrote:
2016-09-23 12:57 GMT+02:00 Vincent Massol
<vincent(a)massol.net>et>:
> I agree with Edy’s answer.
>
> However, what Manuel is also saying (I think), is that by doing so, we
> don’t reward the reporter and we don’t incitate him/her to report more.
> Basically he’s found the problem and we’re saying that he just found a
> duplicate (this is what someone looking at JIRA without doing
archeology
on
the activity of the issues will think).
I don’t have the solution though.
In general, saying "thanks you" seems to be good practice :) It's good
for
issues, pull requests, etc... In this particular
case, we could simply
say:
"Thanks to this report, we have found the
cause of this problem which is
described in the issue ISSUE-1. As a consequence, we have closed this
current issue as a duplicate of ISSUE-1."
Any idea?
Thanks
-Vincent
I agree with the reasoning of Edy about "causes" and
"manifestations".
It's
already the way I am handling issues too.
However, I have noticed a
little
problem.
The issues closed as duplicates are never mentioned in the release notes.
It's because we don't set the "fix version" field for these issues. It
makes sense because we don't always know when the "cause" will be closed,
and it would be a pain to synchronize everything afterwards.
But it means that a user, who have experienced a bug but haven't followed
the jira issue, won't see in the release notes that her bug is solved.
Instead, she will see the "cause" bug without seeing its link to the
manifestation, except by manually browsing jira.
So it is a question of visibility. By reading the list of the issues, we
miss all the bugs that we consider as manifestations of an other one.
What do you think about this?
Sounds interesting, but it would only make sense, IMO, if we can automate
it, i.e. when updating the Fixed Version property of an issue, also update
it for all its duplicates, so that they are always in synch. We could
probably write some quick listener component/script to take care of this,
since on a quick Google search, the question does appear, but not a clear
result other than custom code.
Thanks,
Eduard
Thanks,
>
> > On 23 Sep 2016, at 12:46, Eduard Moraru <enygma2002(a)gmail.com>
wrote:
Hi, Manuel,
On Fri, Sep 23, 2016 at 11:55 AM, Manuel Smeria <manuel(a)xwiki.com>
wrote:
>
>> Hello Devs,
>>
>> I would like to propose a new best practice for the way we close
issues
> as
> >> Duplicate.
> >>
> >> As an example I've reported this issue:
> >>
http://jira.xwiki.org/browse/XWIKI-13728 which was later closed as
a
> >> Duplicate to
http://jira.xwiki.org/browse/XWIKI-13729.
> >>
> >> From my perspective, this is not correct since the issue I reported
is
> valid from an user's POV.
> I would have preferred that my issue was renamed and that developers
would
>> have added some technical information as a comment to it if they
wanted
> to
> >> do so.
> >> It just doesn't make any sense to me to close a perfectly valid
issue
as a
>> Duplicate just to create another one that has a more technically
correct
> >> summary and description.
> >>
> >> It also doesn't make sense to close the original issue as a
Duplicate
to a
> duplicate issue :) (pun intended)
> I see things like this: my issue's description is a use-case of the
issue
>> later reported by Edy, so if anything, Edy's issue should be closed
as a
>> Duplicate to mine and not the other way
around.
>>
>
> As you have explained it yourself, the issue you have created is a
> *usecase*, a *manifestation* of a real problem. That is why we have
> identified the real problem (the "cause") and I have created an issue
to
> > specifically address it and fix it, linking your manifestation issue
to
> the
> > actual problem that caused it. A developer will work to fix the
actual
>
problem, and not its many manifestations. This way, in the issues
tracker
> > (jira), we will have recorded both the actual problem and one (or
many)
> of
> > its manifestations so that, when a user (or even a dev) does a search
> for a
> > manifestation, it will be easy to find the actual problem he is
having
> > (manifestation), but also the real
problem that caused it (and when
it
was
> fixed).
>
> If we were to modify the manifestation issue or simply add a comment,
we
> would lose all the above mentioned
information, which would not be
ideal,
> > so, instead, even if it breaks a bit the chronology of things, we
mark
> the
> > manifestation issue as a duplicate of the "cause" issue, which makes
> > perfect sense when you look at it this way. Fixing the cause will
> > automatically fix all reported manifestations which were clearly
marked
> as
> > duplicates of the cause.
> >
> > So, in practice, when there are more opened issues that are clearly
> > duplicates, the one with the most information and that best
identifies
the
> real source of the problem is left opened, while all the others which
are
> > addressing manifestations get closed as duplicates of the previous
one,
> > even if that issue happened to be
reported later in the chronology.
> >
> >
> >>
> >> One scenario where I think issues dated previously should be closed
as
>>
Duplicate is if the new issue has already been fixed. For example
when a
> >> Developer doesn't notice an older issue and starts working on the
new
one
>> instead of closing the new one as a Duplicate and work on the older
one.
> >> There might be more, feel free to add them to this thread.
> >>
> >
> > Yes, we do that already.
> >
> >
> >>
> >> So, what I propose is that we don't close original issues as
Duplicate
> >> unless it falls into the category
previously described or some other
> >> exceptions that I can't think of now and might occur.
> >>
> >
> > As I mentioned, the "original" issue is less valuable both to users
and
to
devs as an identified "cause" issue,
which really needs fixing.
"Original"
issues still offer value to users when searching
or reading release
notes,
but that`s as far as it can go.
Does this make sense?
Thanks,
Eduard
>
> Thanks,
> Manuel
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
>
http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the
XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the