23 Sep
2016
23 Sep
'16
10:55 a.m.
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.
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.
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.
Thanks,
Manuel
23 Sep
23 Sep
12:46 p.m.
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
12:57 p.m.
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.
Any idea?
Thanks
-Vincent
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
1:06 p.m.
Hi,
On Fri, Sep 23, 2016 at 1:57 PM, Vincent Massol <vincent(a)massol.net> wrote:
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.
I`m not sure. I understand what you`re saying, but I`m wondering if this is
not a problem of perspective.
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).
That would be totally superficial, IMO. It is easy to look at the dates
when the issue was reported and see that, even if it is marked as a
duplicate, it was clearly reported before the real "cause" was found (like
we have in our current case). Nobody is taking any credit from the reporter
in any way. The reality of things is that the reported has reported a
manifestation which eventually lead to finding the cause. Looking at it
just by whose name is on the issue marked with Fixed does not really tell
you much.
Yes, this can impact reports or dashboards, but those reports can never
reflect what actually goes on in practice and if you are really interested
in that information, it`s very easy to trace it all the way (i.e. do
"archeology" :) ).
Make no mistake, we *do* appreciate every reported issue and we *do* need
more help on pointing us to places where our code does not do what it is
supposed to. We`ll eventually figure out the cause of the problem, we don`t
expect anyone to point us to that directly. That would spoil all the fun :)
Thanks,
Eduard
I don’t have the solution though.
Any idea?
Thanks
-Vincent
the
to
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 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 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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 
26 Sep
26 Sep
10:39 a.m.
2016-09-23 12:57 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
the
to
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
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?
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 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 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
11:55 a.m.
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>:
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
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?
Thanks,
issues
as a
tracker
we
are
one.
to
--
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
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 as
wanted
> 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 to
correct
> 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 >
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 >> 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 (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, > 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 > 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 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 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
11:59 a.m.
2016-09-26 11:55 GMT+02:00 Eduard Moraru <enygma2002(a)gmail.com>om>:
On Mon, Sep 26, 2016 at 11:39 AM, Guillaume Delhumeau
<
guillaume.delhumeau(a)xwiki.com> wrote:
That's an interesting lead.
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
for
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
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."
It's
Any idea?
Thanks
-Vincent
I agree with the reasoning of Edy about "causes" and
"manifestations". 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
issues
> as
> >> Duplicate.
> >>
> >> As an example I've reported this issue:
> >> http://jira.xwiki.org/browse/XWIKI-13728 which was later closed as
a
wanted
> to
> >> do so.
> >> It just doesn't make any sense to me to close a perfectly valid
issue
Duplicate
to
many)
mark
one,
new
Duplicate
_______________________________________________
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
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 > >> 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 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 to a
as 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 >> 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 > 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 > 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 > 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 > > 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
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 > >> 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
--
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 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
8:28 p.m.
On Fri, Sep 23, 2016 at 1:46 PM, 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).
The users will always report the manifestation of a problem. They report
what they see. They don't investigate. Following your practice would mean
closing all user-reported issues as duplicate once the developer finds the
real cause. I don't think this is right. Moreover, AFAIK the best practice
when reporting issues, even for developers, is to describe the
manifestation in the issue title. What's important is to understand how the
users are affected. The developer can look for details (like the cause of
the problem) in the comments.
Thanks,
Marius
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
27 Sep
27 Sep
11:38 a.m.
Hi,
Marius summed up pretty good exactly what I'm thinking.
Users are not usually technical, so they will report the bug as they see
it: the button doesn't work, the color is grey instead of blue, etc.
If the developer that investigates the issue finds the cause for it, he can
rephrase it using technical words inside the Git commit or even inside a
Jira comment.
AFAIK the search function in Jira also works for comments.
Thanks,
Manuel
On Mon, Sep 26, 2016 at 9:28 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
On Fri, Sep 23, 2016 at 1:46 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
as
to
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 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).
The users will always report the manifestation of a problem. They report
what they see. They don't investigate. Following your practice would mean
closing all user-reported issues as duplicate once the developer finds the
real cause. I don't think this is right. Moreover, AFAIK the best practice
when reporting issues, even for developers, is to describe the
manifestation in the issue title. What's important is to understand how the
users are affected. The developer can look for details (like the cause of
the problem) in the comments.
Thanks,
Marius
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 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
11:42 a.m.
On 27 Sep 2016, at 11:38, Manuel Smeria
<manuel(a)xwiki.com> wrote:
Hi,
Marius summed up pretty good exactly what I'm thinking.
Users are not usually technical, so they will report the bug as they see
it: the button doesn't work, the color is grey instead of blue, etc.
If the developer that investigates the issue finds the cause for it, he can
rephrase it using technical words inside the Git commit or even inside a
Jira comment.
AFAIK the search function in Jira also works for comments.
So this would mean, not changing the title of the issue. Because if you change the title
you also need to change the description or you have a sync issue with a description not
matching the title (this was the case for the issue that led to this discussion).
When you search in jira (I use JIRA client), it highlight the search terms in the title
for example, giving more weight to the title.
Having 2 issues makes it twice as likely to find the issue you’re looking for (from a user
pov or from a tech pov).
But yes this could be considered minor and we could decide to not touch the title nor the
description and simply add some comment explaining the real cause.
Thanks
-Vincent
Thanks,
Manuel
On Mon, Sep 26, 2016 at 9:28 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
> On Fri, Sep 23, 2016 at 1:46 PM, 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).
>>
>
> The users will always report the manifestation of a problem. They report
> what they see. They don't investigate. Following your practice would mean
> closing all user-reported issues as duplicate once the developer finds the
> real cause. I don't think this is right. Moreover, AFAIK the best practice
> when reporting issues, even for developers, is to describe the
> manifestation in the issue title. What's important is to understand how the
> users are affected. The developer can look for details (like the cause of
> the problem) in the comments.
>
> Thanks,
> Marius
>
>
>>
>> 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
12:01 p.m.
Hello,
Yes, don't change the title.
For example let's take http://jira.xwiki.org/browse/XWIKI-13468
The title for it is "The query used by the Document Tree to get the nested
child pages is very costly".
From my pov it could have easily been "Document
Tree is very slow when
expanding children nodes" if I would have reported it.
I also think it wouldn't have made a difference whether the title was
technical or not, since the fix would be the same.
It's only a matter of the person that is reporting the issue, whether he's
seeing the issue as a Developer or not, but the issue is the same one.
There are not 2 issues, so it doesn't make sense to create another issue
just to close it later as Duplicate.
Thanks,
Manuel
On Tue, Sep 27, 2016 at 12:42 PM, Vincent Massol <vincent(a)massol.net> wrote:
On 27 Sep 2016, at 11:38, Manuel Smeria
<manuel(a)xwiki.com> wrote:
Hi,
Marius summed up pretty good exactly what I'm thinking.
Users are not usually technical, so they will report the bug as they see
it: the button doesn't work, the color is grey instead of blue, etc.
If the developer that investigates the issue finds the cause for it, he
can
rephrase it using technical words inside the Git
commit or even inside a
Jira comment.
AFAIK the search function in Jira also works for comments.
So this would mean, not changing the title of the issue. Because if you
change the title you also need to change the description or you have a sync
issue with a description not matching the title (this was the case for the
issue that led to this discussion).
When you search in jira (I use JIRA client), it highlight the search terms
in the title for example, giving more weight to the title.
Having 2 issues makes it twice as likely to find the issue you’re looking
for (from a user pov or from a tech pov).
But yes this could be considered minor and we could decide to not touch
the title nor the description and simply add some comment explaining the
real cause.
Thanks
-Vincent
Thanks,
Manuel
On Mon, Sep 26, 2016 at 9:28 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
> On Fri, Sep 23, 2016 at 1:46 PM, 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).
>>
>
> The users will always report the manifestation of a problem. They report
> what they see. They don't investigate. Following your practice would
mean
> closing all user-reported issues as duplicate
once the developer finds
the
> real cause. I don't think this is right.
Moreover, AFAIK the best
practice
> when reporting issues, even for developers,
is to describe the
> manifestation in the issue title. What's important is to understand how
the
> users are affected. The developer can look
for details (like the cause
of
> the problem) in the comments.
>
> Thanks,
> Marius
>
>
>>
>> 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
12:01 p.m.
I guess it's a case by case thing. For example you cannot not change a
title like "It not working" or "Massive error on screen", etc.
I don't think we can reach a conclusion on this topic. Some issues are
describing the cause, while other are describing the effect. Some causes
could have multiple effects. Sometimes you cannot find the issue that was
reported before, some issue might be closed not by the book, etc. Since we
document in written the new functionality we add in the Release Notes, any
issue we have will be mainly dedicated to devs, not end-users. Having
clearer issue IMO is nicer (since cuts a next step to read all the
description and the comments), but sure, the language needs to be
moderately technical and be understood by the majority.
Thanks,
Caty
On Tue, Sep 27, 2016 at 12:42 PM, Vincent Massol <vincent(a)massol.net> wrote:
On 27 Sep 2016, at 11:38, Manuel Smeria
<manuel(a)xwiki.com> wrote:
Hi,
Marius summed up pretty good exactly what I'm thinking.
Users are not usually technical, so they will report the bug as they see
it: the button doesn't work, the color is grey instead of blue, etc.
If the developer that investigates the issue finds the cause for it, he
can
rephrase it using technical words inside the Git
commit or even inside a
Jira comment.
AFAIK the search function in Jira also works for comments.
So this would mean, not changing the title of the issue. Because if you
change the title you also need to change the description or you have a sync
issue with a description not matching the title (this was the case for the
issue that led to this discussion).
When you search in jira (I use JIRA client), it highlight the search terms
in the title for example, giving more weight to the title.
Having 2 issues makes it twice as likely to find the issue you’re looking
for (from a user pov or from a tech pov).
But yes this could be considered minor and we could decide to not touch
the title nor the description and simply add some comment explaining the
real cause.
Thanks
-Vincent
Thanks,
Manuel
On Mon, Sep 26, 2016 at 9:28 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
> On Fri, Sep 23, 2016 at 1:46 PM, 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).
>>
>
> The users will always report the manifestation of a problem. They report
> what they see. They don't investigate. Following your practice would
mean
> closing all user-reported issues as duplicate
once the developer finds
the
> real cause. I don't think this is right.
Moreover, AFAIK the best
practice
> when reporting issues, even for developers,
is to describe the
> manifestation in the issue title. What's important is to understand how
the
> users are affected. The developer can look
for details (like the cause
of
> the problem) in the comments.
>
> Thanks,
> Marius
>
>
>>
>> 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
25 Jan
25 Jan
1:07 p.m.
Hello again,
I'm reviving this thread since I found some Documentation links from
Mozilla which might help:
https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla/What_to_do_and_wh…
https://developer.mozilla.org/en-US/docs/Screening_duplicate_bugs#Which_is_…
Quote:
"Other things being equal, newer bugs should be made DUPLICATES of older
bugs, but, more importantly, whichever bug is further along in the process
of getting fixed should *not* be made a duplicate. Signs that progess has
been made include:
[...]
* the bug has been analyzed by developers
* the bug report has a explanation of how to reliably reproduce the bug
and/or it has a simplified testcase"
The scenarios I'm talking about and also the one of
http://jira.xwiki.org/browse/XWIKI-13728 are perfectly described by the
previous quote.
Maybe we can also make a decision about this topic and make some changes to
the current procedure?
Thanks,
Manuel
On Tue, Sep 27, 2016 at 1:01 PM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
I guess it's a case by case thing. For example you
cannot not change a
title like "It not working" or "Massive error on screen", etc.
I don't think we can reach a conclusion on this topic. Some issues are
describing the cause, while other are describing the effect. Some causes
could have multiple effects. Sometimes you cannot find the issue that was
reported before, some issue might be closed not by the book, etc. Since we
document in written the new functionality we add in the Release Notes, any
issue we have will be mainly dedicated to devs, not end-users. Having
clearer issue IMO is nicer (since cuts a next step to read all the
description and the comments), but sure, the language needs to be
moderately technical and be understood by the majority.
Thanks,
Caty
On Tue, Sep 27, 2016 at 12:42 PM, Vincent Massol <vincent(a)massol.net>
wrote:
a
sync
issue
to
many)
how
one,
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> On 27 Sep 2016, at 11:38, Manuel Smeria <manuel(a)xwiki.com> wrote:
>
> Hi,
>
> Marius summed up pretty good exactly what I'm thinking.
> Users are not usually technical, so they will report the bug as they
see
it: the
button doesn't work, the color is grey instead of blue, etc.
If the developer that investigates the issue finds the cause for it, he
can
> rephrase it using technical words inside the Git commit or even inside Jira
comment.
AFAIK the search function in Jira also works for comments.
So this would mean, not changing the title of the issue. Because if you
change the title you also need to change the description or you have a issue with a description not matching the title
(this was the case for
the
issue that led to this discussion).
When you search in jira (I use JIRA client), it highlight the search
terms
in the title for example, giving more weight to
the title.
Having 2 issues makes it twice as likely to find the issue you’re looking
for (from a user pov or from a tech pov).
But yes this could be considered minor and we could decide to not touch
the title nor the description and simply add some comment explaining the
real cause.
Thanks
-Vincent
a
Thanks,
Manuel
On Mon, Sep 26, 2016 at 9:28 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
> On Fri, Sep 23, 2016 at 1:46 PM, 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
>>>> 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
>> 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 >> 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 >> 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).
>>>
>>
>> The users will always report the manifestation of a problem. They
report
> what
they see. They don't investigate. Following your practice would
mean
> closing all user-reported issues as duplicate
once the developer finds
the
> real cause. I don't think this is right.
Moreover, AFAIK the best
practice
>> when reporting issues, even for developers, is to describe the
>> manifestation in the issue title. What's important is to understand the
mark
> users are affected. The developer can look
for details (like the cause
of
> the problem) in the comments.
>
> Thanks,
> Marius
>
>
>>
>> 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 >> 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 >>> 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
2:04 p.m.
You forgot to also quote the following from the same resource [1] you`ve
referenced:
"In general newer bugs should be marked as DUPLICATEs of older bugs, except
when the newer bug contains more information (bug description clearer,
patch already attached, lots of people already CC'ed, etc.)."
Thanks,
Eduard
----------
[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla/What_to_do_and_wh…
On Wed, Jan 25, 2017 at 2:07 PM, Manuel Smeria <manuel(a)xwiki.com> wrote:
Hello again,
I'm reviving this thread since I found some Documentation links from
Mozilla which might help:
https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla/
What_to_do_and_what_not_to_do_in_Bugzilla#Resolving_bugs_as_DUPLICATE
https://developer.mozilla.org/en-US/docs/Screening_
duplicate_bugs#Which_is_the_Duplicate
Quote:
"Other things being equal, newer bugs should be made DUPLICATES of older
bugs, but, more importantly, whichever bug is further along in the process
of getting fixed should *not* be made a duplicate. Signs that progess has
been made include:
[...]
* the bug has been analyzed by developers
* the bug report has a explanation of how to reliably reproduce the bug
and/or it has a simplified testcase"
The scenarios I'm talking about and also the one of
http://jira.xwiki.org/browse/XWIKI-13728 are perfectly described by the
previous quote.
Maybe we can also make a decision about this topic and make some changes to
the current procedure?
Thanks,
Manuel
On Tue, Sep 27, 2016 at 1:01 PM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
issue
the
finds
cause
makes
which
closed
other
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
I guess it's a case by case thing. For
example you cannot not change a
title like "It not working" or "Massive error on screen", etc.
I don't think we can reach a conclusion on this topic. Some issues are
describing the cause, while other are describing the effect. Some causes
could have multiple effects. Sometimes you cannot find the issue that was
reported before, some issue might be closed not by the book, etc. Since
we
document in written the new functionality we add
in the Release Notes,
any
issue we have will be mainly dedicated to devs,
not end-users. Having
clearer issue IMO is nicer (since cuts a next step to read all the
description and the comments), but sure, the language needs to be
moderately technical and be understood by the majority.
Thanks,
Caty
On Tue, Sep 27, 2016 at 12:42 PM, Vincent Massol <vincent(a)massol.net>
wrote:
he
> On 27 Sep 2016, at 11:38, Manuel Smeria <manuel(a)xwiki.com> wrote:
>
> Hi,
>
> Marius summed up pretty good exactly what I'm thinking.
> Users are not usually technical, so they will report the bug as they
see
> > it: the button doesn't work, the color is grey instead of blue, etc.
> > If the developer that investigates the issue finds the cause for it, > can
> > rephrase it using technical words inside the Git commit or even
inside
a
sync
looking
Jira
comment.
AFAIK the search function in Jira also works for comments.
So this would mean, not changing the title of the issue. Because if you
change the title you also need to change the description or you have a issue with a description not matching the title
(this was the case for
the
issue that led to this discussion).
When you search in jira (I use JIRA client), it highlight the search
terms
> in the title for example, giving more weight to the title.
>
> Having 2 issues makes it twice as likely to find the issue you’re > for (from a user pov or from a tech pov).
>
> But yes this could be considered minor and we could decide to not touch
> the title nor the description and simply add some comment explaining
the
> real cause.
>
> Thanks
> -Vincent
>
> > Thanks,
> > Manuel
> >
> > On Mon, Sep 26, 2016 at 9:28 PM, Marius Dumitru Florea <
> > mariusdumitru.florea(a)xwiki.com> wrote:
> >
> >> On Fri, Sep 23, 2016 at 1:46 PM, 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
>> 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
> >> 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
many)
> >> of
> >>> its manifestations so that, when a user (or even a dev) does a
search
>> 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 >>
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).
>>>
>>
>> The users will always report the manifestation of a problem. They
report
> >> what they see. They don't investigate. Following your practice would
> mean
> >> closing all user-reported issues as duplicate once the developer the
how
> the
> >> users are affected. The developer can look for details (like the > real cause. I don't think this is right.
Moreover, AFAIK the best
practice
>> when reporting issues, even for developers, is to describe the
>> manifestation in the issue title. What's important is to understand > of
> >> the problem) in the comments.
> >>
> >> Thanks,
> >> Marius
> >>
> >>
> >>>
> >>> If we were to modify the manifestation issue or simply add a
comment,
we
mark
> >> the
> >>> manifestation issue as a duplicate of the "cause" issue,
which >> 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
>>> 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 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 as
older
>>>> 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
>>
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
>>>> 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
2:07 p.m.
New subject: [xwiki-devs] [Proposal] New Best Practice for closing issues as Duplicate
On 25 Jan 2017, at 14:04, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
You forgot to also quote the following from the same resource [1] you`ve
referenced:
"In general newer bugs should be marked as DUPLICATEs of older bugs, except
when the newer bug contains more information (bug description clearer,
patch already attached, lots of people already CC'ed, etc.).”
Yes we could simply link to that page in our best practice, i.e. link it from somewhere in
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices
-Vincent
Thanks,
Eduard
----------
[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla/What_to_do_and_wh…
On Wed, Jan 25, 2017 at 2:07 PM, Manuel Smeria <manuel(a)xwiki.com> wrote:
> Hello again,
>
> I'm reviving this thread since I found some Documentation links from
> Mozilla which might help:
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla/
> What_to_do_and_what_not_to_do_in_Bugzilla#Resolving_bugs_as_DUPLICATE
> https://developer.mozilla.org/en-US/docs/Screening_
> duplicate_bugs#Which_is_the_Duplicate
>
> Quote:
> "Other things being equal, newer bugs should be made DUPLICATES of older
> bugs, but, more importantly, whichever bug is further along in the process
> of getting fixed should *not* be made a duplicate. Signs that progess has
> been made include:
> [...]
> * the bug has been analyzed by developers
> * the bug report has a explanation of how to reliably reproduce the bug
> and/or it has a simplified testcase"
>
> The scenarios I'm talking about and also the one of
> http://jira.xwiki.org/browse/XWIKI-13728 are perfectly described by the
> previous quote.
> Maybe we can also make a decision about this topic and make some changes to
> the current procedure?
>
> Thanks,
> Manuel
>
> On Tue, Sep 27, 2016 at 1:01 PM, Ecaterina Moraru (Valica) <
> valicac(a)gmail.com> wrote:
>
>> I guess it's a case by case thing. For example you cannot not change a
>> title like "It not working" or "Massive error on screen",
etc.
>>
>> I don't think we can reach a conclusion on this topic. Some issues are
>> describing the cause, while other are describing the effect. Some causes
>> could have multiple effects. Sometimes you cannot find the issue that was
>> reported before, some issue might be closed not by the book, etc. Since
> we
>> document in written the new functionality we add in the Release Notes,
> any
>> issue we have will be mainly dedicated to devs, not end-users. Having
>> clearer issue IMO is nicer (since cuts a next step to read all the
>> description and the comments), but sure, the language needs to be
>> moderately technical and be understood by the majority.
>>
>> Thanks,
>> Caty
>>
>> On Tue, Sep 27, 2016 at 12:42 PM, Vincent Massol <vincent(a)massol.net>
>> wrote:
>>
>>>
>>>> On 27 Sep 2016, at 11:38, Manuel Smeria <manuel(a)xwiki.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Marius summed up pretty good exactly what I'm thinking.
>>>> Users are not usually technical, so they will report the bug as they
>> see
>>>> it: the button doesn't work, the color is grey instead of blue, etc.
>>>> If the developer that investigates the issue finds the cause for it,
> he
>>> can
>>>> rephrase it using technical words inside the Git commit or even
> inside
>> a
>>>> Jira comment.
>>>> AFAIK the search function in Jira also works for comments.
>>>
>>> So this would mean, not changing the title of the issue. Because if you
>>> change the title you also need to change the description or you have a
>> sync
>>> issue with a description not matching the title (this was the case for
>> the
>>> issue that led to this discussion).
>>>
>>> When you search in jira (I use JIRA client), it highlight the search
>> terms
>>> in the title for example, giving more weight to the title.
>>>
>>> Having 2 issues makes it twice as likely to find the issue you’re
> looking
>>> for (from a user pov or from a tech pov).
>>>
>>> But yes this could be considered minor and we could decide to not touch
>>> the title nor the description and simply add some comment explaining
> the
>>> real cause.
>>>
>>> Thanks
>>> -Vincent
>>>
>>>> Thanks,
>>>> Manuel
>>>>
>>>> On Mon, Sep 26, 2016 at 9:28 PM, Marius Dumitru Florea <
>>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>>
>>>>> On Fri, Sep 23, 2016 at 1:46 PM, 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).
>>>>>>
>>>>>
>>>>> The users will always report the manifestation of a problem. They
>> report
>>>>> what they see. They don't investigate. Following your practice
would
>>> mean
>>>>> closing all user-reported issues as duplicate once the developer
> finds
>>> the
>>>>> real cause. I don't think this is right. Moreover, AFAIK the
best
>>> practice
>>>>> when reporting issues, even for developers, is to describe the
>>>>> manifestation in the issue title. What's important is to
understand
>> how
>>> the
>>>>> users are affected. The developer can look for details (like the
> cause
>>> of
>>>>> the problem) in the comments.
>>>>>
>>>>> Thanks,
>>>>> Marius
>>>>>
>>>>>
>>>>>>
>>>>>> 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
>>
>
2:06 p.m.
New subject: [xwiki-devs] [Proposal] New Best Practice for closing issues as Duplicate
Hi Manuel,
On 25 Jan 2017, at 13:07, Manuel Smeria
<manuel(a)xwiki.com> wrote:
Hello again,
I'm reviving this thread since I found some Documentation links from
Mozilla which might help:
https://developer.mozilla.org/en-US/docs/Mozilla/Bugzilla/What_to_do_and_wh…
https://developer.mozilla.org/en-US/docs/Screening_duplicate_bugs#Which_is_…
Quote:
"Other things being equal, newer bugs should be made DUPLICATES of older
bugs, but, more importantly, whichever bug is further along in the process
of getting fixed should *not* be made a duplicate. Signs that progess has
been made include:
[...]
* the bug has been analyzed by developers
* the bug report has a explanation of how to reliably reproduce the bug
and/or it has a simplified testcase"
The scenarios I'm talking about and also the one of
http://jira.xwiki.org/browse/XWIKI-13728 are perfectly described by the
previous quote.
Maybe we can also make a decision about this topic and make some changes to
the current procedure?
That sounds fine to me as a guideline/best practice. Of course we might still make mistake
but we can fix them. Even for XWIKI-13728 if you care strongly, we could still swap the
fixed/duplicate (even though the commit is done against one issue).
Thanks
-Vincent
Thanks,
Manuel
On Tue, Sep 27, 2016 at 1:01 PM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
> I guess it's a case by case thing. For example you cannot not change a
> title like "It not working" or "Massive error on screen", etc.
>
> I don't think we can reach a conclusion on this topic. Some issues are
> describing the cause, while other are describing the effect. Some causes
> could have multiple effects. Sometimes you cannot find the issue that was
> reported before, some issue might be closed not by the book, etc. Since we
> document in written the new functionality we add in the Release Notes, any
> issue we have will be mainly dedicated to devs, not end-users. Having
> clearer issue IMO is nicer (since cuts a next step to read all the
> description and the comments), but sure, the language needs to be
> moderately technical and be understood by the majority.
>
> Thanks,
> Caty
>
> On Tue, Sep 27, 2016 at 12:42 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
>
>>
>>> On 27 Sep 2016, at 11:38, Manuel Smeria <manuel(a)xwiki.com> wrote:
>>>
>>> Hi,
>>>
>>> Marius summed up pretty good exactly what I'm thinking.
>>> Users are not usually technical, so they will report the bug as they
> see
>>> it: the button doesn't work, the color is grey instead of blue, etc.
>>> If the developer that investigates the issue finds the cause for it, he
>> can
>>> rephrase it using technical words inside the Git commit or even inside
> a
>>> Jira comment.
>>> AFAIK the search function in Jira also works for comments.
>>
>> So this would mean, not changing the title of the issue. Because if you
>> change the title you also need to change the description or you have a
> sync
>> issue with a description not matching the title (this was the case for
> the
>> issue that led to this discussion).
>>
>> When you search in jira (I use JIRA client), it highlight the search
> terms
>> in the title for example, giving more weight to the title.
>>
>> Having 2 issues makes it twice as likely to find the issue you’re looking
>> for (from a user pov or from a tech pov).
>>
>> But yes this could be considered minor and we could decide to not touch
>> the title nor the description and simply add some comment explaining the
>> real cause.
>>
>> Thanks
>> -Vincent
>>
>>> Thanks,
>>> Manuel
>>>
>>> On Mon, Sep 26, 2016 at 9:28 PM, Marius Dumitru Florea <
>>> mariusdumitru.florea(a)xwiki.com> wrote:
>>>
>>>> On Fri, Sep 23, 2016 at 1:46 PM, 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).
>>>>>
>>>>
>>>> The users will always report the manifestation of a problem. They
> report
>>>> what they see. They don't investigate. Following your practice would
>> mean
>>>> closing all user-reported issues as duplicate once the developer finds
>> the
>>>> real cause. I don't think this is right. Moreover, AFAIK the best
>> practice
>>>> when reporting issues, even for developers, is to describe the
>>>> manifestation in the issue title. What's important is to understand
> how
>> the
>>>> users are affected. The developer can look for details (like the cause
>> of
>>>> the problem) in the comments.
>>>>
>>>> Thanks,
>>>> Marius
>>>>
>>>>
>>>>>
>>>>> 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
23 Sep
23 Sep
12:57 p.m.
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)
Said differently: Does it make sense to close the "cause" as a duplicate of
one specific "manifestation" (e.g. occurring in application A), and all the
other various manifestations (in applications B, C or D) as duplicate of
that particular "manifestation" (from application A), just because it was
reported in application A first? I would say no.
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.
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.
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.
Thanks,
Manuel
Another thing worth mentioning is that in this particular case that you`ve
mentioned, I`ve created the issue because I was not able to handle it on
the spot and I considered the problem to be of enough importance to deserve
its own issue (and thus gather visibility).
In practice, when the dev addresses the reported manifestation on the spot,
the fix can easily be committed directly on the manifestation issue itself,
without needing to create a separate "cause" issue.
We don`t really have a practice to handle things this way (i.e. always
create a "cause" issue), probably also to avoid artificially increasing the
number of issues and also to keep formalities low.
However, if we do end up having the cause issue (which in this case we do,
due to the reason I mentioned), I would see it more reasonable to mark the
manifestation as the duplicate of the cause.
Thanks,
Eduard
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1 p.m.
New subject: [xwiki-devs] [Proposal] New Best Practice for closing issues as Duplicate
Manuel Smeria wrote:
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.
To me it makes a lot of
sense to close the bug together with its
manifestations.
Even better for the quality: once the developer issue is closed, the
manifestation creators are asked to revalidate their manifestation and
close it themselves.
I agree this breaks the issue-counts...
Paul
1:15 p.m.
On 23 Sep 2016, at 13:00, Paul Libbrecht
<paul(a)hoplahup.net> wrote:
Manuel Smeria wrote:
And the release notes when you generate them from JIRA.
-Vincent
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.
To me it makes a lot of
sense to close the bug together with its
manifestations.
Even better for the quality: once the developer issue is closed, the
manifestation creators are asked to revalidate their manifestation and
close it themselves.
I agree this breaks the issue-counts…
Paul
2783
days inactive
2907
days old
18 comments
7 participants
participants (7)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume Delhumeau -
Manuel Smeria -
Marius Dumitru Florea -
Paul Libbrecht -
Vincent Massol