Re: [xwiki-devs] [VOTE] Move all Confuence related modules to contrib

[Marius Dumitru Florea]

+1

Thanks,
Marius

On Wed, Jan 25, 2017 at 5:53 PM, Thomas Mortagne 
wrote:

> Hi devs,
>
> I would like to give Confluence filter input and syntaxes modules
> there own life on xwiki-contrib pretty much on the same model than
> what I did for MediaWiki (https://github.com/xwiki-contrib/mediawiki/)
> since it's exactly the same use case.
>
> The main reasons are:
> * those modules are not embedded (for the input) or enabled (for the
> syntaxes) by default
> * those modules need to follow Confluence evolution more than XWiki
>
> WDYT ?
>
> Here is my +1
>
> --
> Thomas Mortagne
>

Re: [xwiki-devs] [Proposal] Changing the location of XED files

[Marius Dumitru Florea]

I don't have a problem with keeping the XED files in WEB-INF/lib if the
spec doesn't forbid it, especially if it simplifies the implementation.

Thanks,
Marius

On Tue, Jan 24, 2017 at 2:26 PM, Vincent Massol  wrote:

> Hi devs,
>
> In XWiki 9.0RC1 we’re putting XED files in WEB-INF/lib next to the JAR to
> which they correspond.
>
> I have 2 issues with this:
> * We’re not really supposed to use WEB-INF/lib for that. WEB-INF/lib is
> meant for JAR files that are to be made available to the classloader. It’s
> even possible that some servlet container would emit warnings about this.
> * This is a WTF for admins when they discover this. The WAR has a spec and
> it’s standardised. Thus the WTF when you see this since you’re not used to
> seeing this anywhere else.
>
> I’m thus proposing to move the XED files to a META-INF/xwiki/ directory
> inside the WAR instead since META-INF is meant to contain metadata
> information and is thus meant exactly for this.
>
> WDTY?
>
> Thanks
> -Vincent
>
>

Re: [xwiki-devs] [VOTE] Move all Confuence related modules to contrib

[Sergiu Dumitriu]

On 01/25/2017 10:53 AM, Thomas Mortagne wrote:
> Hi devs,
> 
> I would like to give Confluence filter input and syntaxes modules
> there own life on xwiki-contrib pretty much on the same model than
> what I did for MediaWiki (https://github.com/xwiki-contrib/mediawiki/)
> since it's exactly the same use case.
> 
> The main reasons are:
> * those modules are not embedded (for the input) or enabled (for the
> syntaxes) by default
> * those modules need to follow Confluence evolution more than XWiki
> 
> WDYT ?
> 
> Here is my +1
> 

+1 as well. Extra syntaxes are a nice bragging point, but having them in
the package by default is just bloatware.

-- 
Sergiu Dumitriu
http://purl.org/net/sergiu

Re: [xwiki-devs] [VOTE] Move all Confuence related modules to contrib

[Thomas Mortagne]

Yes but confluence syntaxes are bundled technically so I prefer a vote
on this one.


On Wed, Jan 25, 2017 at 4:56 PM, Vincent Massol  wrote:
> Note: I think we’ve already voted to move all modules not bundled by default 
> in XE to contrib, right?
>
> Thanks
> -Vincent
>
>> On 25 Jan 2017, at 16:54, Vincent Massol  wrote:
>>
>>>
>>> On 25 Jan 2017, at 16:53, Thomas Mortagne  wrote:
>>>
>>> Hi devs,
>>>
>>> I would like to give Confluence filter input and syntaxes modules
>>> there own life on xwiki-contrib pretty much on the same model than
>>> what I did for MediaWiki (https://github.com/xwiki-contrib/mediawiki/)
>>> since it's exactly the same use case.
>>>
>>> The main reasons are:
>>> * those modules are not embedded (for the input) or enabled (for the
>>> syntaxes) by default
>>> * those modules need to follow Confluence evolution more than XWiki
>>>
>>> WDYT ?
>>>
>>> Here is my +1
>>
>> +1
>>
>> Thanks
>> -Vincent
>>
>>> --
>>> Thomas Mortagne
>



-- 
Thomas Mortagne

Re: [xwiki-devs] [VOTE] Move all Confuence related modules to contrib

[Vincent Massol]

Note: I think we’ve already voted to move all modules not bundled by default in 
XE to contrib, right?

Thanks
-Vincent

> On 25 Jan 2017, at 16:54, Vincent Massol  wrote:
> 
>> 
>> On 25 Jan 2017, at 16:53, Thomas Mortagne  wrote:
>> 
>> Hi devs,
>> 
>> I would like to give Confluence filter input and syntaxes modules
>> there own life on xwiki-contrib pretty much on the same model than
>> what I did for MediaWiki (https://github.com/xwiki-contrib/mediawiki/)
>> since it's exactly the same use case.
>> 
>> The main reasons are:
>> * those modules are not embedded (for the input) or enabled (for the
>> syntaxes) by default
>> * those modules need to follow Confluence evolution more than XWiki
>> 
>> WDYT ?
>> 
>> Here is my +1
> 
> +1
> 
> Thanks
> -Vincent
> 
>> -- 
>> Thomas Mortagne

Re: [xwiki-devs] [VOTE] Move all Confuence related modules to contrib

[Vincent Massol]

> On 25 Jan 2017, at 16:53, Thomas Mortagne  wrote:
> 
> Hi devs,
> 
> I would like to give Confluence filter input and syntaxes modules
> there own life on xwiki-contrib pretty much on the same model than
> what I did for MediaWiki (https://github.com/xwiki-contrib/mediawiki/)
> since it's exactly the same use case.
> 
> The main reasons are:
> * those modules are not embedded (for the input) or enabled (for the
> syntaxes) by default
> * those modules need to follow Confluence evolution more than XWiki
> 
> WDYT ?
> 
> Here is my +1

+1

Thanks
-Vincent

> -- 
> Thomas Mortagne

[xwiki-devs] [VOTE] Move all Confuence related modules to contrib

[Thomas Mortagne]

Hi devs,

I would like to give Confluence filter input and syntaxes modules
there own life on xwiki-contrib pretty much on the same model than
what I did for MediaWiki (https://github.com/xwiki-contrib/mediawiki/)
since it's exactly the same use case.

The main reasons are:
* those modules are not embedded (for the input) or enabled (for the
syntaxes) by default
* those modules need to follow Confluence evolution more than XWiki

WDYT ?

Here is my +1

-- 
Thomas Mortagne

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

[Vincent Massol]

> On 25 Jan 2017, at 14:04, Eduard Moraru  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  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) <
>> vali...@gmail.com> 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 
>>> wrote:
>>> 
 
> On 27 Sep 2016, at 11:38, Manuel Smeria  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.flo...@xwiki.com> wrote:
> 
>> On Fri, Sep 23, 2016 at 1:46 PM, Eduard Moraru <
>> enygma2...@gmail.com>
>> wrote:
>> 
>>> Hi, Manuel,
>>> 
>>> On Fri, Sep 23, 2016 at 11:55 AM, Manuel Smeria 
>> 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 

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

[Vincent Massol]

Hi Manuel,

> On 25 Jan 2017, at 13:07, Manuel Smeria  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) <
> vali...@gmail.com> 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 
>> wrote:
>> 
>>> 
 On 27 Sep 2016, at 11:38, Manuel Smeria  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.flo...@xwiki.com> wrote:
 
> On Fri, Sep 23, 2016 at 1:46 PM, Eduard Moraru 
> wrote:
> 
>> Hi, Manuel,
>> 
>> On Fri, Sep 23, 2016 at 11:55 AM, Manuel Smeria 
> 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.
>>> 
>>> 

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

[Eduard Moraru]

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_what_not_to_do_in_Bugzilla#Resolving_bugs_as_DUPLICATE

On Wed, Jan 25, 2017 at 2:07 PM, Manuel Smeria  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) <
> vali...@gmail.com> 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 
> > wrote:
> >
> > >
> > > > On 27 Sep 2016, at 11:38, Manuel Smeria  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.flo...@xwiki.com> wrote:
> > > >
> > > >> On Fri, Sep 23, 2016 at 1:46 PM, Eduard Moraru <
> enygma2...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Hi, Manuel,
> > > >>>
> > > >>> On Fri, Sep 23, 2016 at 11:55 AM, Manuel Smeria 
> > > >> 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
> 

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

[Manuel Smeria]

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) <
vali...@gmail.com> 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 
> wrote:
>
> >
> > > On 27 Sep 2016, at 11:38, Manuel Smeria  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.flo...@xwiki.com> wrote:
> > >
> > >> On Fri, Sep 23, 2016 at 1:46 PM, Eduard Moraru 
> > >> wrote:
> > >>
> > >>> Hi, Manuel,
> > >>>
> > >>> On Fri, Sep 23, 2016 at 11:55 AM, Manuel Smeria 
> > >> 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.
> > 
> > >>>
> > >>>
> > >>
> >