> On 25 Jan 2017, at 14:04, Eduard Moraru <[email protected]> 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_what_not_to_do_in_Bugzilla#Resolving_bugs_as_DUPLICATE > > On Wed, Jan 25, 2017 at 2:07 PM, Manuel Smeria <[email protected]> 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) < >> [email protected]> 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 <[email protected]> >>> wrote: >>> >>>> >>>>> On 27 Sep 2016, at 11:38, Manuel Smeria <[email protected]> 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 < >>>>> [email protected]> wrote: >>>>> >>>>>> On Fri, Sep 23, 2016 at 1:46 PM, 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). >>>>>>> >>>>>> >>>>>> 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 >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >>
