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 >
