2016-09-26 11:55 GMT+02:00 Eduard Moraru <[email protected]>: > On Mon, Sep 26, 2016 at 11:39 AM, Guillaume Delhumeau < > [email protected]> wrote: > > > 2016-09-23 12:57 GMT+02:00 Vincent Massol <[email protected]>: > > > > > I agree with Edy’s answer. > > > > > > However, what Manuel is also saying (I think), is that by doing so, we > > > don’t reward the reporter and we don’t incitate him/her to report more. > > > Basically he’s found the problem and we’re saying that he just found a > > > duplicate (this is what someone looking at JIRA without doing > archeology > > on > > > the activity of the issues will think). > > > > > > I don’t have the solution though. > > > > > > > In general, saying "thanks you" seems to be good practice :) It's good > for > > issues, pull requests, etc... In this particular case, we could simply > say: > > "Thanks to this report, we have found the cause of this problem which is > > described in the issue ISSUE-1. As a consequence, we have closed this > > current issue as a duplicate of ISSUE-1." > > > > > > > > > > Any idea? > > > > > > Thanks > > > -Vincent > > > > > > > I agree with the reasoning of Edy about "causes" and "manifestations". > It's > > already the way I am handling issues too. However, I have noticed a > little > > problem. > > > > The issues closed as duplicates are never mentioned in the release notes. > > It's because we don't set the "fix version" field for these issues. It > > makes sense because we don't always know when the "cause" will be closed, > > and it would be a pain to synchronize everything afterwards. > > > > But it means that a user, who have experienced a bug but haven't followed > > the jira issue, won't see in the release notes that her bug is solved. > > Instead, she will see the "cause" bug without seeing its link to the > > manifestation, except by manually browsing jira. > > > > So it is a question of visibility. By reading the list of the issues, we > > miss all the bugs that we consider as manifestations of an other one. > > > > What do you think about this? > > > > Sounds interesting, but it would only make sense, IMO, if we can automate > it, i.e. when updating the Fixed Version property of an issue, also update > it for all its duplicates, so that they are always in synch. We could > probably write some quick listener component/script to take care of this, > since on a quick Google search, the question does appear, but not a clear > result other than custom code. >
That's an interesting lead. > > Thanks, > Eduard > > > > > > Thanks, > > > > > > > > > > > On 23 Sep 2016, at 12:46, Eduard Moraru <[email protected]> > wrote: > > > > > > > > Hi, Manuel, > > > > > > > > On Fri, Sep 23, 2016 at 11:55 AM, Manuel Smeria <[email protected]> > > > 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 > > > >> [email protected] > > > >> http://lists.xwiki.org/mailman/listinfo/devs > > > >> > > > > _______________________________________________ > > > > devs mailing list > > > > [email protected] > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > -- > > Guillaume Delhumeau ([email protected]) > > Research & Development Engineer at XWiki SAS > > Committer on the XWiki.org project > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
