Re: [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.).”

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 &lt;manuel(a)xwiki.com&gt; 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&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 < > 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 >>> _______________________________________________ >>> 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 >> >