[Idea] XWiki Project Development Flavor

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[Idea] XWiki Project Development Flavor

vmassol
Administrator
Hi devs,

I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like .

Some scattered thoughts:

* First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example.

* Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself.

* We need to finish the Flavor idea by allowing the DM to list flavors.

* Some ideas of content for this Development Project flavor:
** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples:
*** Statistics about commits using Git/GitHub
*** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails)
*** Latest issues (taken from JIRA for example)
*** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#HCommunityHome
** A Release application to help perform releases
** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it
** A Release notes application
** The Blog application
** Ability to generate a whole PDF for the project's documentation for a given version
** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x)
** A layout configured for the flavor
** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker
** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc
** The IRC Bot application
** Bundle the JIRA macro
** Bundle the FAQ application
** A Roadmap application

* Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc).

WDYT?

Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Caleb James DeLisle


On 11/18/2012 05:11 AM, Vincent Massol wrote:
> Hi devs,
>
> I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like .

This could work but would not be easy, developers have pretty specific requirements.

>
> Some scattered thoughts:
>
> * First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example.

Indeed.

>
> * Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself.
>
> * We need to finish the Flavor idea by allowing the DM to list flavors.
>
> * Some ideas of content for this Development Project flavor:
> ** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples:
> *** Statistics about commits using Git/GitHub
> *** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails)

Just converting a mailing list into something web readable that's not aweful to read is a big bonus.

> *** Latest issues (taken from JIRA for example)
> *** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#HCommunityHome

***Buildbot integration.

> ** A Release application to help perform releases
> ** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it
> ** A Release notes application
> ** The Blog application
> ** Ability to generate a whole PDF for the project's documentation for a given version
> ** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x)
> ** A layout configured for the flavor
> ** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker

+1

> ** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc
> ** The IRC Bot application

This has to work or developers won't use it. At the moment the irc bot is a bit of a rough edge in XWiki.

> ** Bundle the JIRA macro
> ** Bundle the FAQ application
> ** A Roadmap application
>
> * Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc).
>
> WDYT?

I think the idea has merit, I would consider a solution like this for my project but it needs to be light on resources.
I think the "light on resources" requirement is going to be a general trend within the developer community, there are offerings which use around 100MB of system ram total and it's hard to argue that using 400M to 1G is worth it for the benefits.

Thanks,
Caleb

>
> Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

jerem
In reply to this post by vmassol
Hi Vincent,


2012/11/18 Vincent Massol <[hidden email]>

> Hi devs,
>


> *** Latest emails (taken from mailman or other mailing list software,
> possibly by subscribing the project to a mailing list so that it gets the
> emails)
>


> ** A forum application, for example the Mail Archive Application done by
> Jeremie which would need to be improved to add ability to post from it
>

Couldn't / shouldn't it be the same thing ?
I know the Mail Archive App is not finished at all, but one feature is
possibility to generate code to include in pages in order to display
filtered lists of emails or topics loaded by the app (filtering by
mailing-list, with ordering, max nb, etc...).

If I may add some comment, it's a very nice idea. To me the biggest trap is
integration with external sources. If it's not easily pluggable /
configurable and choice is too restricted, it will attract only a little
subset of developers. In my office for example, I would use it if I could
link to Rhodecode or Mercurial (instead of github) and Redmine (instead of
jira).

BR,
Jeremie
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Roman Muntyanu
In reply to this post by vmassol
The idea is awesome. If XWiki-based platform got adopted by Apache - that would make all the difference.

bloodhound is built on trac - so the competition will be against features it provides. Knowing strong sides of XWiki, the task would be to cover the strong sides of trac (issue tracker, VCS integration, etc)

 *** Bundled "Apache-project wiki skeleton" (space with template pages describing team, repository, tools, practices, environment set-up and so on) Something similar to http://dev.xwiki.org/xwiki/bin/view/Main/WebHome . Just like Maven enforces project structure, this template would enforce wiki structure for project development.

How much time do you think we have to implement this flavor?
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Vincent Massol [[hidden email]]
Sent: Sunday, November 18, 2012 12:11 PM
To: XWiki Developers
Subject: [xwiki-devs] [Idea] XWiki Project Development Flavor

Hi devs,

I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like .

Some scattered thoughts:

* First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example.

* Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself.

* We need to finish the Flavor idea by allowing the DM to list flavors.

* Some ideas of content for this Development Project flavor:
** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples:
*** Statistics about commits using Git/GitHub
*** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails)
*** Latest issues (taken from JIRA for example)
*** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#HCommunityHome
** A Release application to help perform releases
** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it
** A Release notes application
** The Blog application
** Ability to generate a whole PDF for the project's documentation for a given version
** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x)
** A layout configured for the flavor
** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker
** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc
** The IRC Bot application
** Bundle the JIRA macro
** Bundle the FAQ application
** A Roadmap application

* Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc).

WDYT?

Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

vmassol
Administrator
In reply to this post by jerem

On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <[hidden email]> wrote:

> Hi Vincent,
>
>
> 2012/11/18 Vincent Massol <[hidden email]>
>
>> Hi devs,
>>
>
>
>> *** Latest emails (taken from mailman or other mailing list software,
>> possibly by subscribing the project to a mailing list so that it gets the
>> emails)
>>
>
>
>> ** A forum application, for example the Mail Archive Application done by
>> Jeremie which would need to be improved to add ability to post from it
>>
>
> Couldn't / shouldn't it be the same thing ?
> I know the Mail Archive App is not finished at all, but one feature is
> possibility to generate code to include in pages in order to display
> filtered lists of emails or topics loaded by the app (filtering by
> mailing-list, with ordering, max nb, etc…).

Yes, it's the same thing I agree.

> If I may add some comment, it's a very nice idea. To me the biggest trap is
> integration with external sources. If it's not easily pluggable /
> configurable and choice is too restricted, it will attract only a little
> subset of developers. In my office for example, I would use it if I could
> link to Rhodecode or Mercurial (instead of github) and Redmine (instead of
> jira).

Yep, we would need contributions for other issue trackers but once we start having something it may attract devs to develop other integrations.

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Guillaume Lerouge
Hi Vincent,

if I may, this looks like a common fallacy: developers wanting to build
tools for developers. Of course building a "XWiki for Software Development"
flavor will sound sexy to you, since you're a developer yourself as well as
a XWiki committer. You would be your own target audience. In other words,
you want to build something for yourself.

However, please note that the market for such tools is already very, very
crowded. There's Trac / Bloodhound, there's the whole Atlassian suite,
there is what Github is building as well as countless other solutions.

One of XWiki's great strengths and differentiators is in its ability to let
people manage structured and unstructured content easily. I think we should
keep focusing our work on this instead of trying to enter a crowded space
with little perceivable benefits. In your mind, is this the very best thing
we could possibly work on in order to ensure XWiki's long-term success and
sustainability?

My 2 cents,

Guillaume

On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]> wrote:

>
> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <[hidden email]>
> wrote:
>
> > Hi Vincent,
> >
> >
> > 2012/11/18 Vincent Massol <[hidden email]>
> >
> >> Hi devs,
> >>
> >
> >
> >> *** Latest emails (taken from mailman or other mailing list software,
> >> possibly by subscribing the project to a mailing list so that it gets
> the
> >> emails)
> >>
> >
> >
> >> ** A forum application, for example the Mail Archive Application done by
> >> Jeremie which would need to be improved to add ability to post from it
> >>
> >
> > Couldn't / shouldn't it be the same thing ?
> > I know the Mail Archive App is not finished at all, but one feature is
> > possibility to generate code to include in pages in order to display
> > filtered lists of emails or topics loaded by the app (filtering by
> > mailing-list, with ordering, max nb, etc…).
>
> Yes, it's the same thing I agree.
>
> > If I may add some comment, it's a very nice idea. To me the biggest trap
> is
> > integration with external sources. If it's not easily pluggable /
> > configurable and choice is too restricted, it will attract only a little
> > subset of developers. In my office for example, I would use it if I could
> > link to Rhodecode or Mercurial (instead of github) and Redmine (instead
> of
> > jira).
>
> Yep, we would need contributions for other issue trackers but once we
> start having something it may attract devs to develop other integrations.
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

vmassol
Administrator

On Nov 21, 2012, at 2:33 PM, Guillaume Lerouge <[hidden email]> wrote:

> Hi Vincent,
>
> if I may, this looks like a common fallacy: developers wanting to build
> tools for developers. Of course building a "XWiki for Software Development"
> flavor will sound sexy to you, since you're a developer yourself as well as
> a XWiki committer. You would be your own target audience. In other words,
> you want to build something for yourself.

I think that not being a developer you completely miss the point :)

> However, please note that the market for such tools is already very, very
> crowded.

Market? Who's talking about marketing/research studies, etc here? :)

> There's Trac / Bloodhound, there's the whole Atlassian suite,
> there is what Github is building as well as countless other solutions.
>
> One of XWiki's great strengths and differentiators is in its ability to let
> people manage structured and unstructured content easily. I think we should
> keep focusing our work on this instead of trying to enter a crowded space
> with little perceivable benefits

Who's "we"?

> . In your mind, is this the very best thing
> we could possibly work on in order to ensure XWiki's long-term success and
> sustainability?

Definitely.

Thanks
-Vincent

> My 2 cents,
>
> Guillaume
>
> On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <[hidden email]>
>> wrote:
>>
>>> Hi Vincent,
>>>
>>>
>>> 2012/11/18 Vincent Massol <[hidden email]>
>>>
>>>> Hi devs,
>>>>
>>>
>>>
>>>> *** Latest emails (taken from mailman or other mailing list software,
>>>> possibly by subscribing the project to a mailing list so that it gets
>> the
>>>> emails)
>>>>
>>>
>>>
>>>> ** A forum application, for example the Mail Archive Application done by
>>>> Jeremie which would need to be improved to add ability to post from it
>>>>
>>>
>>> Couldn't / shouldn't it be the same thing ?
>>> I know the Mail Archive App is not finished at all, but one feature is
>>> possibility to generate code to include in pages in order to display
>>> filtered lists of emails or topics loaded by the app (filtering by
>>> mailing-list, with ordering, max nb, etc…).
>>
>> Yes, it's the same thing I agree.
>>
>>> If I may add some comment, it's a very nice idea. To me the biggest trap
>> is
>>> integration with external sources. If it's not easily pluggable /
>>> configurable and choice is too restricted, it will attract only a little
>>> subset of developers. In my office for example, I would use it if I could
>>> link to Rhodecode or Mercurial (instead of github) and Redmine (instead
>> of
>>> jira).
>>
>> Yep, we would need contributions for other issue trackers but once we
>> start having something it may attract devs to develop other integrations.
>>
>> Thanks
>> -Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

vmassol
Administrator

On Nov 21, 2012, at 2:48 PM, Vincent Massol <[hidden email]> wrote:

>
> On Nov 21, 2012, at 2:33 PM, Guillaume Lerouge <[hidden email]> wrote:
>
>> Hi Vincent,
>>
>> if I may, this looks like a common fallacy: developers wanting to build
>> tools for developers. Of course building a "XWiki for Software Development"
>> flavor will sound sexy to you, since you're a developer yourself as well as
>> a XWiki committer. You would be your own target audience. In other words,
>> you want to build something for yourself.
>
> I think that not being a developer you completely miss the point :)
>
>> However, please note that the market for such tools is already very, very
>> crowded.
>
> Market? Who's talking about marketing/research studies, etc here? :)
>
>> There's Trac / Bloodhound, there's the whole Atlassian suite,
>> there is what Github is building as well as countless other solutions.
>>
>> One of XWiki's great strengths and differentiators is in its ability to let
>> people manage structured and unstructured content easily. I think we should
>> keep focusing our work on this instead of trying to enter a crowded space
>> with little perceivable benefits
>
> Who's "we"?
>
>> . In your mind, is this the very best thing
>> we could possibly work on in order to ensure XWiki's long-term success and
>> sustainability?
>
> Definitely.

Just to explain: what we need for xwiki's long term success are contributions and who does contributions? Developers. Appealing to them is needed. Right now I've never succeeded in getting any developer interested in XWiki by presenting it to them. I believe that giving them a tool they want to use for their job would make XWiki more appealing to them.

In any case, I'm not proposing some new roadmap or the like. I'm personally going to work on this. Actually I've started working on this as soon as I joined this project several years ago and I'll continue since we need this for ourselves anyway for xwiki.org and that's enough to justify it since we're already spending the time on it. Now with this email I'm trying to get other people interested in this topic (the more the merrier) and to explain what I'm driving at.

FTR here's what we have so far that's finished (and used on xwiki.org):
* FAQ application
* JIRA macro
* IRC Bot (although we still need to fix a few things as Caleb mentioned but they are small)

In progress:
* MailArchive Application from Jeremie
* Release app (see dev.xwiki.org/xwiki/bin/view/ReleasePlans/WebHome). We'll also need to integrate in it the creation of Release Notes as a feature.
* Some Git/Github extension: http://extensions.xwiki.org/xwiki/bin/view/Extension/GitHub+Application. I'd like to use it on the Hall Of Fame page on xwiki.org
* and probably some more….

Thanks
-Vincent

> Thanks
> -Vincent
>
>> My 2 cents,
>>
>> Guillaume
>>
>> On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]> wrote:
>>
>>>
>>> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <[hidden email]>
>>> wrote:
>>>
>>>> Hi Vincent,
>>>>
>>>>
>>>> 2012/11/18 Vincent Massol <[hidden email]>
>>>>
>>>>> Hi devs,
>>>>>
>>>>
>>>>
>>>>> *** Latest emails (taken from mailman or other mailing list software,
>>>>> possibly by subscribing the project to a mailing list so that it gets
>>> the
>>>>> emails)
>>>>>
>>>>
>>>>
>>>>> ** A forum application, for example the Mail Archive Application done by
>>>>> Jeremie which would need to be improved to add ability to post from it
>>>>>
>>>>
>>>> Couldn't / shouldn't it be the same thing ?
>>>> I know the Mail Archive App is not finished at all, but one feature is
>>>> possibility to generate code to include in pages in order to display
>>>> filtered lists of emails or topics loaded by the app (filtering by
>>>> mailing-list, with ordering, max nb, etc…).
>>>
>>> Yes, it's the same thing I agree.
>>>
>>>> If I may add some comment, it's a very nice idea. To me the biggest trap
>>> is
>>>> integration with external sources. If it's not easily pluggable /
>>>> configurable and choice is too restricted, it will attract only a little
>>>> subset of developers. In my office for example, I would use it if I could
>>>> link to Rhodecode or Mercurial (instead of github) and Redmine (instead
>>> of
>>>> jira).
>>>
>>> Yep, we would need contributions for other issue trackers but once we
>>> start having something it may attract devs to develop other integrations.
>>>
>>> Thanks
>>> -Vincent
>

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Guillaume Lerouge
In reply to this post by vmassol
Hi Vincent,

On Wed, Nov 21, 2012 at 2:48 PM, Vincent Massol <[hidden email]> wrote:

>
> On Nov 21, 2012, at 2:33 PM, Guillaume Lerouge <[hidden email]>
> wrote:
>
> > Hi Vincent,
> >
> > if I may, this looks like a common fallacy: developers wanting to build
> > tools for developers. Of course building a "XWiki for Software
> Development"
> > flavor will sound sexy to you, since you're a developer yourself as well
> as
> > a XWiki committer. You would be your own target audience. In other words,
> > you want to build something for yourself.
>
> I think that not being a developer you completely miss the point :)
>

Of course.

> However, please note that the market for such tools is already very, very
> > crowded.
>
> Market? Who's talking about marketing/research studies, etc here? :)
>

As a developer, you're (presumably) writing software for an audience, with
the hope that members of this audience ("users") will some day use it.

I used the word "market" in that sense.


> > There's Trac / Bloodhound, there's the whole Atlassian suite,
> > there is what Github is building as well as countless other solutions.
> >
> > One of XWiki's great strengths and differentiators is in its ability to
> let
> > people manage structured and unstructured content easily. I think we
> should
> > keep focusing our work on this instead of trying to enter a crowded space
> > with little perceivable benefits
>
> Who's "we"?
>

Members of the XWiki.org community.

Guillaume

> . In your mind, is this the very best thing
> > we could possibly work on in order to ensure XWiki's long-term success
> and
> > sustainability?
>
> Definitely.
>

Not "one of the best things", "the very best thing". There is nothing else
that could possibly be appealing to a wider audience and would thus
guarantee the long-term sustainability of XWiki software?

Guillaume

Thanks

> -Vincent
>
> > My 2 cents,
> >
> > Guillaume
> >
> > On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]>
> wrote:
> >
> >>
> >> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <
> [hidden email]>
> >> wrote:
> >>
> >>> Hi Vincent,
> >>>
> >>>
> >>> 2012/11/18 Vincent Massol <[hidden email]>
> >>>
> >>>> Hi devs,
> >>>>
> >>>
> >>>
> >>>> *** Latest emails (taken from mailman or other mailing list software,
> >>>> possibly by subscribing the project to a mailing list so that it gets
> >> the
> >>>> emails)
> >>>>
> >>>
> >>>
> >>>> ** A forum application, for example the Mail Archive Application done
> by
> >>>> Jeremie which would need to be improved to add ability to post from it
> >>>>
> >>>
> >>> Couldn't / shouldn't it be the same thing ?
> >>> I know the Mail Archive App is not finished at all, but one feature is
> >>> possibility to generate code to include in pages in order to display
> >>> filtered lists of emails or topics loaded by the app (filtering by
> >>> mailing-list, with ordering, max nb, etc…).
> >>
> >> Yes, it's the same thing I agree.
> >>
> >>> If I may add some comment, it's a very nice idea. To me the biggest
> trap
> >> is
> >>> integration with external sources. If it's not easily pluggable /
> >>> configurable and choice is too restricted, it will attract only a
> little
> >>> subset of developers. In my office for example, I would use it if I
> could
> >>> link to Rhodecode or Mercurial (instead of github) and Redmine (instead
> >> of
> >>> jira).
> >>
> >> Yep, we would need contributions for other issue trackers but once we
> >> start having something it may attract devs to develop other
> integrations.
> >>
> >> Thanks
> >> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Guillaume Lerouge
In reply to this post by vmassol
Hi again,

On Wed, Nov 21, 2012 at 2:58 PM, Vincent Massol <[hidden email]> wrote:

>
> On Nov 21, 2012, at 2:48 PM, Vincent Massol <[hidden email]> wrote:
>
> > On Nov 21, 2012, at 2:33 PM, Guillaume Lerouge <[hidden email]>
> wrote:
> >
> >> Hi Vincent,
> >>
> >> if I may, this looks like a common fallacy: developers wanting to build
> >> tools for developers. Of course building a "XWiki for Software
> Development"
> >> flavor will sound sexy to you, since you're a developer yourself as
> well as
> >> a XWiki committer. You would be your own target audience. In other
> words,
> >> you want to build something for yourself.
> >
> > I think that not being a developer you completely miss the point :)
> >
> >> However, please note that the market for such tools is already very,
> very
> >> crowded.
> >
> > Market? Who's talking about marketing/research studies, etc here? :)
> >
> >> There's Trac / Bloodhound, there's the whole Atlassian suite,
> >> there is what Github is building as well as countless other solutions.
> >>
> >> One of XWiki's great strengths and differentiators is in its ability to
> let
> >> people manage structured and unstructured content easily. I think we
> should
> >> keep focusing our work on this instead of trying to enter a crowded
> space
> >> with little perceivable benefits
> >
> > Who's "we"?
> >
> >> . In your mind, is this the very best thing
> >> we could possibly work on in order to ensure XWiki's long-term success
> and
> >> sustainability?
> >
> > Definitely.
>
> Just to explain: what we need for xwiki's long term success are
> contributions and who does contributions? Developers. Appealing to them is
> needed. Right now I've never succeeded in getting any developer interested
> in XWiki by presenting it to them. I believe that giving them a tool they
> want to use for their job would make XWiki more appealing to them.
>

Following this type of logic, if you were working on Microsoft Office you'd
start adding code-highlighting features in order to make it more appealing
to developers. Sounds like a great idea, doesn't it?

What matters for the long-term success of any piece of software is to have
users who love using it. Those users do not necessarily have to be
developers. Developers tend target platforms where they know they will be
able to reach numerous users. So I'd go about this the other way: build a
platform that people love using, and developers will come.


> In any case, I'm not proposing some new roadmap or the like. I'm
> personally going to work on this. Actually I've started working on this as
> soon as I joined this project several years ago and I'll continue since we
> need this for ourselves anyway for xwiki.org and that's enough to justify
> it since we're already spending the time on it. Now with this email I'm
> trying to get other people interested in this topic (the more the merrier)
> and to explain what I'm driving at.
>

Which is exactly why I'm answering. I don't think having additional
committers start working on this topic (instead of focusing on topics that
have a direct impact on a large majority of XWiki users, such as search for
instance) is a good idea.

Guillaume


> FTR here's what we have so far that's finished (and used on xwiki.org):
> * FAQ application
> * JIRA macro
> * IRC Bot (although we still need to fix a few things as Caleb mentioned
> but they are small)
>
> In progress:
> * MailArchive Application from Jeremie
> * Release app (see dev.xwiki.org/xwiki/bin/view/ReleasePlans/WebHome).
> We'll also need to integrate in it the creation of Release Notes as a
> feature.
> * Some Git/Github extension:
> http://extensions.xwiki.org/xwiki/bin/view/Extension/GitHub+Application.
> I'd like to use it on the Hall Of Fame page on xwiki.org
> * and probably some more….
>
> Thanks
> -Vincent
>
> > Thanks
> > -Vincent
> >
> >> My 2 cents,
> >>
> >> Guillaume
> >>
> >> On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]>
> wrote:
> >>
> >>>
> >>> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <
> [hidden email]>
> >>> wrote:
> >>>
> >>>> Hi Vincent,
> >>>>
> >>>>
> >>>> 2012/11/18 Vincent Massol <[hidden email]>
> >>>>
> >>>>> Hi devs,
> >>>>>
> >>>>
> >>>>
> >>>>> *** Latest emails (taken from mailman or other mailing list software,
> >>>>> possibly by subscribing the project to a mailing list so that it gets
> >>> the
> >>>>> emails)
> >>>>>
> >>>>
> >>>>
> >>>>> ** A forum application, for example the Mail Archive Application
> done by
> >>>>> Jeremie which would need to be improved to add ability to post from
> it
> >>>>>
> >>>>
> >>>> Couldn't / shouldn't it be the same thing ?
> >>>> I know the Mail Archive App is not finished at all, but one feature is
> >>>> possibility to generate code to include in pages in order to display
> >>>> filtered lists of emails or topics loaded by the app (filtering by
> >>>> mailing-list, with ordering, max nb, etc…).
> >>>
> >>> Yes, it's the same thing I agree.
> >>>
> >>>> If I may add some comment, it's a very nice idea. To me the biggest
> trap
> >>> is
> >>>> integration with external sources. If it's not easily pluggable /
> >>>> configurable and choice is too restricted, it will attract only a
> little
> >>>> subset of developers. In my office for example, I would use it if I
> could
> >>>> link to Rhodecode or Mercurial (instead of github) and Redmine
> (instead
> >>> of
> >>>> jira).
> >>>
> >>> Yep, we would need contributions for other issue trackers but once we
> >>> start having something it may attract devs to develop other
> integrations.
> >>>
> >>> Thanks
> >>> -Vincent
> >
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

vmassol
Administrator
Hi Guillaume,

I'll stop the discussion here because I don't find it very interesting.

Let's just conclude that in meritocratic open source project the people who decide on the project are the doers… So if you want something, just do it and show the way...

If you're not a doer, you can always whine but it won't do much…

Thanks
-Vincent

On Nov 21, 2012, at 3:08 PM, Guillaume Lerouge <[hidden email]> wrote:

> Hi again,
>
> On Wed, Nov 21, 2012 at 2:58 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>> On Nov 21, 2012, at 2:48 PM, Vincent Massol <[hidden email]> wrote:
>>
>>> On Nov 21, 2012, at 2:33 PM, Guillaume Lerouge <[hidden email]>
>> wrote:
>>>
>>>> Hi Vincent,
>>>>
>>>> if I may, this looks like a common fallacy: developers wanting to build
>>>> tools for developers. Of course building a "XWiki for Software
>> Development"
>>>> flavor will sound sexy to you, since you're a developer yourself as
>> well as
>>>> a XWiki committer. You would be your own target audience. In other
>> words,
>>>> you want to build something for yourself.
>>>
>>> I think that not being a developer you completely miss the point :)
>>>
>>>> However, please note that the market for such tools is already very,
>> very
>>>> crowded.
>>>
>>> Market? Who's talking about marketing/research studies, etc here? :)
>>>
>>>> There's Trac / Bloodhound, there's the whole Atlassian suite,
>>>> there is what Github is building as well as countless other solutions.
>>>>
>>>> One of XWiki's great strengths and differentiators is in its ability to
>> let
>>>> people manage structured and unstructured content easily. I think we
>> should
>>>> keep focusing our work on this instead of trying to enter a crowded
>> space
>>>> with little perceivable benefits
>>>
>>> Who's "we"?
>>>
>>>> . In your mind, is this the very best thing
>>>> we could possibly work on in order to ensure XWiki's long-term success
>> and
>>>> sustainability?
>>>
>>> Definitely.
>>
>> Just to explain: what we need for xwiki's long term success are
>> contributions and who does contributions? Developers. Appealing to them is
>> needed. Right now I've never succeeded in getting any developer interested
>> in XWiki by presenting it to them. I believe that giving them a tool they
>> want to use for their job would make XWiki more appealing to them.
>>
>
> Following this type of logic, if you were working on Microsoft Office you'd
> start adding code-highlighting features in order to make it more appealing
> to developers. Sounds like a great idea, doesn't it?
>
> What matters for the long-term success of any piece of software is to have
> users who love using it. Those users do not necessarily have to be
> developers. Developers tend target platforms where they know they will be
> able to reach numerous users. So I'd go about this the other way: build a
> platform that people love using, and developers will come.
>
>
>> In any case, I'm not proposing some new roadmap or the like. I'm
>> personally going to work on this. Actually I've started working on this as
>> soon as I joined this project several years ago and I'll continue since we
>> need this for ourselves anyway for xwiki.org and that's enough to justify
>> it since we're already spending the time on it. Now with this email I'm
>> trying to get other people interested in this topic (the more the merrier)
>> and to explain what I'm driving at.
>>
>
> Which is exactly why I'm answering. I don't think having additional
> committers start working on this topic (instead of focusing on topics that
> have a direct impact on a large majority of XWiki users, such as search for
> instance) is a good idea.
>
> Guillaume
>
>
>> FTR here's what we have so far that's finished (and used on xwiki.org):
>> * FAQ application
>> * JIRA macro
>> * IRC Bot (although we still need to fix a few things as Caleb mentioned
>> but they are small)
>>
>> In progress:
>> * MailArchive Application from Jeremie
>> * Release app (see dev.xwiki.org/xwiki/bin/view/ReleasePlans/WebHome).
>> We'll also need to integrate in it the creation of Release Notes as a
>> feature.
>> * Some Git/Github extension:
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/GitHub+Application.
>> I'd like to use it on the Hall Of Fame page on xwiki.org
>> * and probably some more….
>>
>> Thanks
>> -Vincent
>>
>>> Thanks
>>> -Vincent
>>>
>>>> My 2 cents,
>>>>
>>>> Guillaume
>>>>
>>>> On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]>
>> wrote:
>>>>
>>>>>
>>>>> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <
>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi Vincent,
>>>>>>
>>>>>>
>>>>>> 2012/11/18 Vincent Massol <[hidden email]>
>>>>>>
>>>>>>> Hi devs,
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> *** Latest emails (taken from mailman or other mailing list software,
>>>>>>> possibly by subscribing the project to a mailing list so that it gets
>>>>> the
>>>>>>> emails)
>>>>>>>
>>>>>>
>>>>>>
>>>>>>> ** A forum application, for example the Mail Archive Application
>> done by
>>>>>>> Jeremie which would need to be improved to add ability to post from
>> it
>>>>>>>
>>>>>>
>>>>>> Couldn't / shouldn't it be the same thing ?
>>>>>> I know the Mail Archive App is not finished at all, but one feature is
>>>>>> possibility to generate code to include in pages in order to display
>>>>>> filtered lists of emails or topics loaded by the app (filtering by
>>>>>> mailing-list, with ordering, max nb, etc…).
>>>>>
>>>>> Yes, it's the same thing I agree.
>>>>>
>>>>>> If I may add some comment, it's a very nice idea. To me the biggest
>> trap
>>>>> is
>>>>>> integration with external sources. If it's not easily pluggable /
>>>>>> configurable and choice is too restricted, it will attract only a
>> little
>>>>>> subset of developers. In my office for example, I would use it if I
>> could
>>>>>> link to Rhodecode or Mercurial (instead of github) and Redmine
>> (instead
>>>>> of
>>>>>> jira).
>>>>>
>>>>> Yep, we would need contributions for other issue trackers but once we
>>>>> start having something it may attract devs to develop other
>> integrations.
>>>>>
>>>>> Thanks
>>>>> -Vincent
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Sergiu Dumitriu-3
On 11/21/2012 09:15 AM, Vincent Massol wrote:
> Hi Guillaume,
>
> I'll stop the discussion here because I don't find it very interesting.
>
> Let's just conclude that in meritocratic open source project the people who decide on the project are the doers… So if you want something, just do it and show the way...
>
> If you're not a doer, you can always whine but it won't do much…

Well said, Vincent.

> Thanks
> -Vincent
>
> On Nov 21, 2012, at 3:08 PM, Guillaume Lerouge <[hidden email]> wrote:
>
>> Hi again,
>>
>> On Wed, Nov 21, 2012 at 2:58 PM, Vincent Massol <[hidden email]> wrote:
>>
>>>
>>> On Nov 21, 2012, at 2:48 PM, Vincent Massol <[hidden email]> wrote:
>>>
>>>> On Nov 21, 2012, at 2:33 PM, Guillaume Lerouge <[hidden email]>
>>> wrote:
>>>>
>>>>> Hi Vincent,
>>>>>
>>>>> if I may, this looks like a common fallacy: developers wanting to build
>>>>> tools for developers. Of course building a "XWiki for Software
>>> Development"
>>>>> flavor will sound sexy to you, since you're a developer yourself as
>>> well as
>>>>> a XWiki committer. You would be your own target audience. In other
>>> words,
>>>>> you want to build something for yourself.
>>>>
>>>> I think that not being a developer you completely miss the point :)
>>>>
>>>>> However, please note that the market for such tools is already very,
>>> very
>>>>> crowded.
>>>>
>>>> Market? Who's talking about marketing/research studies, etc here? :)
>>>>
>>>>> There's Trac / Bloodhound, there's the whole Atlassian suite,
>>>>> there is what Github is building as well as countless other solutions.
>>>>>
>>>>> One of XWiki's great strengths and differentiators is in its ability to
>>> let
>>>>> people manage structured and unstructured content easily. I think we
>>> should
>>>>> keep focusing our work on this instead of trying to enter a crowded
>>> space
>>>>> with little perceivable benefits
>>>>
>>>> Who's "we"?
>>>>
>>>>> . In your mind, is this the very best thing
>>>>> we could possibly work on in order to ensure XWiki's long-term success
>>> and
>>>>> sustainability?
>>>>
>>>> Definitely.
>>>
>>> Just to explain: what we need for xwiki's long term success are
>>> contributions and who does contributions? Developers. Appealing to them is
>>> needed. Right now I've never succeeded in getting any developer interested
>>> in XWiki by presenting it to them. I believe that giving them a tool they
>>> want to use for their job would make XWiki more appealing to them.
>>>

I agree with Vincent. This has also been my vision for a very long time.

And yes, this is *definitely* the *best* thing that we can do to get
XWiki popular/famous, and as a consequence, to get more customers for
all the companies that want to base their business on the XWiki open
source products.

Why? Well, XWiki SAS has been pursuing the same business model for many
years, and while it did grow, I've seen many more open source startups
grow exponentially into multi-million businesses in far shorter times,
and they did that by being popular in the developer community.

>> Following this type of logic, if you were working on Microsoft Office you'd
>> start adding code-highlighting features in order to make it more appealing
>> to developers. Sounds like a great idea, doesn't it?

That's a lame analogy. Although some say that "XWiki is the Excel of the
Web", what does the XWiki Platform have in common with an Office suite?
I've always presented XWiki as a "web application development platform",
and not as a "wiki engine". And a development platform needs development
features.

Feel free to view XWiki any way you want, even as a MS Office
alternative that doesn't need code highlighting, but keep in mind that
you're just one member of the community, and you don't exclusively
control the vision of the project and the direction in which other
community members want to move.


To counter your example even more, MS did go even deeper than code
highlighting in MS Word: they developed an open source (!) Office
extension for AsmL, which allowed researchers to write formal
specifications inside Word documents, and those specifications could be
validated and compiled directly from within Word. Why would they do
that? The official reason for embedding such a feature in Word was that
researchers will write such formal models in their publications anyway,
so why copy/paste them from an external tool when they could write and
validate the models straight in their paper, and reviewers could just
validate the models straight from Word? This wasn't a move toward
attracting a much larger user base than what Word already had, it was a
move with network effects in mind targeting a very very specific
userbase, but with large ripple effects. It was a move toward keeping
researchers using MSOffice, and transitively Windows, instead of other
open source tools that didn't require any MS products, and researchers
and other academic personnel in turn influence a lot of people.

>> What matters for the long-term success of any piece of software is to have
>> users who love using it. Those users do not necessarily have to be
>> developers. Developers tend target platforms where they know they will be
>> able to reach numerous users. So I'd go about this the other way: build a
>> platform that people love using, and developers will come.

Let me remind you that most of the users that you're targeting are
simple users of a customized enterprise solution built by XWiki SAS
employees, hiding all the development features behind easy to use
interfaces. Those kinds of users will rarely be developers. While I
agree in general that building a great solution for users will bring
developers, that won't happen when you dumb down the solution so that no
user will feel the need to tinker with the code, when you hide the fact
that there's even the option of tinkering with the code, and when you
explicitly oppose the idea of becoming more appealing to developers.

How many developers did we get from our enterprise users? I don't
remember any. Almost all the community members that actively participate
in the community are advanced users, sysadmins or developers that use
XWiki as developers, not as end users.

XWiki has great features that excited all the other open source
developers that I've had the chance to talk with, but nobody knows what
XWiki is because so far we've explicitly avoided getting into that
"market". Nobody is working on performance because none of our users are
big enough to need better performance. Put XWiki behind several high
profile communities, and we'll get our performance improved in no time.

>>
>>> In any case, I'm not proposing some new roadmap or the like. I'm
>>> personally going to work on this. Actually I've started working on this as
>>> soon as I joined this project several years ago and I'll continue since we
>>> need this for ourselves anyway for xwiki.org and that's enough to justify
>>> it since we're already spending the time on it. Now with this email I'm
>>> trying to get other people interested in this topic (the more the merrier)
>>> and to explain what I'm driving at.
>>>
>>
>> Which is exactly why I'm answering. I don't think having additional
>> committers start working on this topic (instead of focusing on topics that
>> have a direct impact on a large majority of XWiki users, such as search for
>> instance) is a good idea.

That is your opinion. I think that getting XWiki known in the open
source world is the best way to get new users as well. You think that
clients can only come from marketing campaigns, while I think that
having a product widely adopted by developers is a much better alternative.

Did mysql become a billion dollar company by trying to keep open source
developers away, and targeting only enterprise users that could afford
to pay for it?

I see in XWiki the potential to be the next Ruby on Rails, and RoR is a
successful web application development framework without enterprise
features, yet it still manages to have a lot of monetary value around it.

Another aspect is that many times members of other open source
communities have a day job in another company, and employees that are
good enough to be in an open source community usually have a strong
enough voice in their company to be able to suggest solutions such as
XWiki. If for the next project they have to do they suggest XWiki
instead of Drupal, or if they suggest XWiki Enterprise as a better
alternative to their current intranet solution, it's a win for us. At
least some of those companies will opt for proper support from one of
the companies developing the XWiki software.

I agree that not spreading our development resources too thin is a good
idea, since we don't really have many developers, but I don't agree that
the only "market" for XWiki is the one you see. While the "platform for
developers" market is indeed crowded, this is also a highly dynamic
market where winners change often based on their merits, and I believe
that XWiki has a lot of merits (especially if we fix the performance).

Now, to answer Vincent's original email, I do agree with this proposal,
and frankly it's one that I've been trying to pursue myself since the
beginning, although I've been constantly pushed into other directions.
From now on, I'll work toward making XWiki better for developers.

This is also what I'm thinking of proposing as a talk for FOSDEM.

Some other tools that we could include:

* Poll application for decision making
* Presentation application, plus
* Event organizing and scheduling (we wrote something for the Community
Building and Marketing devroom that I'm co-organizing at FOSDEM)
* The l10n application

>> Guillaume
>>
>>
>>> FTR here's what we have so far that's finished (and used on xwiki.org):
>>> * FAQ application
>>> * JIRA macro
>>> * IRC Bot (although we still need to fix a few things as Caleb mentioned
>>> but they are small)
>>>
>>> In progress:
>>> * MailArchive Application from Jeremie
>>> * Release app (see dev.xwiki.org/xwiki/bin/view/ReleasePlans/WebHome).
>>> We'll also need to integrate in it the creation of Release Notes as a
>>> feature.
>>> * Some Git/Github extension:
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/GitHub+Application.
>>> I'd like to use it on the Hall Of Fame page on xwiki.org
>>> * and probably some more….
>>>
>>> Thanks
>>> -Vincent
>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>> My 2 cents,
>>>>>
>>>>> Guillaume
>>>>>
>>>>> On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]>
>>> wrote:
>>>>>
>>>>>>
>>>>>> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <
>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Vincent,
>>>>>>>
>>>>>>>
>>>>>>> 2012/11/18 Vincent Massol <[hidden email]>
>>>>>>>
>>>>>>>> Hi devs,
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> *** Latest emails (taken from mailman or other mailing list software,
>>>>>>>> possibly by subscribing the project to a mailing list so that it gets
>>>>>> the
>>>>>>>> emails)
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> ** A forum application, for example the Mail Archive Application
>>> done by
>>>>>>>> Jeremie which would need to be improved to add ability to post from
>>> it
>>>>>>>>
>>>>>>>
>>>>>>> Couldn't / shouldn't it be the same thing ?
>>>>>>> I know the Mail Archive App is not finished at all, but one feature is
>>>>>>> possibility to generate code to include in pages in order to display
>>>>>>> filtered lists of emails or topics loaded by the app (filtering by
>>>>>>> mailing-list, with ordering, max nb, etc…).
>>>>>>
>>>>>> Yes, it's the same thing I agree.
>>>>>>
>>>>>>> If I may add some comment, it's a very nice idea. To me the biggest
>>> trap
>>>>>> is
>>>>>>> integration with external sources. If it's not easily pluggable /
>>>>>>> configurable and choice is too restricted, it will attract only a
>>> little
>>>>>>> subset of developers. In my office for example, I would use it if I
>>> could
>>>>>>> link to Rhodecode or Mercurial (instead of github) and Redmine
>>> (instead
>>>>>> of
>>>>>>> jira).
>>>>>>
>>>>>> Yep, we would need contributions for other issue trackers but once we
>>>>>> start having something it may attract devs to develop other
>>> integrations.
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent


--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Sergiu Dumitriu-3
In reply to this post by Guillaume Lerouge
On 11/21/2012 08:33 AM, Guillaume Lerouge wrote:

> Hi Vincent,
>
> if I may, this looks like a common fallacy: developers wanting to build
> tools for developers. Of course building a "XWiki for Software Development"
> flavor will sound sexy to you, since you're a developer yourself as well as
> a XWiki committer. You would be your own target audience. In other words,
> you want to build something for yourself.
>
> However, please note that the market for such tools is already very, very
> crowded. There's Trac / Bloodhound, there's the whole Atlassian suite,
> there is what Github is building as well as countless other solutions.

What Vincent proposed doesn't fit into the same category. It's an
all-in-one site for an open source project, offering either simple
alternatives or just integration with other tools. We're not replacing
GitHub, we're just offering a quick view of the project's status on the
home page of your project. We're not replacing mail servers, we're just
mirroring mailing lists. We're not replacing Jira or Bugzilla or the
simple GitHub issues, we're offering a way to embed statistics from an
issue tracker into your roadmap page from the wiki. And so on. All this
without having to visit several different sites just to see what's new
on different levels. Kind of a portal.

But if a tool is specific enough and not so feature-rich, like a simple
poll, why use yet another tool when the wiki provides a simple
alternative? Tool proliferation is dreaded by everyone.

> One of XWiki's great strengths and differentiators is in its ability to let
> people manage structured and unstructured content easily. I think we should
> keep focusing our work on this instead of trying to enter a crowded space
> with little perceivable benefits. In your mind, is this the very best thing
> we could possibly work on in order to ensure XWiki's long-term success and
> sustainability?
>
> My 2 cents,
>
> Guillaume
>
> On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <[hidden email]>
>> wrote:
>>
>>> Hi Vincent,
>>>
>>>
>>> 2012/11/18 Vincent Massol <[hidden email]>
>>>
>>>> Hi devs,
>>>>
>>>
>>>
>>>> *** Latest emails (taken from mailman or other mailing list software,
>>>> possibly by subscribing the project to a mailing list so that it gets
>> the
>>>> emails)
>>>>
>>>
>>>
>>>> ** A forum application, for example the Mail Archive Application done by
>>>> Jeremie which would need to be improved to add ability to post from it
>>>>
>>>
>>> Couldn't / shouldn't it be the same thing ?
>>> I know the Mail Archive App is not finished at all, but one feature is
>>> possibility to generate code to include in pages in order to display
>>> filtered lists of emails or topics loaded by the app (filtering by
>>> mailing-list, with ordering, max nb, etc…).
>>
>> Yes, it's the same thing I agree.
>>
>>> If I may add some comment, it's a very nice idea. To me the biggest trap
>> is
>>> integration with external sources. If it's not easily pluggable /
>>> configurable and choice is too restricted, it will attract only a little
>>> subset of developers. In my office for example, I would use it if I could
>>> link to Rhodecode or Mercurial (instead of github) and Redmine (instead
>> of
>>> jira).
>>
>> Yep, we would need contributions for other issue trackers but once we
>> start having something it may attract devs to develop other integrations.
>>
>> Thanks
>> -Vincent

--
Sergiu Dumitriu
http://purl.org/net/sergiu
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

vmassol
Administrator
Just to make sure my intent is clear with this idea email, here are my main points:

* This idea is *not* about dropping what we're already doing. It's not even about putting this in the roadmap. We definitely need to fix things that don't work well in XWiki (search, etc).

* I posted this idea because this is something I believe in and I've started working on it several years ago. The reason it's not fully there already is because I'm spending most of my time working on day to day stuff like fixing bugs, improving quality, and generally speaking following the agreed roadmap.

* We need this for ourselves anyway since we're development project and we need those tools (FAQ, Release app, IRCBot app, JIRA macro, Dev Stats, etc).

* The goal of this idea is not so much to attract committers but more to expand the XWiki ecosystem of extensions. The persons developing extensions are mostly developers and we need a strong ecosystem of extensions. IMO this is what can make a difference in how XWiki is known in the world.

Thanks
-Vincent

On Dec 5, 2012, at 2:57 AM, Sergiu Dumitriu <[hidden email]> wrote:

> On 11/21/2012 08:33 AM, Guillaume Lerouge wrote:
>> Hi Vincent,
>>
>> if I may, this looks like a common fallacy: developers wanting to build
>> tools for developers. Of course building a "XWiki for Software Development"
>> flavor will sound sexy to you, since you're a developer yourself as well as
>> a XWiki committer. You would be your own target audience. In other words,
>> you want to build something for yourself.
>>
>> However, please note that the market for such tools is already very, very
>> crowded. There's Trac / Bloodhound, there's the whole Atlassian suite,
>> there is what Github is building as well as countless other solutions.
>
> What Vincent proposed doesn't fit into the same category. It's an
> all-in-one site for an open source project, offering either simple
> alternatives or just integration with other tools. We're not replacing
> GitHub, we're just offering a quick view of the project's status on the
> home page of your project. We're not replacing mail servers, we're just
> mirroring mailing lists. We're not replacing Jira or Bugzilla or the
> simple GitHub issues, we're offering a way to embed statistics from an
> issue tracker into your roadmap page from the wiki. And so on. All this
> without having to visit several different sites just to see what's new
> on different levels. Kind of a portal.
>
> But if a tool is specific enough and not so feature-rich, like a simple
> poll, why use yet another tool when the wiki provides a simple
> alternative? Tool proliferation is dreaded by everyone.
>
>> One of XWiki's great strengths and differentiators is in its ability to let
>> people manage structured and unstructured content easily. I think we should
>> keep focusing our work on this instead of trying to enter a crowded space
>> with little perceivable benefits. In your mind, is this the very best thing
>> we could possibly work on in order to ensure XWiki's long-term success and
>> sustainability?
>>
>> My 2 cents,
>>
>> Guillaume
>>
>> On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]> wrote:
>>
>>>
>>> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <[hidden email]>
>>> wrote:
>>>
>>>> Hi Vincent,
>>>>
>>>>
>>>> 2012/11/18 Vincent Massol <[hidden email]>
>>>>
>>>>> Hi devs,
>>>>>
>>>>
>>>>
>>>>> *** Latest emails (taken from mailman or other mailing list software,
>>>>> possibly by subscribing the project to a mailing list so that it gets
>>> the
>>>>> emails)
>>>>>
>>>>
>>>>
>>>>> ** A forum application, for example the Mail Archive Application done by
>>>>> Jeremie which would need to be improved to add ability to post from it
>>>>>
>>>>
>>>> Couldn't / shouldn't it be the same thing ?
>>>> I know the Mail Archive App is not finished at all, but one feature is
>>>> possibility to generate code to include in pages in order to display
>>>> filtered lists of emails or topics loaded by the app (filtering by
>>>> mailing-list, with ordering, max nb, etc…).
>>>
>>> Yes, it's the same thing I agree.
>>>
>>>> If I may add some comment, it's a very nice idea. To me the biggest trap
>>> is
>>>> integration with external sources. If it's not easily pluggable /
>>>> configurable and choice is too restricted, it will attract only a little
>>>> subset of developers. In my office for example, I would use it if I could
>>>> link to Rhodecode or Mercurial (instead of github) and Redmine (instead
>>> of
>>>> jira).
>>>
>>> Yep, we would need contributions for other issue trackers but once we
>>> start having something it may attract devs to develop other integrations.
>>>
>>> Thanks
>>> -Vincent
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Caleb James DeLisle
In reply to this post by Guillaume Lerouge
Hi,

In defense of Guillaume's position, developers are the worst group to market
to, we want tools to get out of our way but provide everything we need, we
want our tools to be fast and we want to extend them using <favorite language>
and possibly would not even review a solution which wasn't written in that
language. We do not tolerate imperfection (and use the word 'sucks' often).
Even JIRA is not marketed to developers but rather to the managers who guard
over them.

One of XWiki's big selling points in my opinion is that it is open source so
you're not going to end up in integration hell because the company needs
specialized business software and their intranet solution refuses to talk to
it.

If we can use XWikiDev as a way to wear the system integrator hat then we get
the best of dogfooding while producing a suite of extensions which might come
in handy to some of our users.

Overall I'd give this a cautious +1

Thanks,
Caleb


On 11/21/2012 09:00 AM, Guillaume Lerouge wrote:

> Hi Vincent,
>
> On Wed, Nov 21, 2012 at 2:48 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>> On Nov 21, 2012, at 2:33 PM, Guillaume Lerouge <[hidden email]>
>> wrote:
>>
>>> Hi Vincent,
>>>
>>> if I may, this looks like a common fallacy: developers wanting to build
>>> tools for developers. Of course building a "XWiki for Software
>> Development"
>>> flavor will sound sexy to you, since you're a developer yourself as well
>> as
>>> a XWiki committer. You would be your own target audience. In other words,
>>> you want to build something for yourself.
>>
>> I think that not being a developer you completely miss the point :)
>>
>
> Of course.
>
>> However, please note that the market for such tools is already very, very
>>> crowded.
>>
>> Market? Who's talking about marketing/research studies, etc here? :)
>>
>
> As a developer, you're (presumably) writing software for an audience, with
> the hope that members of this audience ("users") will some day use it.
>
> I used the word "market" in that sense.
>
>
>>> There's Trac / Bloodhound, there's the whole Atlassian suite,
>>> there is what Github is building as well as countless other solutions.
>>>
>>> One of XWiki's great strengths and differentiators is in its ability to
>> let
>>> people manage structured and unstructured content easily. I think we
>> should
>>> keep focusing our work on this instead of trying to enter a crowded space
>>> with little perceivable benefits
>>
>> Who's "we"?
>>
>
> Members of the XWiki.org community.
>
> Guillaume
>
>> . In your mind, is this the very best thing
>>> we could possibly work on in order to ensure XWiki's long-term success
>> and
>>> sustainability?
>>
>> Definitely.
>>
>
> Not "one of the best things", "the very best thing". There is nothing else
> that could possibly be appealing to a wider audience and would thus
> guarantee the long-term sustainability of XWiki software?
>
> Guillaume
>
> Thanks
>> -Vincent
>>
>>> My 2 cents,
>>>
>>> Guillaume
>>>
>>> On Wed, Nov 21, 2012 at 1:20 PM, Vincent Massol <[hidden email]>
>> wrote:
>>>
>>>>
>>>> On Nov 21, 2012, at 12:40 PM, Jeremie BOUSQUET <
>> [hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Vincent,
>>>>>
>>>>>
>>>>> 2012/11/18 Vincent Massol <[hidden email]>
>>>>>
>>>>>> Hi devs,
>>>>>>
>>>>>
>>>>>
>>>>>> *** Latest emails (taken from mailman or other mailing list software,
>>>>>> possibly by subscribing the project to a mailing list so that it gets
>>>> the
>>>>>> emails)
>>>>>>
>>>>>
>>>>>
>>>>>> ** A forum application, for example the Mail Archive Application done
>> by
>>>>>> Jeremie which would need to be improved to add ability to post from it
>>>>>>
>>>>>
>>>>> Couldn't / shouldn't it be the same thing ?
>>>>> I know the Mail Archive App is not finished at all, but one feature is
>>>>> possibility to generate code to include in pages in order to display
>>>>> filtered lists of emails or topics loaded by the app (filtering by
>>>>> mailing-list, with ordering, max nb, etc…).
>>>>
>>>> Yes, it's the same thing I agree.
>>>>
>>>>> If I may add some comment, it's a very nice idea. To me the biggest
>> trap
>>>> is
>>>>> integration with external sources. If it's not easily pluggable /
>>>>> configurable and choice is too restricted, it will attract only a
>> little
>>>>> subset of developers. In my office for example, I would use it if I
>> could
>>>>> link to Rhodecode or Mercurial (instead of github) and Redmine (instead
>>>> of
>>>>> jira).
>>>>
>>>> Yep, we would need contributions for other issue trackers but once we
>>>> start having something it may attract devs to develop other
>> integrations.
>>>>
>>>> Thanks
>>>> -Vincent
>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>


_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Fabio Mancinelli-4
In reply to this post by vmassol
Hi devs,

I am reviving this thread because in one of the collaborative R&D
project we are carrying on at XWikiSAS we might address some of the
points stated into this mail.

The project I am talking about is RISCOSS
(http://riscoss.eu/bin/view/Main/) which aims at performing risk and
cost analysis of OSS in order to help decision makers to adopt OSS in
their environment.
There's a lot of things in this project that are marginally relevant
for XWiki and XWiki Project Development Flavor, but one thing that
imho matches part of the goal stated in this thread is that in order
to evaluate the risk and cost of an OSS you must start from the OSS
project by gathering and analysing project's data.

So in an ideal RISCOSS-Platform users might create "OSS projects
descriptors" and associate to them data sources where interesting data
can be harvested and presented to the user (...and also to automatic
tools that are in charge of performing advanced mumbo-jumbo :))

This looks very similar to one of the point about "dashboard metrics
of your project" where ideally you can have plugins scanning data from
different data sources (git, mailing lists, IRC, Sonar, Jenkins,
whatever) and organize it in nice dashboards.

In RISCOSS probably we'll need to address more problems (e.g., how
much to collect and where to store the data) but I think that the
high-level feature is almost the same in the two cases.

I am open to suggestions and discussions and I'll try to keep you
posted as the project advances.

Thanks,
Fabio


On Sun, Nov 18, 2012 at 11:11 AM, Vincent Massol <[hidden email]> wrote:

> Hi devs,
>
> I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/) and this reminded of this idea I've had several times in the past: Creating a Project Development Flavor of XE. I mentioned it in some other email already but I wanted to see if this excites you as much as it does for me and maybe we could brainstorm in this thread about what it could be like .
>
> Some scattered thoughts:
>
> * First, from the point of view of the XWiki project I believe it could be a game changer if we did it right since it has the potential of being adopted by projects around the world and thus making them discover xwiki as a result. And since they're developers they would be able to take advantage of XWiki's development features and contribute back to the project through extensions for example.
>
> * Ideally it would be awesome that this project be started independently of the XWiki project I think and just use XWiki as the platform since it's a full fledged project with a different goal than the XWiki project itself.
>
> * We need to finish the Flavor idea by allowing the DM to list flavors.
>
> * Some ideas of content for this Development Project flavor:
> ** A home page dashboard about metrics of your project. These metrics would be retried from external sources. Examples:
> *** Statistics about commits using Git/GitHub
> *** Latest emails (taken from mailman or other mailing list software, possibly by subscribing the project to a mailing list so that it gets the emails)
> *** Latest issues (taken from JIRA for example)
> *** Screenshot example: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#HCommunityHome
> ** A Release application to help perform releases
> ** A forum application, for example the Mail Archive Application done by Jeremie which would need to be improved to add ability to post from it
> ** A Release notes application
> ** The Blog application
> ** Ability to generate a whole PDF for the project's documentation for a given version
> ** A modern and nice skin (either Lyrebird or the new Skin proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x)
> ** A layout configured for the flavor
> ** Future: a simple issue tracker (or integrate one) for those who want an all-in-one solution. However keep the external issue tracker possibility for those already having an issue tracker
> ** Some predefined templates for creating well known project pages: source repository, build, hall in fame, project documentation home page, etc
> ** The IRC Bot application
> ** Bundle the JIRA macro
> ** Bundle the FAQ application
> ** A Roadmap application
>
> * Of course we should use this flavor on xwiki.org itself. And we could move some of the modules we currently have in platform and that would make more sense there (jira macro, IRC Bot application, FAQ application, etc).
>
> WDYT?
>
> Add your ideas to this email thread or, better, on http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Idea] XWiki Project Development Flavor

Ecaterina Moraru (Valica)
Hi Fabio,

I just want to share some work I did related to this subject.

* My vision of what extensions we could use for this "Project Development
Flavor" and the current XWiki.org status
https://docs.google.com/spreadsheet/ccc?key=0AnlUBgkhiZA8dElwbEVmUjJnbEhFOUFGYU1ubWlMa1E&usp=sharing

* Vincent's 'initia'l vision
http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor

* XWiki.org websites proposals
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgHomepage

* A more generic development flavor 'Application Development Flavor'
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AppDevelopmentFlavor

Hope this helps,
Caty

On Thu, Jul 4, 2013 at 12:56 PM, Fabio Mancinelli <
[hidden email]> wrote:

> Hi devs,
>
> I am reviving this thread because in one of the collaborative R&D
> project we are carrying on at XWikiSAS we might address some of the
> points stated into this mail.
>
> The project I am talking about is RISCOSS
> (http://riscoss.eu/bin/view/Main/) which aims at performing risk and
> cost analysis of OSS in order to help decision makers to adopt OSS in
> their environment.
> There's a lot of things in this project that are marginally relevant
> for XWiki and XWiki Project Development Flavor, but one thing that
> imho matches part of the goal stated in this thread is that in order
> to evaluate the risk and cost of an OSS you must start from the OSS
> project by gathering and analysing project's data.
>
> So in an ideal RISCOSS-Platform users might create "OSS projects
> descriptors" and associate to them data sources where interesting data
> can be harvested and presented to the user (...and also to automatic
> tools that are in charge of performing advanced mumbo-jumbo :))
>
> This looks very similar to one of the point about "dashboard metrics
> of your project" where ideally you can have plugins scanning data from
> different data sources (git, mailing lists, IRC, Sonar, Jenkins,
> whatever) and organize it in nice dashboards.
>
> In RISCOSS probably we'll need to address more problems (e.g., how
> much to collect and where to store the data) but I think that the
> high-level feature is almost the same in the two cases.
>
> I am open to suggestions and discussions and I'll try to keep you
> posted as the project advances.
>
> Thanks,
> Fabio
>
>
> On Sun, Nov 18, 2012 at 11:11 AM, Vincent Massol <[hidden email]>
> wrote:
> > Hi devs,
> >
> > I've noticed Apache BloodHound (https://issues.apache.org/bloodhound/)
> and this reminded of this idea I've had several times in the past: Creating
> a Project Development Flavor of XE. I mentioned it in some other email
> already but I wanted to see if this excites you as much as it does for me
> and maybe we could brainstorm in this thread about what it could be like .
> >
> > Some scattered thoughts:
> >
> > * First, from the point of view of the XWiki project I believe it could
> be a game changer if we did it right since it has the potential of being
> adopted by projects around the world and thus making them discover xwiki as
> a result. And since they're developers they would be able to take advantage
> of XWiki's development features and contribute back to the project through
> extensions for example.
> >
> > * Ideally it would be awesome that this project be started independently
> of the XWiki project I think and just use XWiki as the platform since it's
> a full fledged project with a different goal than the XWiki project itself.
> >
> > * We need to finish the Flavor idea by allowing the DM to list flavors.
> >
> > * Some ideas of content for this Development Project flavor:
> > ** A home page dashboard about metrics of your project. These metrics
> would be retried from external sources. Examples:
> > *** Statistics about commits using Git/GitHub
> > *** Latest emails (taken from mailman or other mailing list software,
> possibly by subscribing the project to a mailing list so that it gets the
> emails)
> > *** Latest issues (taken from JIRA for example)
> > *** Screenshot example:
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2#HCommunityHome
> > ** A Release application to help perform releases
> > ** A forum application, for example the Mail Archive Application done by
> Jeremie which would need to be improved to add ability to post from it
> > ** A Release notes application
> > ** The Blog application
> > ** Ability to generate a whole PDF for the project's documentation for a
> given version
> > ** A modern and nice skin (either Lyrebird or the new Skin proposal:
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin4x)
> > ** A layout configured for the flavor
> > ** Future: a simple issue tracker (or integrate one) for those who want
> an all-in-one solution. However keep the external issue tracker possibility
> for those already having an issue tracker
> > ** Some predefined templates for creating well known project pages:
> source repository, build, hall in fame, project documentation home page, etc
> > ** The IRC Bot application
> > ** Bundle the JIRA macro
> > ** Bundle the FAQ application
> > ** A Roadmap application
> >
> > * Of course we should use this flavor on xwiki.org itself. And we could
> move some of the modules we currently have in platform and that would make
> more sense there (jira macro, IRC Bot application, FAQ application, etc).
> >
> > WDYT?
> >
> > Add your ideas to this email thread or, better, on
> http://dev.xwiki.org/xwiki/bin/view/Design/DevelopmentFlavor
> >
> > Thanks
> > -Vincent
> >
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs