Re: [xwiki-devs] [Proposal] New Best Practice for closing issues as Duplicate

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?

Thanks, Manuel On Tue, Sep 27, 2016 at 1:01 PM, Ecaterina Moraru (Valica) < valicac(a)gmail.com&gt; 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 &lt;vincent(a)massol.net&gt; > wrote: > >> >>> On 27 Sep 2016, at 11:38, Manuel Smeria &lt;manuel(a)xwiki.com&gt; 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&gt; wrote: >>> >>>> On Fri, Sep 23, 2016 at 1:46 PM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt; >>>> wrote: >>>> >>>>> Hi, Manuel, >>>>> >>>>> On Fri, Sep 23, 2016 at 11:55 AM, Manuel Smeria &lt;manuel(a)xwiki.com&gt; >>>> 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