[xwiki-devs] Fwd: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension.
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension.
Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's
Not sure it's a good thing. I'm sure Vincent will agree
Ludovic
Envoyé de mon iPhone
Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit :
One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;)
Thanks Caleb
On 10/22/2012 10:14 PM, Caleb James DeLisle wrote:
Hi,
Thanks for the complement.
I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user.
Thanks, Caleb
On 10/19/2012 07:59 AM, Ryszard Łach wrote:
Great work!
It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements?
R.
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs
Envoyé de mon iPhone
Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension.
Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's
Not sure it's a good thing. I'm sure Vincent will agree
Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think. Thanks -Vincent
Ludovic
Envoyé de mon iPhone
Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit :
One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;)
Thanks Caleb
On 10/22/2012 10:14 PM, Caleb James DeLisle wrote:
Hi,
Thanks for the complement.
I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user.
Thanks, Caleb
On 10/19/2012 07:59 AM, Ryszard Łach wrote:
Great work!
It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements?
R.
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent, This is a interesting topic and there are several aspects to it. For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.). That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc. Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example). The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). Jerome
Thanks -Vincent
Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit :
One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote:
Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote:
Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hello, My opinion of github is not very bright, there's vender lockin because you can't easily migrate issues and other value addeds and they don't open source their platform so while git allows you to push somewhere else, you can't have the nice web interface with the features without going through them. That said, it is hard to argue with 3 clicks and a `git push`. While it would be easy to dismiss me as "lazy", I see this dismissal as a huge problem for the free software movement in general. Why should an ordinary person ask for permission to use xwiki-contrib then make sure their pom.xml parent ID is in order when they could just do 3 clicks and a git push? Granted XWiki is far better off than some projects, when I see copyright release forms and patent non-infringement statements which have to be signed, I find it mindboggling that anyone would contribute to these projects at all given all of the roadblocks which have been erected. A good example of a social good also being more useful is Linux. I love Linux, it is free software and it is fast, even the giants such as Microsoft and Apple can't afford to outspend the army of companies who pour money into profiling, tweaking, optimizing, and refactoring Linux and the result is a network stack which blows the doors off of everyone else in the market. And it got that way being free. Now the question of how we should make xwiki-contrib more attractive than $THE_OTHER_GUY is worth asking. It is better for the contributor, they get continuous integration and issue tracking, but none of it is automated. Since we're all pretty busy and automating this process is probably not on anybody's roadmap, I think we're going to have to accept that it's easier to start off a small project in one's own namespace and then move when it grows and the contributor wants to take advantage of the services in xwiki-contrib. If we don't at least understand this fundamental issue then the githubs and facebooks of the world with their 1 click walled gardens will win. Thanks, Caleb On 11/05/2012 04:02 AM, Jerome Velociter wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/).
Jerome
Thanks -Vincent
Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit :
One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote:
Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: > Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caleb and all, On Nov 5, 2012, at 2:07 PM, Caleb James DeLisle <[email protected]> wrote:
Hello,
My opinion of github is not very bright, there's vender lockin because you can't easily migrate issues and other value addeds and they don't open source their platform so while git allows you to push somewhere else, you can't have the nice web interface with the features without going through them.
That said, it is hard to argue with 3 clicks and a `git push`.
While it would be easy to dismiss me as "lazy", I see this dismissal as a huge problem for the free software movement in general. Why should an ordinary person ask for permission to use xwiki-contrib then make sure their pom.xml parent ID is in order when they could just do 3 clicks and a git push?
Because you get a lot more by being an xwiki-contrib project: * CI * Mailing list email notification * Maven repository where to release versions * JIRA, Wiki page (which you also get with github but that's about it) * Sonar dashboard (coming up ;)) * Ability to collaborate with others through a mailing list and more generally collaborate as equals with others rather than in a "creator/second level citizen" mode * Quality stats on xwiki.org on the hall of fame page (needs to be improved) * More visibility since we reference xwiki contribs projects on xwiki.org even more than pure extensions. Note that we need to improve this part which is not fully true ATM but which we could easily make true * More generally ability to benefit from best of breed tools that xwiki.org offers and continue to update/improve in general
Granted XWiki is far better off than some projects, when I see copyright release forms and patent non-infringement statements which have to be signed, I find it mindboggling that anyone would contribute to these projects at all given all of the roadblocks which have been erected.
Actually we might have to do something about CLA in the future...
A good example of a social good also being more useful is Linux. I love Linux, it is free software and it is fast, even the giants such as Microsoft and Apple can't afford to outspend the army of companies who pour money into profiling, tweaking, optimizing, and refactoring Linux and the result is a network stack which blows the doors off of everyone else in the market. And it got that way being free.
Now the question of how we should make xwiki-contrib more attractive than $THE_OTHER_GUY is worth asking. It is better for the contributor, they get continuous integration and issue tracking, but none of it is automated. Since we're all pretty busy and automating this process is probably not on anybody's roadmap, I think we're going to have to accept that it's easier to start off a small project in one's own namespace and then move when it grows and the contributor wants to take advantage of the services in xwiki-contrib.
I don't really agree here. For a user asking to be on xwiki-contrib it's pretty easy and all the work is done for them by xwiki committers. It would need to be automated for xwiki committers' sake but not for the users asking ;)
If we don't at least understand this fundamental issue then the githubs and facebooks of the world with their 1 click walled gardens will win.
I think the list I've put above is pretty interesting for any project and it can only grow as we improve our forge in the future. The biggest improvement would probably be to offer a full wiki configured as a dev project flavor for contrib projects which would contain (for ex): - A dashboard with would have gadgets listing: latest jira issues, contributors of the project, sonar quality gadgets, latest blog posts of the project, etc - A Release application (similar to the one we have on dev.xwiki.org) - A FAQ application - Git stats using our Github Application - Mailing list/forum application (the one Jeremie is working on :)) - etc Thanks -Vincent
Thanks, Caleb
On 11/05/2012 04:02 AM, Jerome Velociter wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/).
Jerome
Thanks -Vincent
Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit :
One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: > Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, > Ryszard Łach wrote: >> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
On Nov 7, 2012, at 9:13 AM, Vincent Massol <[email protected]> wrote:
Hi Caleb and all,
On Nov 5, 2012, at 2:07 PM, Caleb James DeLisle <[email protected]> wrote:
Hello,
My opinion of github is not very bright, there's vender lockin because you can't easily migrate issues and other value addeds and they don't open source their platform so while git allows you to push somewhere else, you can't have the nice web interface with the features without going through them.
That said, it is hard to argue with 3 clicks and a `git push`.
While it would be easy to dismiss me as "lazy", I see this dismissal as a huge problem for the free software movement in general. Why should an ordinary person ask for permission to use xwiki-contrib then make sure their pom.xml parent ID is in order when they could just do 3 clicks and a git push?
Because you get a lot more by being an xwiki-contrib project: * CI * Mailing list email notification * Maven repository where to release versions * JIRA, Wiki page (which you also get with github but that's about it) * Sonar dashboard (coming up ;)) * Ability to collaborate with others through a mailing list and more generally collaborate as equals with others rather than in a "creator/second level citizen" mode * Quality stats on xwiki.org on the hall of fame page (needs to be improved) * More visibility since we reference xwiki contribs projects on xwiki.org even more than pure extensions. Note that we need to improve this part which is not fully true ATM but which we could easily make true * More generally ability to benefit from best of breed tools that xwiki.org offers and continue to update/improve in general
Jerome, isn't this compelling to you?
Granted XWiki is far better off than some projects, when I see copyright release forms and patent non-infringement statements which have to be signed, I find it mindboggling that anyone would contribute to these projects at all given all of the roadblocks which have been erected.
Actually we might have to do something about CLA in the future...
A good example of a social good also being more useful is Linux. I love Linux, it is free software and it is fast, even the giants such as Microsoft and Apple can't afford to outspend the army of companies who pour money into profiling, tweaking, optimizing, and refactoring Linux and the result is a network stack which blows the doors off of everyone else in the market. And it got that way being free.
Now the question of how we should make xwiki-contrib more attractive than $THE_OTHER_GUY is worth asking. It is better for the contributor, they get continuous integration and issue tracking, but none of it is automated. Since we're all pretty busy and automating this process is probably not on anybody's roadmap, I think we're going to have to accept that it's easier to start off a small project in one's own namespace and then move when it grows and the contributor wants to take advantage of the services in xwiki-contrib.
I don't really agree here. For a user asking to be on xwiki-contrib it's pretty easy and all the work is done for them by xwiki committers. It would need to be automated for xwiki committers' sake but not for the users asking ;)
If we don't at least understand this fundamental issue then the githubs and facebooks of the world with their 1 click walled gardens will win.
I think the list I've put above is pretty interesting for any project and it can only grow as we improve our forge in the future. The biggest improvement would probably be to offer a full wiki configured as a dev project flavor for contrib projects which would contain (for ex): - A dashboard with would have gadgets listing: latest jira issues, contributors of the project, sonar quality gadgets, latest blog posts of the project, etc - A Release application (similar to the one we have on dev.xwiki.org) - A FAQ application - Git stats using our Github Application - Mailing list/forum application (the one Jeremie is working on :)) - etc
Jerome, would that be compelling enough? If not, what would make you want to be an xwiki-contrib project? :) One-click release maybe? ;) (note that for the maven part this is probably possible through Jenkins) Thanks -Vincent
Thanks -Vincent
Thanks, Caleb
On 11/05/2012 04:02 AM, Jerome Velociter wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/).
Jerome
Thanks -Vincent
Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : > One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, >> Ryszard Łach wrote: >>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
On 11/07/2012 09:35 AM, Vincent Massol wrote: > On Nov 7, 2012, at 9:13 AM, Vincent Massol <[email protected]> wrote: > >> Hi Caleb and all, >> >> On Nov 5, 2012, at 2:07 PM, Caleb James DeLisle <[email protected]> wrote: >> >>> Hello, >>> >>> My opinion of github is not very bright, there's vender lockin because you can't easily migrate >>> issues and other value addeds and they don't open source their platform so while git allows you >>> to push somewhere else, you can't have the nice web interface with the features without going through >>> them. >>> >>> That said, it is hard to argue with 3 clicks and a `git push`. >>> >>> While it would be easy to dismiss me as "lazy", I see this dismissal as a huge problem for the free >>> software movement in general. Why should an ordinary person ask for permission to use xwiki-contrib >>> then make sure their pom.xml parent ID is in order when they could just do 3 clicks and a git push? >> Because you get a lot more by being an xwiki-contrib project: >> * CI >> * Mailing list email notification >> * Maven repository where to release versions >> * JIRA, Wiki page (which you also get with github but that's about it) >> * Sonar dashboard (coming up ;)) >> * Ability to collaborate with others through a mailing list and more generally collaborate as equals with others rather than in a "creator/second level citizen" mode >> * Quality stats on xwiki.org on the hall of fame page (needs to be improved) >> * More visibility since we reference xwiki contribs projects on xwiki.org even more than pure extensions. Note that we need to improve this part which is not fully true ATM but which we could easily make true >> * More generally ability to benefit from best of breed tools that xwiki.org offers and continue to update/improve in general > Jerome, isn't this compelling to you? > >>> Granted XWiki is far better off than some projects, when I see copyright release forms and patent >>> non-infringement statements which have to be signed, I find it mindboggling that anyone would contribute >>> to these projects at all given all of the roadblocks which have been erected. >> Actually we might have to do something about CLA in the future... >> >>> A good example of a social good also being more useful is Linux. I love Linux, it is free software and >>> it is fast, even the giants such as Microsoft and Apple can't afford to outspend the army of companies >>> who pour money into profiling, tweaking, optimizing, and refactoring Linux and the result is a network >>> stack which blows the doors off of everyone else in the market. And it got that way being free. >>> >>> Now the question of how we should make xwiki-contrib more attractive than $THE_OTHER_GUY is worth asking. >>> It is better for the contributor, they get continuous integration and issue tracking, but none of it is >>> automated. Since we're all pretty busy and automating this process is probably not on anybody's roadmap, >>> I think we're going to have to accept that it's easier to start off a small project in one's own namespace >>> and then move when it grows and the contributor wants to take advantage of the services in xwiki-contrib. >> I don't really agree here. For a user asking to be on xwiki-contrib it's pretty easy and all the work is done for them by xwiki committers. It would need to be automated for xwiki committers' sake but not for the users asking ;) >> >>> If we don't at least understand this fundamental issue then the githubs and facebooks of the world with >>> their 1 click walled gardens will win. >> I think the list I've put above is pretty interesting for any project and it can only grow as we improve our forge in the future. The biggest improvement would probably be to offer a full wiki configured as a dev project flavor for contrib projects which would contain (for ex): >> - A dashboard with would have gadgets listing: latest jira issues, contributors of the project, sonar quality gadgets, latest blog posts of the project, etc >> - A Release application (similar to the one we have on dev.xwiki.org) >> - A FAQ application >> - Git stats using our Github Application >> - Mailing list/forum application (the one Jeremie is working on :)) >> - etc > Jerome, would that be compelling enough? If not, what would make you want to be an xwiki-contrib project? :) Yes it's very nice, especially for big(ger) projects. For a lot of projects, it's also too much tooling IMO (but of course one can use just a subset). TBH I don't think that not wanting to be an XWiki contrib project is an issue that we should try to address (bringing more tools for example). Personnally I'll continue to have some projects under xwiki-contrib and others under other umbrellas, depending of where I see them fit. Jerome. > > One-click release maybe? ;) (note that for the maven part this is probably possible through Jenkins) > > Thanks > -Vincent > >> Thanks >> -Vincent >> >>> Thanks, >>> Caleb >>> >>> >>> On 11/05/2012 04:02 AM, Jerome Velociter wrote: >>>> On 10/23/2012 09:33 AM, Vincent Massol wrote: >>>>> On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote: >>>>>> This should have been for devs Envoyé de mon iPhone Début du message transféré : >>>>>>> Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree >>>>> Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project >>>>> in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib >>>>> is better with the 2 arguments listed above. Jerome, Caleb let me know what you think. >>>> >>>> Hi Vincent, >>>> >>>> This is a interesting topic and there are several aspects to it. >>>> >>>> For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.). >>>> >>>> That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc. >>>> >>>> Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : >>>> - use of own tools and own workflow (github issues vs. JIRA for example). >>>> - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example). >>>> >>>> The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? >>>> If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). >>>> >>>> Jerome >>>> >>>> >>>>> Thanks -Vincent >>>>>>> Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : >>>>>>>> One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >>>>>>>>> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, >>>>>>>>> Ryszard Łach wrote: >>>>>>>>>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R. >>>>> _______________________________________________ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
On 11/07/2012 03:13 AM, Vincent Massol wrote:
Hi Caleb and all,
On Nov 5, 2012, at 2:07 PM, Caleb James DeLisle <[email protected]> wrote:
Hello,
My opinion of github is not very bright, there's vender lockin because you can't easily migrate issues and other value addeds and they don't open source their platform so while git allows you to push somewhere else, you can't have the nice web interface with the features without going through them.
That said, it is hard to argue with 3 clicks and a `git push`.
While it would be easy to dismiss me as "lazy", I see this dismissal as a huge problem for the free software movement in general. Why should an ordinary person ask for permission to use xwiki-contrib then make sure their pom.xml parent ID is in order when they could just do 3 clicks and a git push?
Because you get a lot more by being an xwiki-contrib project: * CI * Mailing list email notification * Maven repository where to release versions * JIRA, Wiki page (which you also get with github but that's about it) * Sonar dashboard (coming up ;)) * Ability to collaborate with others through a mailing list and more generally collaborate as equals with others rather than in a "creator/second level citizen" mode * Quality stats on xwiki.org on the hall of fame page (needs to be improved) * More visibility since we reference xwiki contribs projects on xwiki.org even more than pure extensions. Note that we need to improve this part which is not fully true ATM but which we could easily make true * More generally ability to benefit from best of breed tools that xwiki.org offers and continue to update/improve in general
These are all great value-addeds, two problems are they aren't very useful until a project becomes somewhat established and they are a bit dispersed. Just having an xwiki-contrib control panel with links to each of these things would be a big step.
Granted XWiki is far better off than some projects, when I see copyright release forms and patent non-infringement statements which have to be signed, I find it mindboggling that anyone would contribute to these projects at all given all of the roadblocks which have been erected.
Actually we might have to do something about CLA in the future...
This is unfortunate. Number one because these issues almost never actually come up in court and law is complex enough that there is always a way to litigate. Number two because I would never spend my free time contributing to a project which required me to file paperwork for the privilege of helping them. That said, I might well be the exception to the rule. After all, if everyone were like me credit card companies would not exist.
A good example of a social good also being more useful is Linux. I love Linux, it is free software and it is fast, even the giants such as Microsoft and Apple can't afford to outspend the army of companies who pour money into profiling, tweaking, optimizing, and refactoring Linux and the result is a network stack which blows the doors off of everyone else in the market. And it got that way being free.
Now the question of how we should make xwiki-contrib more attractive than $THE_OTHER_GUY is worth asking. It is better for the contributor, they get continuous integration and issue tracking, but none of it is automated. Since we're all pretty busy and automating this process is probably not on anybody's roadmap, I think we're going to have to accept that it's easier to start off a small project in one's own namespace and then move when it grows and the contributor wants to take advantage of the services in xwiki-contrib.
I don't really agree here. For a user asking to be on xwiki-contrib it's pretty easy and all the work is done for them by xwiki committers. It would need to be automated for xwiki committers' sake but not for the users asking ;)
If we don't at least understand this fundamental issue then the githubs and facebooks of the world with their 1 click walled gardens will win.
I think the list I've put above is pretty interesting for any project and it can only grow as we improve our forge in the future. The biggest improvement would probably be to offer a full wiki configured as a dev project flavor for contrib projects which would contain (for ex): - A dashboard with would have gadgets listing: latest jira issues, contributors of the project, sonar quality gadgets, latest blog posts of the project, etc - A Release application (similar to the one we have on dev.xwiki.org) - A FAQ application - Git stats using our Github Application - Mailing list/forum application (the one Jeremie is working on :)) - etc
+1 One remaining issue is the "asking to be in contrib" part, it's not particularly hard but nobody wants to ask until they have something to show so I see pushing to one's github namespace and then transferring later as the most common usage scenario. Thanks, Caleb
Thanks -Vincent
Thanks, Caleb
On 11/05/2012 04:02 AM, Jerome Velociter wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/).
Jerome
Thanks -Vincent
Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : > One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, >> Ryszard Łach wrote: >>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
- Mailing list/forum application (the one Jeremie is working on :))
In fact, I think the most missing feature from xwiki-contrib is a time-warp machine to allocate a parallel dimension to the contributor where time stays still :) The idea of a contrib project specific wiki is nice (implemented as a Workspace ?). It merges with my own idea (for internal needs where I work) to create workspaces dedicated to various communities, and present a mail archive view on topics related to that community, creating a workspace template pre-configured for that.
While it would be easy to dismiss me as "lazy", I see this dismissal as a huge problem for the free software movement in general. Why should an ordinary person ask for permission to use xwiki-contrib then make sure their pom.xml parent ID is in order when they could just do 3 clicks and a git push?
Well, I believe it really depends on the profile of the person ... Someone already used to creating open-source projects, having already put in place his own tools and delivery process, may find boring to comply to xwiki contrib rules. Considering my own case, I never really contributed much to open-source projects (nor created some for myself), the tools and processes I'm familiar with are mainly internal and use proprietary (and expansive) tools. So it was very natural for me to use what xwiki contrib had to offer. Also there's the idea that a contribution is more likely to be contributed if it matches community-wise known rules, and so it's easier to get some help if needed. 2012/11/7 Vincent Massol <[email protected]>:
Hi Caleb and all,
On Nov 5, 2012, at 2:07 PM, Caleb James DeLisle <[email protected]> wrote:
Hello,
My opinion of github is not very bright, there's vender lockin because you can't easily migrate issues and other value addeds and they don't open source their platform so while git allows you to push somewhere else, you can't have the nice web interface with the features without going through them.
That said, it is hard to argue with 3 clicks and a `git push`.
While it would be easy to dismiss me as "lazy", I see this dismissal as a huge problem for the free software movement in general. Why should an ordinary person ask for permission to use xwiki-contrib then make sure their pom.xml parent ID is in order when they could just do 3 clicks and a git push?
Because you get a lot more by being an xwiki-contrib project: * CI * Mailing list email notification * Maven repository where to release versions * JIRA, Wiki page (which you also get with github but that's about it) * Sonar dashboard (coming up ;)) * Ability to collaborate with others through a mailing list and more generally collaborate as equals with others rather than in a "creator/second level citizen" mode * Quality stats on xwiki.org on the hall of fame page (needs to be improved) * More visibility since we reference xwiki contribs projects on xwiki.org even more than pure extensions. Note that we need to improve this part which is not fully true ATM but which we could easily make true * More generally ability to benefit from best of breed tools that xwiki.org offers and continue to update/improve in general
Granted XWiki is far better off than some projects, when I see copyright release forms and patent non-infringement statements which have to be signed, I find it mindboggling that anyone would contribute to these projects at all given all of the roadblocks which have been erected.
Actually we might have to do something about CLA in the future...
A good example of a social good also being more useful is Linux. I love Linux, it is free software and it is fast, even the giants such as Microsoft and Apple can't afford to outspend the army of companies who pour money into profiling, tweaking, optimizing, and refactoring Linux and the result is a network stack which blows the doors off of everyone else in the market. And it got that way being free.
Now the question of how we should make xwiki-contrib more attractive than $THE_OTHER_GUY is worth asking. It is better for the contributor, they get continuous integration and issue tracking, but none of it is automated. Since we're all pretty busy and automating this process is probably not on anybody's roadmap, I think we're going to have to accept that it's easier to start off a small project in one's own namespace and then move when it grows and the contributor wants to take advantage of the services in xwiki-contrib.
I don't really agree here. For a user asking to be on xwiki-contrib it's pretty easy and all the work is done for them by xwiki committers. It would need to be automated for xwiki committers' sake but not for the users asking ;)
If we don't at least understand this fundamental issue then the githubs and facebooks of the world with their 1 click walled gardens will win.
I think the list I've put above is pretty interesting for any project and it can only grow as we improve our forge in the future. The biggest improvement would probably be to offer a full wiki configured as a dev project flavor for contrib projects which would contain (for ex): - A dashboard with would have gadgets listing: latest jira issues, contributors of the project, sonar quality gadgets, latest blog posts of the project, etc - A Release application (similar to the one we have on dev.xwiki.org) - A FAQ application - Git stats using our Github Application - Mailing list/forum application (the one Jeremie is working on :)) - etc
Thanks -Vincent
Thanks, Caleb
On 11/05/2012 04:02 AM, Jerome Velociter wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/).
Jerome
Thanks -Vincent
Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : > One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, >> Ryszard Łach wrote: >>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 7, 2012, at 3:41 PM, Jeremie BOUSQUET <[email protected]> wrote:
- Mailing list/forum application (the one Jeremie is working on :))
In fact, I think the most missing feature from xwiki-contrib is a time-warp machine to allocate a parallel dimension to the contributor where time stays still :)
Indeed! That's a nice feature, you should open a JIRA for it ;)
The idea of a contrib project specific wiki is nice (implemented as a Workspace ?).
Yes could be a XEM (i.e. workspaces) or as a farm with hardcoded links between wikis.
It merges with my own idea (for internal needs where I work) to create workspaces dedicated to various communities, and present a mail archive view on topics related to that community, creating a workspace template pre-configured for that.
Yes
While it would be easy to dismiss me as "lazy", I see this dismissal as a huge problem for the free software movement in general. Why should an ordinary person ask for permission to use xwiki-contrib then make sure their pom.xml parent ID is in order when they could just do 3 clicks and a git push?
Well, I believe it really depends on the profile of the person ... Someone already used to creating open-source projects, having already put in place his own tools and delivery process, may find boring to comply to xwiki contrib rules. Considering my own case, I never really contributed much to open-source projects (nor created some for myself), the tools and processes I'm familiar with are mainly internal and use proprietary (and expansive) tools. So it was very natural for me to use what xwiki contrib had to offer. Also there's the idea that a contribution is more likely to be contributed if it matches community-wise known rules, and so it's easier to get some help if needed.
Good points. Thanks -Vincent
2012/11/7 Vincent Massol <[email protected]>:
Hi Caleb and all,
On Nov 5, 2012, at 2:07 PM, Caleb James DeLisle <[email protected]> wrote:
Hello,
My opinion of github is not very bright, there's vender lockin because you can't easily migrate issues and other value addeds and they don't open source their platform so while git allows you to push somewhere else, you can't have the nice web interface with the features without going through them.
That said, it is hard to argue with 3 clicks and a `git push`.
While it would be easy to dismiss me as "lazy", I see this dismissal as a huge problem for the free software movement in general. Why should an ordinary person ask for permission to use xwiki-contrib then make sure their pom.xml parent ID is in order when they could just do 3 clicks and a git push?
Because you get a lot more by being an xwiki-contrib project: * CI * Mailing list email notification * Maven repository where to release versions * JIRA, Wiki page (which you also get with github but that's about it) * Sonar dashboard (coming up ;)) * Ability to collaborate with others through a mailing list and more generally collaborate as equals with others rather than in a "creator/second level citizen" mode * Quality stats on xwiki.org on the hall of fame page (needs to be improved) * More visibility since we reference xwiki contribs projects on xwiki.org even more than pure extensions. Note that we need to improve this part which is not fully true ATM but which we could easily make true * More generally ability to benefit from best of breed tools that xwiki.org offers and continue to update/improve in general
Granted XWiki is far better off than some projects, when I see copyright release forms and patent non-infringement statements which have to be signed, I find it mindboggling that anyone would contribute to these projects at all given all of the roadblocks which have been erected.
Actually we might have to do something about CLA in the future...
A good example of a social good also being more useful is Linux. I love Linux, it is free software and it is fast, even the giants such as Microsoft and Apple can't afford to outspend the army of companies who pour money into profiling, tweaking, optimizing, and refactoring Linux and the result is a network stack which blows the doors off of everyone else in the market. And it got that way being free.
Now the question of how we should make xwiki-contrib more attractive than $THE_OTHER_GUY is worth asking. It is better for the contributor, they get continuous integration and issue tracking, but none of it is automated. Since we're all pretty busy and automating this process is probably not on anybody's roadmap, I think we're going to have to accept that it's easier to start off a small project in one's own namespace and then move when it grows and the contributor wants to take advantage of the services in xwiki-contrib.
I don't really agree here. For a user asking to be on xwiki-contrib it's pretty easy and all the work is done for them by xwiki committers. It would need to be automated for xwiki committers' sake but not for the users asking ;)
If we don't at least understand this fundamental issue then the githubs and facebooks of the world with their 1 click walled gardens will win.
I think the list I've put above is pretty interesting for any project and it can only grow as we improve our forge in the future. The biggest improvement would probably be to offer a full wiki configured as a dev project flavor for contrib projects which would contain (for ex): - A dashboard with would have gadgets listing: latest jira issues, contributors of the project, sonar quality gadgets, latest blog posts of the project, etc - A Release application (similar to the one we have on dev.xwiki.org) - A FAQ application - Git stats using our Github Application - Mailing list/forum application (the one Jeremie is working on :)) - etc
Thanks -Vincent
Thanks, Caleb
On 11/05/2012 04:02 AM, Jerome Velociter wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré : > Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/).
Jerome
Thanks -Vincent
> Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : >> One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >>> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, >>> Ryszard Łach wrote: >>>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/).
My take on this: * Either the project is a xwiki-contrib project and then it gets the tools and niceties included for being an xwiki-contrib project (jira, CI, web site, ability to collaborate equally between contributors, email notifications on xwiki lists, sonar dashboard coming soon, maven remote repository, etc) or it's not and then it uses whatever tools it wants but not xwiki's project resources. It seems fair to me. * If we agree we should then update contrib.xwiki.org to explain better all that the user will get by being an xwiki-contrib project and explain the alternative. And also explain that if the user wants to host it himself then give him some direction for the maven groupid/artifactid that he should or rather the ones he shouldn't use since it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not sure if we want to also say that his artifact id shouldn't start with "xwiki-" as its done for maven plugins in apache land). WDYT? Thanks -Vincent
Jerome
Thanks -Vincent
Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit :
One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote:
Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: > Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 11/07/2012 09:03 AM, Vincent Massol wrote:
On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). My take on this:
* Either the project is a xwiki-contrib project and then it gets the tools and niceties included for being an xwiki-contrib project (jira, CI, web site, ability to collaborate equally between contributors, email notifications on xwiki lists, sonar dashboard coming soon, maven remote repository, etc) or it's not and then it uses whatever tools it wants but not xwiki's project resources. It seems fair to me. * If we agree we should then update contrib.xwiki.org to explain better all that the user will get by being an xwiki-contrib project and explain the alternative. And also explain that if the user wants to host it himself then give him some direction for the maven groupid/artifactid that he should or rather the ones he shouldn't use since it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not sure if we want to also say that his artifact id shouldn't start with "xwiki-" as its done for maven plugins in apache land).
WDYT?
Makes sense to me. One thing to consider also is the fact projects outside contrib will play less well with XWiki extension manager since they won't be in XWiki nexus (unless the repository they are in is added to nexus). Personnally I think we should allow contributing organization repositories being added in XWiki's nexus so that it's not a differentiator. Jerome.
Thanks -Vincent
Jerome
Thanks -Vincent
Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit :
One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: > Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: >> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 7, 2012, at 9:53 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:03 AM, Vincent Massol wrote:
On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré :
Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think.
Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). My take on this:
* Either the project is a xwiki-contrib project and then it gets the tools and niceties included for being an xwiki-contrib project (jira, CI, web site, ability to collaborate equally between contributors, email notifications on xwiki lists, sonar dashboard coming soon, maven remote repository, etc) or it's not and then it uses whatever tools it wants but not xwiki's project resources. It seems fair to me. * If we agree we should then update contrib.xwiki.org to explain better all that the user will get by being an xwiki-contrib project and explain the alternative. And also explain that if the user wants to host it himself then give him some direction for the maven groupid/artifactid that he should or rather the ones he shouldn't use since it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not sure if we want to also say that his artifact id shouldn't start with "xwiki-" as its done for maven plugins in apache land).
WDYT?
Makes sense to me.
One thing to consider also is the fact projects outside contrib will play less well with XWiki extension manager since they won't be in XWiki nexus (unless the repository they are in is added to nexus). Personnally I think we should allow contributing organization repositories being added in XWiki's nexus so that it's not a differentiator.
I mentioned that already in my reply when I said that xwiki-contrib projects get a maven remote repo. Re allowing external projects to be hosted in our remote maven repo, maybe but it's dangerous. We need some oversight of the project we host because we're then legally responsible for what we host. So we'd some way for people to request hosting and have manual operation. TBH I'm not sure if we should provide this since Sonatype already provides it for any open source project, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U... They already have all the tools to verify that poms are correct and more so I don't think we should duplicate the effort. Right now, I'd say we only offer a remote maven repo for our own projects and we direct others to the Sonatype OSS repo. Thanks -Vincent
Jerome.
Thanks -Vincent
Jerome
Thanks -Vincent
Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : > One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: >>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
On 11/07/2012 09:59 AM, Vincent Massol wrote:
On Nov 7, 2012, at 9:53 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:03 AM, Vincent Massol wrote:
On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote:
This should have been for devs Envoyé de mon iPhone Début du message transféré : > Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think. Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). My take on this:
* Either the project is a xwiki-contrib project and then it gets the tools and niceties included for being an xwiki-contrib project (jira, CI, web site, ability to collaborate equally between contributors, email notifications on xwiki lists, sonar dashboard coming soon, maven remote repository, etc) or it's not and then it uses whatever tools it wants but not xwiki's project resources. It seems fair to me. * If we agree we should then update contrib.xwiki.org to explain better all that the user will get by being an xwiki-contrib project and explain the alternative. And also explain that if the user wants to host it himself then give him some direction for the maven groupid/artifactid that he should or rather the ones he shouldn't use since it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not sure if we want to also say that his artifact id shouldn't start with "xwiki-" as its done for maven plugins in apache land).
WDYT? Makes sense to me.
One thing to consider also is the fact projects outside contrib will play less well with XWiki extension manager since they won't be in XWiki nexus (unless the repository they are in is added to nexus). Personnally I think we should allow contributing organization repositories being added in XWiki's nexus so that it's not a differentiator. I mentioned that already in my reply when I said that xwiki-contrib projects get a maven remote repo.
Re allowing external projects to be hosted in our remote maven repo, maybe but it's dangerous. We need some oversight of the project we host because we're then legally responsible for what we host. So we'd some way for people to request hosting and have manual operation.
TBH I'm not sure if we should provide this since Sonatype already provides it for any open source project, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...
They already have all the tools to verify that poms are correct and more so I don't think we should duplicate the effort.
Right now, I'd say we only offer a remote maven repo for our own projects and we direct others to the Sonatype OSS repo.
Actually I wasn't talking about hosting, but about having their (external repositories of contributing individuals/organizations that is not xwiki-contrib) repositories proxied in XWiki's nexus so that they are found by the extension manager with the default configuration. Reserving hosting on the maven repos to xwiki-contrib is fine. Jerome
Thanks -Vincent
Jerome.
Thanks -Vincent
Jerome
Thanks -Vincent
> Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : >> One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >>> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: >>>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 7, 2012, at 10:07 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:59 AM, Vincent Massol wrote:
On Nov 7, 2012, at 9:53 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:03 AM, Vincent Massol wrote:
On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote:
On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote: > This should have been for devs Envoyé de mon iPhone Début du message transféré : >> Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think. Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). My take on this:
* Either the project is a xwiki-contrib project and then it gets the tools and niceties included for being an xwiki-contrib project (jira, CI, web site, ability to collaborate equally between contributors, email notifications on xwiki lists, sonar dashboard coming soon, maven remote repository, etc) or it's not and then it uses whatever tools it wants but not xwiki's project resources. It seems fair to me. * If we agree we should then update contrib.xwiki.org to explain better all that the user will get by being an xwiki-contrib project and explain the alternative. And also explain that if the user wants to host it himself then give him some direction for the maven groupid/artifactid that he should or rather the ones he shouldn't use since it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not sure if we want to also say that his artifact id shouldn't start with "xwiki-" as its done for maven plugins in apache land).
WDYT? Makes sense to me.
One thing to consider also is the fact projects outside contrib will play less well with XWiki extension manager since they won't be in XWiki nexus (unless the repository they are in is added to nexus). Personnally I think we should allow contributing organization repositories being added in XWiki's nexus so that it's not a differentiator. I mentioned that already in my reply when I said that xwiki-contrib projects get a maven remote repo.
Re allowing external projects to be hosted in our remote maven repo, maybe but it's dangerous. We need some oversight of the project we host because we're then legally responsible for what we host. So we'd some way for people to request hosting and have manual operation.
TBH I'm not sure if we should provide this since Sonatype already provides it for any open source project, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...
They already have all the tools to verify that poms are correct and more so I don't think we should duplicate the effort.
Right now, I'd say we only offer a remote maven repo for our own projects and we direct others to the Sonatype OSS repo.
Actually I wasn't talking about hosting, but about having their (external repositories of contributing individuals/organizations that is not xwiki-contrib) repositories proxied in XWiki's nexus so that they are found by the extension manager with the default configuration.
I know :) I'm talking about the same thing! Our Nexus proxies several repos including Maven Central. So if you push your artifact in Sonatype's OSS repo then you get it in XWiki's Extension Manager ;) -Vincent
Reserving hosting on the maven repos to xwiki-contrib is fine.
Jerome
Thanks -Vincent
Jerome.
Thanks -Vincent
Jerome
Thanks -Vincent >> Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : >>> One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >>>> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: >>>>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
On 11/07/2012 10:33 AM, Vincent Massol wrote:
On Nov 7, 2012, at 10:07 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:59 AM, Vincent Massol wrote:
On Nov 7, 2012, at 9:53 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:03 AM, Vincent Massol wrote:
On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> wrote:
On 10/23/2012 09:33 AM, Vincent Massol wrote: > On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote: >> This should have been for devs Envoyé de mon iPhone Début du message transféré : >>> Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree > Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think. Hi Vincent,
This is a interesting topic and there are several aspects to it.
For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.).
That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc.
Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : - use of own tools and own workflow (github issues vs. JIRA for example). - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example).
The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). My take on this:
* Either the project is a xwiki-contrib project and then it gets the tools and niceties included for being an xwiki-contrib project (jira, CI, web site, ability to collaborate equally between contributors, email notifications on xwiki lists, sonar dashboard coming soon, maven remote repository, etc) or it's not and then it uses whatever tools it wants but not xwiki's project resources. It seems fair to me. * If we agree we should then update contrib.xwiki.org to explain better all that the user will get by being an xwiki-contrib project and explain the alternative. And also explain that if the user wants to host it himself then give him some direction for the maven groupid/artifactid that he should or rather the ones he shouldn't use since it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not sure if we want to also say that his artifact id shouldn't start with "xwiki-" as its done for maven plugins in apache land).
WDYT? Makes sense to me.
One thing to consider also is the fact projects outside contrib will play less well with XWiki extension manager since they won't be in XWiki nexus (unless the repository they are in is added to nexus). Personnally I think we should allow contributing organization repositories being added in XWiki's nexus so that it's not a differentiator. I mentioned that already in my reply when I said that xwiki-contrib projects get a maven remote repo.
Re allowing external projects to be hosted in our remote maven repo, maybe but it's dangerous. We need some oversight of the project we host because we're then legally responsible for what we host. So we'd some way for people to request hosting and have manual operation.
TBH I'm not sure if we should provide this since Sonatype already provides it for any open source project, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...
They already have all the tools to verify that poms are correct and more so I don't think we should duplicate the effort.
Right now, I'd say we only offer a remote maven repo for our own projects and we direct others to the Sonatype OSS repo. Actually I wasn't talking about hosting, but about having their (external repositories of contributing individuals/organizations that is not xwiki-contrib) repositories proxied in XWiki's nexus so that they are found by the extension manager with the default configuration. I know :) I'm talking about the same thing! Our Nexus proxies several repos including Maven Central. So if you push your artifact in Sonatype's OSS repo then you get it in XWiki's Extension Manager ;)
Yes but one could still want it in its own repos and not sonatype. BTW we're not proxying sonatype repos yet AFAIK. Jerome
-Vincent
Reserving hosting on the maven repos to xwiki-contrib is fine.
Jerome
Thanks -Vincent
Jerome.
Thanks -Vincent
Jerome
> Thanks -Vincent >>> Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : >>>> One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >>>>> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: >>>>>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 7, 2012, at 10:38 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 10:33 AM, Vincent Massol wrote:
On Nov 7, 2012, at 10:07 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:59 AM, Vincent Massol wrote:
On Nov 7, 2012, at 9:53 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:03 AM, Vincent Massol wrote:
On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> wrote:
> On 10/23/2012 09:33 AM, Vincent Massol wrote: >> On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote: >>> This should have been for devs Envoyé de mon iPhone Début du message transféré : >>>> Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree >> Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think. > Hi Vincent, > > This is a interesting topic and there are several aspects to it. > > For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.). > > That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc. > > Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : > - use of own tools and own workflow (github issues vs. JIRA for example). > - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example). > > The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? > If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). My take on this:
* Either the project is a xwiki-contrib project and then it gets the tools and niceties included for being an xwiki-contrib project (jira, CI, web site, ability to collaborate equally between contributors, email notifications on xwiki lists, sonar dashboard coming soon, maven remote repository, etc) or it's not and then it uses whatever tools it wants but not xwiki's project resources. It seems fair to me. * If we agree we should then update contrib.xwiki.org to explain better all that the user will get by being an xwiki-contrib project and explain the alternative. And also explain that if the user wants to host it himself then give him some direction for the maven groupid/artifactid that he should or rather the ones he shouldn't use since it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not sure if we want to also say that his artifact id shouldn't start with "xwiki-" as its done for maven plugins in apache land).
WDYT? Makes sense to me.
One thing to consider also is the fact projects outside contrib will play less well with XWiki extension manager since they won't be in XWiki nexus (unless the repository they are in is added to nexus). Personnally I think we should allow contributing organization repositories being added in XWiki's nexus so that it's not a differentiator. I mentioned that already in my reply when I said that xwiki-contrib projects get a maven remote repo.
Re allowing external projects to be hosted in our remote maven repo, maybe but it's dangerous. We need some oversight of the project we host because we're then legally responsible for what we host. So we'd some way for people to request hosting and have manual operation.
TBH I'm not sure if we should provide this since Sonatype already provides it for any open source project, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...
They already have all the tools to verify that poms are correct and more so I don't think we should duplicate the effort.
Right now, I'd say we only offer a remote maven repo for our own projects and we direct others to the Sonatype OSS repo. Actually I wasn't talking about hosting, but about having their (external repositories of contributing individuals/organizations that is not xwiki-contrib) repositories proxied in XWiki's nexus so that they are found by the extension manager with the default configuration. I know :) I'm talking about the same thing! Our Nexus proxies several repos including Maven Central. So if you push your artifact in Sonatype's OSS repo then you get it in XWiki's Extension Manager ;)
Yes but one could still want it in its own repos and not sonatype.
Sure but then it's not our problem and I personally don't agree about proxying other people's remote repos (too much maintenance and too dangerous). FYI Maven Central stopped doing this after they had problems with it.
BTW we're not proxying sonatype repos yet AFAIK.
Sonatype's repos are synced to central AFAIK. And for the same reason we shouldn't proxy any Sonatype repo. -Vincent
Jerome
-Vincent
Reserving hosting on the maven repos to xwiki-contrib is fine.
Jerome
Thanks -Vincent
Jerome.
Thanks -Vincent
> Jerome > > >> Thanks -Vincent >>>> Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : >>>>> One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >>>>>> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: >>>>>>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 11/07/2012 10:41 AM, Vincent Massol wrote:
On Nov 7, 2012, at 10:38 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 10:33 AM, Vincent Massol wrote:
On Nov 7, 2012, at 10:07 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:59 AM, Vincent Massol wrote:
On Nov 7, 2012, at 9:53 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:03 AM, Vincent Massol wrote: > On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> wrote: > >> On 10/23/2012 09:33 AM, Vincent Massol wrote: >>> On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote: >>>> This should have been for devs Envoyé de mon iPhone Début du message transféré : >>>>> Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree >>> Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think. >> Hi Vincent, >> >> This is a interesting topic and there are several aspects to it. >> >> For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.). >> >> That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc. >> >> Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : >> - use of own tools and own workflow (github issues vs. JIRA for example). >> - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example). >> >> The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? >> If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). > My take on this: > > * Either the project is a xwiki-contrib project and then it gets the tools and niceties included for being an xwiki-contrib project (jira, CI, web site, ability to collaborate equally between contributors, email notifications on xwiki lists, sonar dashboard coming soon, maven remote repository, etc) or it's not and then it uses whatever tools it wants but not xwiki's project resources. It seems fair to me. > * If we agree we should then update contrib.xwiki.org to explain better all that the user will get by being an xwiki-contrib project and explain the alternative. And also explain that if the user wants to host it himself then give him some direction for the maven groupid/artifactid that he should or rather the ones he shouldn't use since it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not sure if we want to also say that his artifact id shouldn't start with "xwiki-" as its done for maven plugins in apache land). > > WDYT? Makes sense to me.
One thing to consider also is the fact projects outside contrib will play less well with XWiki extension manager since they won't be in XWiki nexus (unless the repository they are in is added to nexus). Personnally I think we should allow contributing organization repositories being added in XWiki's nexus so that it's not a differentiator. I mentioned that already in my reply when I said that xwiki-contrib projects get a maven remote repo.
Re allowing external projects to be hosted in our remote maven repo, maybe but it's dangerous. We need some oversight of the project we host because we're then legally responsible for what we host. So we'd some way for people to request hosting and have manual operation.
TBH I'm not sure if we should provide this since Sonatype already provides it for any open source project, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...
They already have all the tools to verify that poms are correct and more so I don't think we should duplicate the effort.
Right now, I'd say we only offer a remote maven repo for our own projects and we direct others to the Sonatype OSS repo. Actually I wasn't talking about hosting, but about having their (external repositories of contributing individuals/organizations that is not xwiki-contrib) repositories proxied in XWiki's nexus so that they are found by the extension manager with the default configuration. I know :) I'm talking about the same thing! Our Nexus proxies several repos including Maven Central. So if you push your artifact in Sonatype's OSS repo then you get it in XWiki's Extension Manager ;) Yes but one could still want it in its own repos and not sonatype. Sure but then it's not our problem and I personally don't agree about proxying other people's remote repos (too much maintenance and too dangerous). FYI Maven Central stopped doing this after they had problems with it.
Could you expand on why too dangerous/what problems it causes ? For example, what's the difference with repos we are already proxying ?
BTW we're not proxying sonatype repos yet AFAIK. Sonatype's repos are synced to central AFAIK. And for the same reason we shouldn't proxy any Sonatype repo.
OK not everything is synced it seems (c.f. https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...) that would explain why I had a dependency on sonatype's repos not resoved by the EM by default (see https://github.com/jvelo/xwiki-social-login/blob/master/pom.xml) Jerome
-Vincent
Jerome
-Vincent
Reserving hosting on the maven repos to xwiki-contrib is fine.
Jerome
Thanks -Vincent
Jerome.
> Thanks > -Vincent > >> Jerome >> >> >>> Thanks -Vincent >>>>> Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : >>>>>> One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >>>>>>> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: >>>>>>>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 7, 2012, at 10:49 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 10:41 AM, Vincent Massol wrote:
On Nov 7, 2012, at 10:38 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 10:33 AM, Vincent Massol wrote:
On Nov 7, 2012, at 10:07 AM, Jerome Velociter <[email protected]> wrote:
On 11/07/2012 09:59 AM, Vincent Massol wrote:
On Nov 7, 2012, at 9:53 AM, Jerome Velociter <[email protected]> wrote:
> On 11/07/2012 09:03 AM, Vincent Massol wrote: >> On Nov 5, 2012, at 10:02 AM, Jerome Velociter <[email protected]> wrote: >> >>> On 10/23/2012 09:33 AM, Vincent Massol wrote: >>>> On Oct 23, 2012, at 9:20 AM, Ludovic Dubost <[email protected]> wrote: >>>>> This should have been for devs Envoyé de mon iPhone Début du message transféré : >>>>>> Expéditeur: Ludovic Dubost <[email protected]> Date: 23 octobre 2012 09:19:55 UTC+02:00 Destinataire: XWiki Users <[email protected]> Objet: Github tracker. was: Re: [xwiki-users] New Realtime collaborative editing extension. Just a quick. You seem to introduce a practice to use the github tracker instead of xwiki.org jira's Not sure it's a good thing. I'm sure Vincent will agree >>>> Well, what I would prefer personally is that contrib projects be in the xwiki-contrib organization and use the XWiki tools (wiki, jira, etc). The reason is that this allows: * to group together projects around XWiki (they're not scattered everywhere on the web and harder to find) * make it a neutral location for people to collaborate together on xwiki projects. That's a key element to contribution IMO * is more long term. If you stop working on the project it's not going to be a dead project in someone's github repo and it'll have more chance of being maintained/seen in the xwiki-contrib repo I know Jerome also puts his contributions in his own github project and I had the same reservation about it. We can't force anyone of course since this is a contribution but it's more collaborative to make them xwiki-contrib project, following the rules defined at http://contrib.xwiki.org I understand you may want to beef up your github profile but for collaboration I feel the xwiki-contrib is better with the 2 arguments listed above. Jerome, Caleb let me know what you think. >>> Hi Vincent, >>> >>> This is a interesting topic and there are several aspects to it. >>> >>> For me the "discoverability" argument for having projects on https://github.com/xwiki-contribdoes not make much sense. The centralized place for projects around XWiki is http://extensions.xwiki.org, not github. There's the "view source" button that tells where the sources are. Github is a convenience here, and it's always possible to "copy" (or fork) a project in xwiki-contrib, for whatever reason (original project not active, etc.). >>> >>> That being said I understand why you think it's better to have as much projects as possible under the xwiki-contrib umbrella : it makes it a one-stop shop with the same tools, same workflow, same permissions, etc. >>> >>> Here are the arguments I see for why one contributor or contributing organization would want to host its projects itself : >>> - use of own tools and own workflow (github issues vs. JIRA for example). >>> - it allows a contributor or contributing organization to have it's own place to centralize its contribution(s) (the "beef up" argument as you say). I think this can make sense in some circonstances, especially for contributing organizations (companies for example). >>> >>> The bottom line comes down to : what rules do we want for using the "org.xwiki.contrib" groupId and tools (maven repos, CI, etc.) ? >>> If we want a rule saying that the project should be hosted on github.com/xwiki-contrib/ then that's that, and I think it's fair. We just have to decide on it (right now there is no such rule according to http://contrib.xwiki.org/). >> My take on this: >> >> * Either the project is a xwiki-contrib project and then it gets the tools and niceties included for being an xwiki-contrib project (jira, CI, web site, ability to collaborate equally between contributors, email notifications on xwiki lists, sonar dashboard coming soon, maven remote repository, etc) or it's not and then it uses whatever tools it wants but not xwiki's project resources. It seems fair to me. >> * If we agree we should then update contrib.xwiki.org to explain better all that the user will get by being an xwiki-contrib project and explain the alternative. And also explain that if the user wants to host it himself then give him some direction for the maven groupid/artifactid that he should or rather the ones he shouldn't use since it's reserved (basicallty the rule is his groupid cannot start with org.xwiki, not sure if we want to also say that his artifact id shouldn't start with "xwiki-" as its done for maven plugins in apache land). >> >> WDYT? > Makes sense to me. > > One thing to consider also is the fact projects outside contrib will play less well with XWiki extension manager since they won't be in XWiki nexus (unless the repository they are in is added to nexus). Personnally I think we should allow contributing organization repositories being added in XWiki's nexus so that it's not a differentiator. I mentioned that already in my reply when I said that xwiki-contrib projects get a maven remote repo.
Re allowing external projects to be hosted in our remote maven repo, maybe but it's dangerous. We need some oversight of the project we host because we're then legally responsible for what we host. So we'd some way for people to request hosting and have manual operation.
TBH I'm not sure if we should provide this since Sonatype already provides it for any open source project, see https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...
They already have all the tools to verify that poms are correct and more so I don't think we should duplicate the effort.
Right now, I'd say we only offer a remote maven repo for our own projects and we direct others to the Sonatype OSS repo. Actually I wasn't talking about hosting, but about having their (external repositories of contributing individuals/organizations that is not xwiki-contrib) repositories proxied in XWiki's nexus so that they are found by the extension manager with the default configuration. I know :) I'm talking about the same thing! Our Nexus proxies several repos including Maven Central. So if you push your artifact in Sonatype's OSS repo then you get it in XWiki's Extension Manager ;) Yes but one could still want it in its own repos and not sonatype. Sure but then it's not our problem and I personally don't agree about proxying other people's remote repos (too much maintenance and too dangerous). FYI Maven Central stopped doing this after they had problems with it.
Could you expand on why too dangerous/what problems it causes ? For example, what's the difference with repos we are already proxying ?
It's just too much maintenance. I'll give you one example: the jboss guys made a mistake in their remote repo and suddenly all our artifacts proxied were all wrong and it took us several days to fix this. Another issue is that we don't control what's put in these repo so the less we proxy the better. Actually when we proxy existing repos like the jboss one we should ideally only proxy the artifacts we use. More generally the more repos we had the more problems we'll have, the more space it'll take and the more maintenance it'll require (dead repos, slow repos, bad data in the repos, etc). I'm personally not willing to use my own time to help on this. We have enough work elsewhere and again this service is provided by Sonatype already so there's no reason/advantage for us to duplicate their effort (they have more resource than we have). Thanks -Vincent
BTW we're not proxying sonatype repos yet AFAIK. Sonatype's repos are synced to central AFAIK. And for the same reason we shouldn't proxy any Sonatype repo.
OK not everything is synced it seems (c.f. https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+U...) that would explain why I had a dependency on sonatype's repos not resoved by the EM by default (see https://github.com/jvelo/xwiki-social-login/blob/master/pom.xml)
Jerome
-Vincent
Jerome
-Vincent
Reserving hosting on the maven repos to xwiki-contrib is fine.
Jerome
Thanks -Vincent
> Jerome. > >> Thanks >> -Vincent >> >>> Jerome >>> >>> >>>> Thanks -Vincent >>>>>> Ludovic Envoyé de mon iPhone Le 23 oct. 2012 à 04:17, Caleb James DeLisle <[email protected]> a écrit : >>>>>>> One other thing, please report the features which you want and what you imagine as best on the github tracker, it's easier to close an issue as "won't fix" than it is to remember an important issue which nobody wrote down ;) Thanks Caleb On 10/22/2012 10:14 PM, Caleb James DeLisle wrote: >>>>>>>> Hi, Thanks for the complement. I just updated it and fixed issue #1. Thanks for reporting it. Somehow showing who else is editing, showing where they are editing in the document and allowing the user to spawn a chat window with other editors on the page are all interesting possibilities. Right now I think the thing to do is decide where there is the most bang for your buck in terms of feature value and get an idea of what's most natural for the user. Thanks, Caleb On 10/19/2012 07:59 AM, Ryszard Łach wrote: >>>>>>>>> Great work! It looks like good starting point to give xwiki the main (at least for me) feature, that makes googledoc sometimes more suitable for collaborative editing. It would be really great, if your editor would show somehow, where the other editor (person) is now, where is his cursor. Maybe a highlight (the whole line) showing the other's cursor placement? Do you plan to work on such improvements? R.
participants (5)
-
Caleb James DeLisle -
Jeremie BOUSQUET -
Jerome Velociter -
Ludovic Dubost -
Vincent Massol