Hi Manuel, > On 25 Jan 2017, at 13:07, 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?
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) < > [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
