Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Ecaterina Moraru (Valica)]

Created Forum entry
https://forum.xwiki.org/t/comparing-xwiki-to-mediawiki-and-confluence-on-xwiki-org/634

Thanks,
Caty

On Fri, Sep 22, 2017 at 7:11 PM, Ecaterina Moraru (Valica) <
vali...@gmail.com> wrote:

> Hi,
>
> I finally got the time to make another iteration for these comparison
> pages.
>
> If anyone want to make modifications on the texts, they are available at:
> - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/
> - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-Confluence/
> - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-MediaWiki/
>
> They should look like:
> - Compare: http://design.xwiki.org/xwiki/bin/download/Proposal/
> XWikiOrg2017/preview_Compare.png
> - XWiki vs. Confluence: http://design.xwiki.org/xwiki/
> bin/download/Proposal/XWikiOrg2017/preview_Confluence.png
> - XWiki vs. MediaWiki: http://design.xwiki.org/xwiki/
> bin/download/Proposal/XWikiOrg2017/preview_MediaWiki.png
>
> I'm curious to know what you think about this version in terms of layout,
> validate the content, maybe you have other points that we can compare the
> solutions on, maybe I wrote something wrong for the solutions.
>
> Let me know,
> Caty
>
> On Tue, May 17, 2016 at 11:17 PM, Bryn Jeffries <
> bryn.jeffr...@sydney.edu.au> wrote:
>
>> Denis Gervalle said:
>> > > Yes, we only maintain documentation for the latest version of XWiki on
>> > > xwiki.org (not enough manpower to have decent doc for several
>> versions
>> > > ATM).
>> > >
>> >
>> > However, for version 6.2.5 and later, you have a way to mitigate this
>> > limitation. You can install the Scripting Documentation Application on
>> your
>> > own wiki (see
>> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripti
>> ng+Documenta
>> > tion+Application).
>>
>> Thanks, I did not know about this tool, which sounds excellent.
>>
>> > Unless you are using XWiki prior to 4.2 , using Wiki Component is
>> definitely
>> > the recommended way to writes Groovy components. Registering
>> > components "by hand" from a groovy script has many drawbacks not only
>> > the restart one, and you should avoid doing that. The best is of course
>> to
>> > write the components in Java, and install them as an extension.
>>
>> I've found the ability to write small Groovy scripts as components has
>> been very handy and simpler than writing full extensions in Java. For
>> utilities that I don't wish to make into public extensions the burden of a
>> small Groovy script into a proper extension seems prohibitive (although
>> that may just be that I haven't written one yet, and I'm just a walker at
>> the bottom of a hill complaining about how high it looks...). Last time I
>> asked there is was no simple way to install private extensions. Also, I
>> didn't have much luck writing a proper component in Groovy, which I
>> sometimes prefer to Java.
>> ___
>> users mailing list
>> users@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/users
>>
>
>

Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Ecaterina Moraru (Valica)]

Hi,

I finally got the time to make another iteration for these comparison
pages.

If anyone want to make modifications on the texts, they are available at:
- http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/
- http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-Confluence/
- http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-MediaWiki/

They should look like:
- Compare:
http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Compare.png
- XWiki vs. Confluence:
http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Confluence.png
- XWiki vs. MediaWiki:
http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_MediaWiki.png

I'm curious to know what you think about this version in terms of layout,
validate the content, maybe you have other points that we can compare the
solutions on, maybe I wrote something wrong for the solutions.

Let me know,
Caty

On Tue, May 17, 2016 at 11:17 PM, Bryn Jeffries  wrote:

> Denis Gervalle said:
> > > Yes, we only maintain documentation for the latest version of XWiki on
> > > xwiki.org (not enough manpower to have decent doc for several versions
> > > ATM).
> > >
> >
> > However, for version 6.2.5 and later, you have a way to mitigate this
> > limitation. You can install the Scripting Documentation Application on
> your
> > own wiki (see
> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripting+Documenta
> > tion+Application).
>
> Thanks, I did not know about this tool, which sounds excellent.
>
> > Unless you are using XWiki prior to 4.2 , using Wiki Component is
> definitely
> > the recommended way to writes Groovy components. Registering
> > components "by hand" from a groovy script has many drawbacks not only
> > the restart one, and you should avoid doing that. The best is of course
> to
> > write the components in Java, and install them as an extension.
>
> I've found the ability to write small Groovy scripts as components has
> been very handy and simpler than writing full extensions in Java. For
> utilities that I don't wish to make into public extensions the burden of a
> small Groovy script into a proper extension seems prohibitive (although
> that may just be that I haven't written one yet, and I'm just a walker at
> the bottom of a hill complaining about how high it looks...). Last time I
> asked there is was no simple way to install private extensions. Also, I
> didn't have much luck writing a proper component in Groovy, which I
> sometimes prefer to Java.
> ___
> users mailing list
> users@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>

Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Bryn Jeffries]

Denis Gervalle said:
> > Yes, we only maintain documentation for the latest version of XWiki on
> > xwiki.org (not enough manpower to have decent doc for several versions
> > ATM).
> >
> 
> However, for version 6.2.5 and later, you have a way to mitigate this
> limitation. You can install the Scripting Documentation Application on your
> own wiki (see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripting+Documenta
> tion+Application).

Thanks, I did not know about this tool, which sounds excellent.

> Unless you are using XWiki prior to 4.2 , using Wiki Component is definitely
> the recommended way to writes Groovy components. Registering
> components "by hand" from a groovy script has many drawbacks not only
> the restart one, and you should avoid doing that. The best is of course to
> write the components in Java, and install them as an extension.

I've found the ability to write small Groovy scripts as components has been 
very handy and simpler than writing full extensions in Java. For utilities that 
I don't wish to make into public extensions the burden of a small Groovy script 
into a proper extension seems prohibitive (although that may just be that I 
haven't written one yet, and I'm just a walker at the bottom of a hill 
complaining about how high it looks...). Last time I asked there is was no 
simple way to install private extensions. Also, I didn't have much luck writing 
a proper component in Groovy, which I sometimes prefer to Java.
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Denis Gervalle]

On Mon, May 16, 2016 at 10:45 AM, Vincent Massol  wrote:

> Hi Bryn,
>
> Thanks again, see below.
>
> > On 16 May 2016, at 00:40, Bryn Jeffries 
> wrote:
> >
> > Vincent wrote:
> >> You seem to be knowing Confluence which is great, since it’s been more
> than
> >> 10 years that I haven’t used it myself.
> >
> > It's been a few years for me also, but I suspect many of the good
> features present then are still the most noticeable.
> >
> >> Indeed, I don’t know why there’s this "Ticket plugin” mentioned. I’ll
> check
> >> with Caty. XWiki certainly doesn’t have a full ticket extension right
> now
> >> AFAIK. The closest I can think of is the Task Application:
> >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Appli
> >> cation
> >
> > Yes, I looked into this but it felt like a proof of principle rather
> than an actively used and maintained product. I ended up going with the
> Redmine plugin instead for a while, but it wasn't anything near Jira.
>
> Yes, it could have some more love for sure ;) However, it’s supposed to be
> usable and it’s not competing with dedicated products such as redmine,
> jira, etc. Dedicated products will always be better. The goal is that if
> your needs are small, you can instal this extension and it’ll do the job
> and you don’t need to install another product.
>
> What we should be doing is integrate with external issue trackers.
>
> Regarding JIRA for example, we have strong integration with it using our
> JIRA macro our our JIRA scripting API.
>
> > The extensions in XWiki really vary in quality, whereas Confluence has a
> lot
> >> of very polished plugins. That's at least been my experience, and I
> think
> >> there's a need to distinguish between high-quality maintained
> extensions vs.
> >> the more hacky ones.
> >>
> >> Definitely. I’ve also discussed this with others and it’s time that we
> start
> >> curating extensions and introduce some “Editor Picks” or “Recommended”
> >> extensions. I’ll start this in another thread real soon.
> >
> > I think this is a smart move. A decent set of flagship plugins could
> really set the standard for others.
> >
> > Also, if you're competing with Confluence, it's important to keep in
> mind that it's not just a wiki. The appeal of Confluence is that it's a
> great wiki with excellent integration with Atlassian's other (also great)
> products like Jira and source code repositories. To appeal to the same
> audience you really need to have a strong ecosystem built around the XWiki
> platform.
>
> There’s a difference here. XWiki’s goal is not to compete on the developer
> spectrum but more on the general business one, see
> http://dev.xwiki.org/xwiki/bin/view/Drafts/XWiki-vs-Confluence#HIntermsofmarketpositioning
>
> Now, I personally think that XWiki should have a great appeal to devs
> since it’s full programmable and scriptable.
>
> > The lack of a markup editor in Confluence is a big difference. Might be
> >> worth illustrating further.
> >>
> >> Agreed. Maybe the polyglotism too (ability to use various markup
> syntaxes).
> >
> > Maybe. Sometimes too much choice can be a bad thing. A single really
> good markup language is better that multiple similar ones. But being able
> to port easily from other systems with different markups is certainly a
> good thing. On several occasions I've found myself investing time writing
> content in one system, and then years later being unable to move to better
> platforms because the markup languages are incompatible and not having the
> time to port things over manually.
> >
> >>
> >>> I think the page hierarchy model is rather difference. Confluence makes
> >> chaining of child pages very easy, and access restrictions to child
> pages is
> >> simple to manage. XWiki was a bit clunky by comparison, but that was
> for 7.1
> >> and maybe the addition of sub-spaces in more recent versions makes this
> >> easier to manage.
> >>
> >> Could you explain why it’s simpler with Confluence by comparison with,
> say,
> >> XWiki 7.4.3? I think this now at least as easy if not more now. Same
> for access
> >> restrictions to children pages.
> >>
> >> See
> http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization
> >
> > This is a new feature that I haven't tried yet - I'm running a 7.1.1 and
> 7.1.2 system. I look forward to upgrading and trying this out soon.
>
> I’m eager to get your feedback on this!
>
> > The other big difference, to me, is in documentation. XWiki has
> >>> changed a lot over the years, particularly in the API,
> >>
> >> This is not fully correct. A lot of new APIs have been introduced,
> showing the
> >> dynamism of the XWiki community indeed. However, we take very seriously
> >> backward-compatibility (so seriously that breaking it fails our build
> >> automatically ;)). So all that worked are still supposed to work. Do
> you have
> >> an example that you’ve noticed where it’s not true (it can happen from
> 

Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Vincent Massol]

Hi Bryn,

Thanks again, see below.

> On 16 May 2016, at 00:40, Bryn Jeffries  wrote:
> 
> Vincent wrote:
>> You seem to be knowing Confluence which is great, since it’s been more than
>> 10 years that I haven’t used it myself.
> 
> It's been a few years for me also, but I suspect many of the good features 
> present then are still the most noticeable.
> 
>> Indeed, I don’t know why there’s this "Ticket plugin” mentioned. I’ll check
>> with Caty. XWiki certainly doesn’t have a full ticket extension right now
>> AFAIK. The closest I can think of is the Task Application:
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Appli
>> cation
> 
> Yes, I looked into this but it felt like a proof of principle rather than an 
> actively used and maintained product. I ended up going with the Redmine 
> plugin instead for a while, but it wasn't anything near Jira.

Yes, it could have some more love for sure ;) However, it’s supposed to be 
usable and it’s not competing with dedicated products such as redmine, jira, 
etc. Dedicated products will always be better. The goal is that if your needs 
are small, you can instal this extension and it’ll do the job and you don’t 
need to install another product.

What we should be doing is integrate with external issue trackers.

Regarding JIRA for example, we have strong integration with it using our JIRA 
macro our our JIRA scripting API.

> The extensions in XWiki really vary in quality, whereas Confluence has a lot
>> of very polished plugins. That's at least been my experience, and I think
>> there's a need to distinguish between high-quality maintained extensions vs.
>> the more hacky ones.
>> 
>> Definitely. I’ve also discussed this with others and it’s time that we start
>> curating extensions and introduce some “Editor Picks” or “Recommended”
>> extensions. I’ll start this in another thread real soon.
> 
> I think this is a smart move. A decent set of flagship plugins could really 
> set the standard for others.
> 
> Also, if you're competing with Confluence, it's important to keep in mind 
> that it's not just a wiki. The appeal of Confluence is that it's a great wiki 
> with excellent integration with Atlassian's other (also great) products like 
> Jira and source code repositories. To appeal to the same audience you really 
> need to have a strong ecosystem built around the XWiki platform.

There’s a difference here. XWiki’s goal is not to compete on the developer 
spectrum but more on the general business one, see 
http://dev.xwiki.org/xwiki/bin/view/Drafts/XWiki-vs-Confluence#HIntermsofmarketpositioning

Now, I personally think that XWiki should have a great appeal to devs since 
it’s full programmable and scriptable.

> The lack of a markup editor in Confluence is a big difference. Might be
>> worth illustrating further.
>> 
>> Agreed. Maybe the polyglotism too (ability to use various markup syntaxes).
> 
> Maybe. Sometimes too much choice can be a bad thing. A single really good 
> markup language is better that multiple similar ones. But being able to port 
> easily from other systems with different markups is certainly a good thing. 
> On several occasions I've found myself investing time writing content in one 
> system, and then years later being unable to move to better platforms because 
> the markup languages are incompatible and not having the time to port things 
> over manually.
> 
>> 
>>> I think the page hierarchy model is rather difference. Confluence makes
>> chaining of child pages very easy, and access restrictions to child pages is
>> simple to manage. XWiki was a bit clunky by comparison, but that was for 7.1
>> and maybe the addition of sub-spaces in more recent versions makes this
>> easier to manage.
>> 
>> Could you explain why it’s simpler with Confluence by comparison with, say,
>> XWiki 7.4.3? I think this now at least as easy if not more now. Same for 
>> access
>> restrictions to children pages.
>> 
>> See http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization
> 
> This is a new feature that I haven't tried yet - I'm running a 7.1.1 and 
> 7.1.2 system. I look forward to upgrading and trying this out soon.

I’m eager to get your feedback on this!

> The other big difference, to me, is in documentation. XWiki has
>>> changed a lot over the years, particularly in the API,
>> 
>> This is not fully correct. A lot of new APIs have been introduced, showing 
>> the
>> dynamism of the XWiki community indeed. However, we take very seriously
>> backward-compatibility (so seriously that breaking it fails our build
>> automatically ;)). So all that worked are still supposed to work. Do you have
>> an example that you’ve noticed where it’s not true (it can happen from time
>> to time when we conscientiously decide to break a recent API that we think
>> nobody uses) .
> 
> Again, I may be out of date here. I've really struggled to get the API 
> documentation for 7.1. I see that things 

Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Ryszard Łach]

On 2016-05-14 14:47, Vincent Massol wrote:
>> The extensions in XWiki really vary in quality, whereas Confluence has a lot 
>> of very polished plugins. That's at least been my experience, and I think 
>> there's a need to distinguish between high-quality maintained extensions vs. 
>> the more hacky ones.
> Definitely. I’ve also discussed this with others and it’s time that we start 
> curating extensions and introduce some “Editor Picks” or “Recommended” 
> extensions. I’ll start this in another thread real soon.
>

I think, that first simple step to improve extensions could be improving info 
about creating issues regarding extension. I recently tried to create one 
following link from standard extension homepage and didn't make to create it in 
right place.

Cheers,
R.
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Bryn Jeffries]

Vincent wrote:
> You seem to be knowing Confluence which is great, since it’s been more than
> 10 years that I haven’t used it myself.

It's been a few years for me also, but I suspect many of the good features 
present then are still the most noticeable.

> Indeed, I don’t know why there’s this "Ticket plugin” mentioned. I’ll check
> with Caty. XWiki certainly doesn’t have a full ticket extension right now
> AFAIK. The closest I can think of is the Task Application:
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Appli
> cation

Yes, I looked into this but it felt like a proof of principle rather than an 
actively used and maintained product. I ended up going with the Redmine plugin 
instead for a while, but it wasn't anything near Jira.

> > The extensions in XWiki really vary in quality, whereas Confluence has a lot
> of very polished plugins. That's at least been my experience, and I think
> there's a need to distinguish between high-quality maintained extensions vs.
> the more hacky ones.
> 
> Definitely. I’ve also discussed this with others and it’s time that we start
> curating extensions and introduce some “Editor Picks” or “Recommended”
> extensions. I’ll start this in another thread real soon.

I think this is a smart move. A decent set of flagship plugins could really set 
the standard for others.

Also, if you're competing with Confluence, it's important to keep in mind that 
it's not just a wiki. The appeal of Confluence is that it's a great wiki with 
excellent integration with Atlassian's other (also great) products like Jira 
and source code repositories. To appeal to the same audience you really need to 
have a strong ecosystem built around the XWiki platform.

> 
> > The lack of a markup editor in Confluence is a big difference. Might be
> worth illustrating further.
> 
> Agreed. Maybe the polyglotism too (ability to use various markup syntaxes).

Maybe. Sometimes too much choice can be a bad thing. A single really good 
markup language is better that multiple similar ones. But being able to port 
easily from other systems with different markups is certainly a good thing. On 
several occasions I've found myself investing time writing content in one 
system, and then years later being unable to move to better platforms because 
the markup languages are incompatible and not having the time to port things 
over manually.

> 
> > I think the page hierarchy model is rather difference. Confluence makes
> chaining of child pages very easy, and access restrictions to child pages is
> simple to manage. XWiki was a bit clunky by comparison, but that was for 7.1
> and maybe the addition of sub-spaces in more recent versions makes this
> easier to manage.
> 
> Could you explain why it’s simpler with Confluence by comparison with, say,
> XWiki 7.4.3? I think this now at least as easy if not more now. Same for 
> access
> restrictions to children pages.
> 
> See http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization

This is a new feature that I haven't tried yet - I'm running a 7.1.1 and 7.1.2 
system. I look forward to upgrading and trying this out soon.

> > The other big difference, to me, is in documentation. XWiki has
> > changed a lot over the years, particularly in the API,
> 
> This is not fully correct. A lot of new APIs have been introduced, showing the
> dynamism of the XWiki community indeed. However, we take very seriously
> backward-compatibility (so seriously that breaking it fails our build
> automatically ;)). So all that worked are still supposed to work. Do you have
> an example that you’ve noticed where it’s not true (it can happen from time
> to time when we conscientiously decide to break a recent API that we think
> nobody uses) .

Again, I may be out of date here. I've really struggled to get the API 
documentation for 7.1. I see that things have been cleaned up a lot at 
http://platform.xwiki.org/xwiki/bin/view/DevGuide/API but the APIs still seem 
to be missing for versions between 5.0 and 7.4.3. Obviously the solution for me 
now would be to upgrade.

> > > and a lot of the material discoverable on the web is out of date.
> 
> Any example? That would help to fix them.

Again this may be historical rather than present day. I'll certainly yell if I 
encounter examples in the future. When I first set about writing a component I 
googled around for examples and much of that was for the older plugin 
architecture, and I was too new to things to appreciate the difference. I think 
the API was also in a state of transition at the time, so properties available 
through the wiki context required awkward bridging classes that didn't make 
sense to noobs such as me.

Incidentally, I think it could still be easier to write extensions for XWiki. 
Writing Groovy components within XWiki pages is neat, but (at least in 7.1) 
they don't work until someone manually visits the page a first time. This means 
some components stop working when the system is 

Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Vincent Massol]

Hi Bryn,

Thanks for your feedback, lots of good points. See below for a point by point 
comment.

> On 14 May 2016, at 00:47, Bryn Jeffries  wrote:
> 
> Useful comparisons, but I wasn't sure who the expected reader would be.

I’ve just sent another email explaining more the context and the reason for 
this initiative.

> The XWiki vs Confluence comparison feels rather biased so wouldn't be very 
> helpful to someone trying to make a rational decision.

The goal is of course to be as unbiased as possible although it’s never fully 
possible to do so. At least we need to find out the parts that are not correct 
and remove them or word them better. The goal is to highlight the strengths of 
XWiki vs Confluence and MediaWiki.

> The table makes them seem identical (perhaps it would be useful to highlight 
> the actual differences) aside from license.

I agree that I’m not sure we need to list the stuff that are similar and maybe 
it would be better to only mention the differences. Now that said, I think the 
idea is also for neophytes to wikis to be able to understand this page. We need 
to decide which we wish to have.

> Both are listed as having a ticketing plugin, but last time I checked 
> (admittedly over a year ago) I couldn't find a robust plugin anywhere close 
> to Confluence's offerings.

You seem to be knowing Confluence which is great, since it’s been more than 10 
years that I haven’t used it myself.

Indeed, I don’t know why there’s this "Ticket plugin” mentioned. I’ll check 
with Caty. XWiki certainly doesn’t have a full ticket extension right now 
AFAIK. The 
closest I can think of is the Task Application: 
http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Application

> The extensions in XWiki really vary in quality, whereas Confluence has a lot 
> of very polished plugins. That's at least been my experience, and I think 
> there's a need to distinguish between high-quality maintained extensions vs. 
> the more hacky ones.

Definitely. I’ve also discussed this with others and it’s time that we start 
curating extensions and introduce some “Editor Picks” or “Recommended” 
extensions. I’ll start this in another thread real soon.

> The lack of a markup editor in Confluence is a big difference. Might be worth 
> illustrating further.

Agreed. Maybe the polyglotism too (ability to use various markup syntaxes).

> I think the page hierarchy model is rather difference. Confluence makes 
> chaining of child pages very easy, and access restrictions to child pages is 
> simple to manage. XWiki was a bit clunky by comparison, but that was for 7.1 
> and maybe the addition of sub-spaces in more recent versions makes this 
> easier to manage.

Could you explain why it’s simpler with Confluence by comparison with, say, 
XWiki 7.4.3? I think this now at least as easy if not more now. Same for access 
restrictions to children pages.

See http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization

> The other big difference, to me, is in documentation. XWiki has changed a lot 
> over the years, particularly in the API,

This is not fully correct. A lot of new APIs have been introduced, showing the 
dynamism of the XWiki community indeed. However, we take very seriously 
backward-compatibility (so seriously that breaking it fails our build 
automatically ;)). So all that worked are still supposed to work. Do you have 
an example that you’ve noticed where it’s not true (it can happen from time to 
time when we conscientiously decide to break a recent API that we think nobody 
uses) .

> and a lot of the material discoverable on the web is out of date.

Any example? That would help to fix them.

> My perception is that Confluence's API has been more stable over successive 
> releases and more effort has been invested in keeping documentation up to 
> date.

It’s certainly true that we need to improve on dev documentation (the user doc 
is probably ok but the dev one can be improved).

> Much of this difference is just a natural outcome of the proprietary vs. open 
> source backgrounds of each system.

Well our goal is to be open source and still be good on all fronts! :)

Re Confluence, they have lots of people working on the doc vs XWiki where it’s 
the developers doing it, so it’s more a question of manpower than of 
proprietary vs open source IMO.

What’s interesting though XWiki is a smaller team, we’re still progressing and 
innovative at least as fast (if not more) as Confluence IMO. Lots of people 
have commented that they prefer XWiki over Confluence. Some quotes are on 
https://www.xwiki.org/xwiki/bin/view/References/Testimonials

Anyway, let’s focus on editing this comparison page to make it as accurate as 
possible. Keep the comments coming and feel free to edit the doc too if you 
wish.

Thanks
-Vincent

> -Original Message-
>> From: Ecaterina Moraru (Valica) [mailto:vali...@gmail.com]
>> Sent: Saturday, 14 May 2016 1:05 AM
>> To: 

Re: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Bryn Jeffries]

Useful comparisons, but I wasn't sure who the expected reader would be. The 
XWiki vs Confluence comparison feels rather biased so wouldn't be very helpful 
to someone trying to make a rational decision. The table makes them seem 
identical (perhaps it would be useful to highlight the actual differences) 
aside from license. Both are listed as having a ticketing plugin, but last time 
I checked (admittedly over a year ago) I couldn't find a robust plugin anywhere 
close to Confluence's offerings.

The extensions in XWiki really vary in quality, whereas Confluence has a lot of 
very polished plugins. That's at least been my experience, and I think there's 
a need to distinguish between high-quality maintained extensions vs. the more 
hacky ones.

The lack of a markup editor in Confluence is a big difference. Might be worth 
illustrating further.

I think the page hierarchy model is rather difference. Confluence makes 
chaining of child pages very easy, and access restrictions to child pages is 
simple to manage. XWiki was a bit clunky by comparison, but that was for 7.1 
and maybe the addition of sub-spaces in more recent versions makes this easier 
to manage.

The other big difference, to me, is in documentation. XWiki has changed a lot 
over the years, particularly in the API, and a lot of the material discoverable 
on the web is out of date. My perception is that Confluence's API has been more 
stable over successive releases and more effort has been invested in keeping 
documentation up to date. Much of this difference is just a natural outcome of 
the proprietary vs. open source backgrounds of each system.

> -Original Message-
> From: Ecaterina Moraru (Valica) [mailto:vali...@gmail.com]
> Sent: Saturday, 14 May 2016 1:05 AM
> To: XWiki Mailinglist; XWiki Mailinglist
> Subject: [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and
> Confluence on xwiki.org
> 
> Hi,
> 
> Since we had users asking on the IRC what are the differences between
> XWiki and other solutions, it would be a good idea to provide such pages on
> the
> website:
> 
> - XWiki and MediaWiki
> http://dev.xwiki.org/xwiki/bin/view/Drafts/XWiki-vs-MediaWiki
> 
> - XWiki and Confluence
> http://dev.xwiki.org/xwiki/bin/view/Drafts/XWiki-vs-Confluence
> 
> It would be great to know if you agree with the listed content and if you find
> other similarities or distinctions between the above solutions.
> 
> Additionally, what other solutions would you be interested in seeing
> comparison with?
> 
> Thanks,
> Caty

___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users