[xwiki-devs] [Proposal] XWiki Watch publicly available on xwiki.org
Hi devs, As it has been already mentioned a couple of times, I strongly believe that XWiki Watch should be accessible in a sandbox on xwiki.org, for everyone to try it out and explore its features and for us to get an open real-life test of it. There is a document dedicated to the issues that might prevent this at http://watch.xwiki.org/xwiki/bin/view/Development/XWatchOnXWikiOrg , please fill it in with any opinions you have! Here's my +1 for having an installation of XWatch publicly available on xwiki.org, WDYT? Happy coding, Anca P.S: Sorry for the duplicate email, I forgot the subject in the previous one and I thought it's important enough to deserve duplicating.
On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote:
Hi devs,
As it has been already mentioned a couple of times, I strongly believe that XWiki Watch should be accessible in a sandbox on xwiki.org, for everyone to try it out and explore its features and for us to get an open real-life test of it. There is a document dedicated to the issues that might prevent this at http://watch.xwiki.org/xwiki/bin/view/Development/XWatchOnXWikiOrg , please fill it in with any opinions you have!
Here's my +1 for having an installation of XWatch publicly available on xwiki.org, WDYT?
Sure, we've already discussed it as I wanted to install it but discovered it wasn't possible at the time. I wouldn't call it a sandbox as I think it could be used for real and contain feeds related to xwiki and anything relevant. Here are some issues I can think of: 1) Allow unregistered users to view and use the reader 2) Provide ability to undo changes done by users (the revert feature of all wikis). This is especially important in a public instance: it needs to be easier to revert an error than it is to create one! 3) Good performances I think that if we have 1) and 2) we could start using it on xwiki.org. Thanks -Vincent [snip]
Vincent Massol wrote:
On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote:
Hi devs,
As it has been already mentioned a couple of times, I strongly believe that XWiki Watch should be accessible in a sandbox on xwiki.org, for everyone to try it out and explore its features and for us to get an open real-life test of it. There is a document dedicated to the issues that might prevent this at http://watch.xwiki.org/xwiki/bin/view/Development/XWatchOnXWikiOrg , please fill it in with any opinions you have!
Here's my +1 for having an installation of XWatch publicly available on xwiki.org, WDYT?
Sure, we've already discussed it as I wanted to install it but discovered it wasn't possible at the time. I wouldn't call it a sandbox as I think it could be used for real and contain feeds related to xwiki and anything relevant.
Here are some issues I can think of: 1) Allow unregistered users to view and use the reader
Since Watch is implemented using the XWiki documents & objects model, user rights follow the same model as all XWiki. Guest users use the rights we give them: for viewing / navigating through the reader, view right is enough, whereas any edit (add feed, tag/flag/trash/mark as read articles) requires edit rights. Unless there is a problem with giving edit rights to guests, I don't see exactly what is the issue with having guests use the reader.
2) Provide ability to undo changes done by users (the revert feature of all wikis). This is especially important in a public instance: it needs to be easier to revert an error than it is to create one!
As mentioned earlier, all Watch data is stored in xwiki documents & objects, so reverting is as easy as it can be in any other instance of xwiki. Now, there is a problem with what we understand by reverting changes in a "feed reader". The first example that comes into my mind is when a user adds a feed source, say unwanted. Since the feed articles fetched from that are stored in xwiki documents, revert (wiki-way) would mean deleting the feed, but that would not trigger deleting all fetched articles. While from a feed reader point of view, reverting this change would probably mean deleting all fetched articles too. For this particular example this is not a problem because deleting a feed with all fetched articles is implemented in watch reader interface, but there is a general problem of actions and concepts interpretation in Watch: seeing it as a wiki vs. seeing it as a feed reader.
3) Good performances
Depending on the type of database used and the database setup, XWiki Watch can get a little heavy for (arguable) large database sizes (~10000 fetched articles), but I think using it on xwiki.org would help better estimating these type of problems.
I think that if we have 1) and 2) we could start using it on xwiki.org.
Thanks -Vincent
[snip]
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jul 24, 2008, at 9:35 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote:
Hi devs,
As it has been already mentioned a couple of times, I strongly believe that XWiki Watch should be accessible in a sandbox on xwiki.org, for everyone to try it out and explore its features and for us to get an open real-life test of it. There is a document dedicated to the issues that might prevent this at http://watch.xwiki.org/xwiki/bin/view/Development/XWatchOnXWikiOrg , please fill it in with any opinions you have!
Here's my +1 for having an installation of XWatch publicly available on xwiki.org, WDYT?
Sure, we've already discussed it as I wanted to install it but discovered it wasn't possible at the time. I wouldn't call it a sandbox as I think it could be used for real and contain feeds related to xwiki and anything relevant.
Here are some issues I can think of: 1) Allow unregistered users to view and use the reader
Since Watch is implemented using the XWiki documents & objects model, user rights follow the same model as all XWiki. Guest users use the rights we give them: for viewing / navigating through the reader, view right is enough, whereas any edit (add feed, tag/flag/trash/mark as read articles) requires edit rights. Unless there is a problem with giving edit rights to guests, I don't see exactly what is the issue with having guests use the reader.
Yes we definitely shouldn't give edit rights to guests. This leads to spamming. We need people to be registered for getting edit rights. But if users can use the reader with only view rights then it's good. AFAIR it wasn't working before.
2) Provide ability to undo changes done by users (the revert feature of all wikis). This is especially important in a public instance: it needs to be easier to revert an error than it is to create one!
As mentioned earlier, all Watch data is stored in xwiki documents & objects, so reverting is as easy as it can be in any other instance of xwiki.
Now, there is a problem with what we understand by reverting changes in a "feed reader". The first example that comes into my mind is when a user adds a feed source, say unwanted. Since the feed articles fetched from that are stored in xwiki documents, revert (wiki-way) would mean deleting the feed, but that would not trigger deleting all fetched articles. While from a feed reader point of view, reverting this change would probably mean deleting all fetched articles too. For this particular example this is not a problem because deleting a feed with all fetched articles is implemented in watch reader interface, but there is a general problem of actions and concepts interpretation in Watch: seeing it as a wiki vs. seeing it as a feed reader.
We just need to check use case by use case if we have a way to revert changes: * If a user adds an unwanted feed, we can remove it with the delete feed button so that's ok * if a user deletes a feed, how can we restore it? * if a user creates a spammy comment or tag how can we remove them? * can a user remove a tag or comment? (probably not or maybe only his own tags/comments) * same questions for the trash and starring. Ah another point: 4) We need a RSS feeds of all actions that happen in the reader, like "adding a new feed", "deleting a feed", "commenting", "flagging", etc so that it's possible to follow what's happening and revert if need be.
3) Good performances
Depending on the type of database used and the database setup, XWiki Watch can get a little heavy for (arguable) large database sizes (~10000 fetched articles), but I think using it on xwiki.org would help better estimating these type of problems.
Yes. Thanks -Vincent
Vincent Massol wrote:
On Jul 24, 2008, at 9:35 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote:
Hi devs,
As it has been already mentioned a couple of times, I strongly believe that XWiki Watch should be accessible in a sandbox on xwiki.org, for everyone to try it out and explore its features and for us to get an open real-life test of it. There is a document dedicated to the issues that might prevent this at http://watch.xwiki.org/xwiki/bin/view/Development/XWatchOnXWikiOrg , please fill it in with any opinions you have!
Here's my +1 for having an installation of XWatch publicly available on xwiki.org, WDYT? Sure, we've already discussed it as I wanted to install it but discovered it wasn't possible at the time. I wouldn't call it a sandbox as I think it could be used for real and contain feeds related to xwiki and anything relevant.
Here are some issues I can think of: 1) Allow unregistered users to view and use the reader Since Watch is implemented using the XWiki documents & objects model, user rights follow the same model as all XWiki. Guest users use the rights we give them: for viewing / navigating through the reader, view right is enough, whereas any edit (add feed, tag/flag/trash/mark as read articles) requires edit rights. Unless there is a problem with giving edit rights to guests, I don't see exactly what is the issue with having guests use the reader.
Yes we definitely shouldn't give edit rights to guests. This leads to spamming. We need people to be registered for getting edit rights.
But if users can use the reader with only view rights then it's good. AFAIR it wasn't working before.
2) Provide ability to undo changes done by users (the revert feature of all wikis). This is especially important in a public instance: it needs to be easier to revert an error than it is to create one! As mentioned earlier, all Watch data is stored in xwiki documents & objects, so reverting is as easy as it can be in any other instance of xwiki.
Now, there is a problem with what we understand by reverting changes in a "feed reader". The first example that comes into my mind is when a user adds a feed source, say unwanted. Since the feed articles fetched from that are stored in xwiki documents, revert (wiki-way) would mean deleting the feed, but that would not trigger deleting all fetched articles. While from a feed reader point of view, reverting this change would probably mean deleting all fetched articles too. For this particular example this is not a problem because deleting a feed with all fetched articles is implemented in watch reader interface, but there is a general problem of actions and concepts interpretation in Watch: seeing it as a wiki vs. seeing it as a feed reader.
We just need to check use case by use case if we have a way to revert changes: * If a user adds an unwanted feed, we can remove it with the delete feed button so that's ok * if a user deletes a feed, how can we restore it?
A feed is an object in a XWikiDocument, so restoring from recycle bin would work perfectly fine. Same for deleted articles, groups, keywords.
* if a user creates a spammy comment or tag how can we remove them? * can a user remove a tag or comment? (probably not or maybe only his own tags/comments) * same questions for the trash and starring.
A comment for an article is a xwiki comment for the document holding the article, the tags, star, trash are properties of the article object. So any change can be rolledback through the wiki interface.
Ah another point:
4) We need a RSS feeds of all actions that happen in the reader, like "adding a new feed", "deleting a feed", "commenting", "flagging", etc so that it's possible to follow what's happening and revert if need be.
For all changes we can use the standard xwiki WebRSS, but that won't give us very precise information. For some changes, the press review RSS can be used, as it is possible to filter on certain values for the properties (read articles, flagged articles, etc) and export in rss. Happy coding, Anca Luca
3) Good performances Depending on the type of database used and the database setup, XWiki Watch can get a little heavy for (arguable) large database sizes (~10000 fetched articles), but I think using it on xwiki.org would help better estimating these type of problems.
Yes.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jul 24, 2008, at 2:48 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 24, 2008, at 9:35 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote:
Hi devs,
As it has been already mentioned a couple of times, I strongly believe that XWiki Watch should be accessible in a sandbox on xwiki.org, for everyone to try it out and explore its features and for us to get an open real-life test of it. There is a document dedicated to the issues that might prevent this at http://watch.xwiki.org/xwiki/bin/view/Development/ XWatchOnXWikiOrg , please fill it in with any opinions you have!
Here's my +1 for having an installation of XWatch publicly available on xwiki.org, WDYT? Sure, we've already discussed it as I wanted to install it but discovered it wasn't possible at the time. I wouldn't call it a sandbox as I think it could be used for real and contain feeds related to xwiki and anything relevant.
Here are some issues I can think of: 1) Allow unregistered users to view and use the reader Since Watch is implemented using the XWiki documents & objects model, user rights follow the same model as all XWiki. Guest users use the rights we give them: for viewing / navigating through the reader, view right is enough, whereas any edit (add feed, tag/flag/trash/mark as read articles) requires edit rights. Unless there is a problem with giving edit rights to guests, I don't see exactly what is the issue with having guests use the reader.
Yes we definitely shouldn't give edit rights to guests. This leads to spamming. We need people to be registered for getting edit rights.
But if users can use the reader with only view rights then it's good. AFAIR it wasn't working before.
2) Provide ability to undo changes done by users (the revert feature of all wikis). This is especially important in a public instance: it needs to be easier to revert an error than it is to create one! As mentioned earlier, all Watch data is stored in xwiki documents & objects, so reverting is as easy as it can be in any other instance of xwiki.
Now, there is a problem with what we understand by reverting changes in a "feed reader". The first example that comes into my mind is when a user adds a feed source, say unwanted. Since the feed articles fetched from that are stored in xwiki documents, revert (wiki-way) would mean deleting the feed, but that would not trigger deleting all fetched articles. While from a feed reader point of view, reverting this change would probably mean deleting all fetched articles too. For this particular example this is not a problem because deleting a feed with all fetched articles is implemented in watch reader interface, but there is a general problem of actions and concepts interpretation in Watch: seeing it as a wiki vs. seeing it as a feed reader.
We just need to check use case by use case if we have a way to revert changes: * If a user adds an unwanted feed, we can remove it with the delete feed button so that's ok * if a user deletes a feed, how can we restore it?
A feed is an object in a XWikiDocument, so restoring from recycle bin would work perfectly fine. Same for deleted articles, groups, keywords.
* if a user creates a spammy comment or tag how can we remove them? * can a user remove a tag or comment? (probably not or maybe only his own tags/comments) * same questions for the trash and starring.
A comment for an article is a xwiki comment for the document holding the article, the tags, star, trash are properties of the article object. So any change can be rolledback through the wiki interface.
The problem is that the exposed interface is the Feed Reader one so I guess we could need some simple access to the underlying wiki pages or some admin buttons to revert changes easily.
Ah another point:
4) We need a RSS feeds of all actions that happen in the reader, like "adding a new feed", "deleting a feed", "commenting", "flagging", etc so that it's possible to follow what's happening and revert if need be.
For all changes we can use the standard xwiki WebRSS, but that won't give us very precise information.
Yes, that's probably good enough to start. We need to improve the XE WebRSS content anyway to make it easier to see changes. Then later on we could have a Watch-specific RSS feed maybe. Thanks -Vincent
For some changes, the press review RSS can be used, as it is possible to filter on certain values for the properties (read articles, flagged articles, etc) and export in rss.
Happy coding, Anca Luca
3) Good performances Depending on the type of database used and the database setup, XWiki Watch can get a little heavy for (arguable) large database sizes (~10000 fetched articles), but I think using it on xwiki.org would help better estimating these type of problems.
Yes.
Thanks -Vincent
Vincent Massol wrote: > On Jul 24, 2008, at 2:48 PM, Anca Paula Luca wrote: > >> >> Vincent Massol wrote: >>> On Jul 24, 2008, at 9:35 AM, Anca Paula Luca wrote: >>> >>>> Vincent Massol wrote: >>>>> On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote: >>>>> >>>>>> Hi devs, >>>>>> >>>>>> As it has been already mentioned a couple of times, I strongly >>>>>> believe >>>>>> that XWiki Watch should be accessible in a sandbox on xwiki.org, >>>>>> for >>>>>> everyone to try it out and explore its features and for us to >>>>>> get an >>>>>> open real-life test of it. >>>>>> There is a document dedicated to the issues that might prevent >>>>>> this at >>>>>> http://watch.xwiki.org/xwiki/bin/view/Development/ >>>>>> XWatchOnXWikiOrg , >>>>>> please fill it in with any opinions you have! >>>>>> >>>>>> Here's my +1 for having an installation of XWatch publicly >>>>>> available >>>>>> on >>>>>> xwiki.org, WDYT? >>>>> Sure, we've already discussed it as I wanted to install it but >>>>> discovered it wasn't possible at the time. I wouldn't call it a >>>>> sandbox as I think it could be used for real and contain feeds >>>>> related >>>>> to xwiki and anything relevant. >>>>> >>>>> Here are some issues I can think of: >>>>> 1) Allow unregistered users to view and use the reader >>>> Since Watch is implemented using the XWiki documents & objects >>>> model, user >>>> rights follow the same model as all XWiki. Guest users use the >>>> rights we give >>>> them: for viewing / navigating through the reader, view right is >>>> enough, whereas >>>> any edit (add feed, tag/flag/trash/mark as read articles) requires >>>> edit rights. >>>> Unless there is a problem with giving edit rights to guests, I don't >>>> see exactly >>>> what is the issue with having guests use the reader. >>> Yes we definitely shouldn't give edit rights to guests. This leads to >>> spamming. We need people to be registered for getting edit rights. >>> >>> But if users can use the reader with only view rights then it's good. >>> AFAIR it wasn't working before. >>> >>>>> 2) Provide ability to undo changes done by users (the revert >>>>> feature >>>>> of all wikis). This is especially important in a public instance: >>>>> it >>>>> needs to be easier to revert an error than it is to create one! >>>> As mentioned earlier, all Watch data is stored in xwiki documents & >>>> objects, so >>>> reverting is as easy as it can be in any other instance of xwiki. >>>> >>>> Now, there is a problem with what we understand by reverting changes >>>> in a "feed >>>> reader". The first example that comes into my mind is when a user >>>> adds a feed >>>> source, say unwanted. Since the feed articles fetched from that are >>>> stored in >>>> xwiki documents, revert (wiki-way) would mean deleting the feed, but >>>> that would >>>> not trigger deleting all fetched articles. While from a feed reader >>>> point of >>>> view, reverting this change would probably mean deleting all fetched >>>> articles >>>> too. For this particular example this is not a problem because >>>> deleting a feed >>>> with all fetched articles is implemented in watch reader interface, >>>> but there is >>>> a general problem of actions and concepts interpretation in Watch: >>>> seeing it as >>>> a wiki vs. seeing it as a feed reader. >>> We just need to check use case by use case if we have a way to revert >>> changes: >>> * If a user adds an unwanted feed, we can remove it with the delete >>> feed button so that's ok >>> * if a user deletes a feed, how can we restore it? >> A feed is an object in a XWikiDocument, so restoring from recycle >> bin would work >> perfectly fine. Same for deleted articles, groups, keywords. >> >>> * if a user creates a spammy comment or tag how can we remove them? >>> * can a user remove a tag or comment? (probably not or maybe only his >>> own tags/comments) >>> * same questions for the trash and starring. >> A comment for an article is a xwiki comment for the document holding >> the >> article, the tags, star, trash are properties of the article object. >> So any >> change can be rolledback through the wiki interface. > > The problem is that the exposed interface is the Feed Reader one so I > guess we could need some simple access to the underlying wiki pages or > some admin buttons to revert changes easily. Both interfaces are exposed (the wiki interface is available at Watch.WebHome), with default "start page" in Watch.WebHome. > >>> Ah another point: >>> >>> 4) We need a RSS feeds of all actions that happen in the reader, like >>> "adding a new feed", "deleting a feed", "commenting", "flagging", etc >>> so that it's possible to follow what's happening and revert if need >>> be. >> For all changes we can use the standard xwiki WebRSS, but that won't >> give us >> very precise information. > > Yes, that's probably good enough to start. We need to improve the XE > WebRSS content anyway to make it easier to see changes. Then later on > we could have a Watch-specific RSS feed maybe. > > Thanks > -Vincent > >> For some changes, the press review RSS can be used, as it is >> possible to filter >> on certain values for the properties (read articles, flagged >> articles, etc) and >> export in rss. >> >> Happy coding, >> Anca Luca >> >>>>> 3) Good performances >>>> Depending on the type of database used and the database setup, XWiki >>>> Watch can >>>> get a little heavy for (arguable) large database sizes (~10000 >>>> fetched >>>> articles), but I think using it on xwiki.org would help better >>>> estimating these >>>> type of problems. >>> Yes. >>> >>> Thanks >>> -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
On Jul 24, 2008, at 3:11 PM, Anca Paula Luca wrote: > Vincent Massol wrote: >> On Jul 24, 2008, at 2:48 PM, Anca Paula Luca wrote: >> >>> >>> Vincent Massol wrote: >>>> On Jul 24, 2008, at 9:35 AM, Anca Paula Luca wrote: >>>> >>>>> Vincent Massol wrote: >>>>>> On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote: >>>>>> >>>>>>> Hi devs, >>>>>>> >>>>>>> As it has been already mentioned a couple of times, I strongly >>>>>>> believe >>>>>>> that XWiki Watch should be accessible in a sandbox on xwiki.org, >>>>>>> for >>>>>>> everyone to try it out and explore its features and for us to >>>>>>> get an >>>>>>> open real-life test of it. >>>>>>> There is a document dedicated to the issues that might prevent >>>>>>> this at >>>>>>> http://watch.xwiki.org/xwiki/bin/view/Development/ >>>>>>> XWatchOnXWikiOrg , >>>>>>> please fill it in with any opinions you have! >>>>>>> >>>>>>> Here's my +1 for having an installation of XWatch publicly >>>>>>> available >>>>>>> on >>>>>>> xwiki.org, WDYT? >>>>>> Sure, we've already discussed it as I wanted to install it but >>>>>> discovered it wasn't possible at the time. I wouldn't call it a >>>>>> sandbox as I think it could be used for real and contain feeds >>>>>> related >>>>>> to xwiki and anything relevant. >>>>>> >>>>>> Here are some issues I can think of: >>>>>> 1) Allow unregistered users to view and use the reader >>>>> Since Watch is implemented using the XWiki documents & objects >>>>> model, user >>>>> rights follow the same model as all XWiki. Guest users use the >>>>> rights we give >>>>> them: for viewing / navigating through the reader, view right is >>>>> enough, whereas >>>>> any edit (add feed, tag/flag/trash/mark as read articles) requires >>>>> edit rights. >>>>> Unless there is a problem with giving edit rights to guests, I >>>>> don't >>>>> see exactly >>>>> what is the issue with having guests use the reader. >>>> Yes we definitely shouldn't give edit rights to guests. This >>>> leads to >>>> spamming. We need people to be registered for getting edit rights. >>>> >>>> But if users can use the reader with only view rights then it's >>>> good. >>>> AFAIR it wasn't working before. >>>> >>>>>> 2) Provide ability to undo changes done by users (the revert >>>>>> feature >>>>>> of all wikis). This is especially important in a public instance: >>>>>> it >>>>>> needs to be easier to revert an error than it is to create one! >>>>> As mentioned earlier, all Watch data is stored in xwiki >>>>> documents & >>>>> objects, so >>>>> reverting is as easy as it can be in any other instance of xwiki. >>>>> >>>>> Now, there is a problem with what we understand by reverting >>>>> changes >>>>> in a "feed >>>>> reader". The first example that comes into my mind is when a user >>>>> adds a feed >>>>> source, say unwanted. Since the feed articles fetched from that >>>>> are >>>>> stored in >>>>> xwiki documents, revert (wiki-way) would mean deleting the feed, >>>>> but >>>>> that would >>>>> not trigger deleting all fetched articles. While from a feed >>>>> reader >>>>> point of >>>>> view, reverting this change would probably mean deleting all >>>>> fetched >>>>> articles >>>>> too. For this particular example this is not a problem because >>>>> deleting a feed >>>>> with all fetched articles is implemented in watch reader >>>>> interface, >>>>> but there is >>>>> a general problem of actions and concepts interpretation in Watch: >>>>> seeing it as >>>>> a wiki vs. seeing it as a feed reader. >>>> We just need to check use case by use case if we have a way to >>>> revert >>>> changes: >>>> * If a user adds an unwanted feed, we can remove it with the delete >>>> feed button so that's ok >>>> * if a user deletes a feed, how can we restore it? >>> A feed is an object in a XWikiDocument, so restoring from recycle >>> bin would work >>> perfectly fine. Same for deleted articles, groups, keywords. >>> >>>> * if a user creates a spammy comment or tag how can we remove them? >>>> * can a user remove a tag or comment? (probably not or maybe only >>>> his >>>> own tags/comments) >>>> * same questions for the trash and starring. >>> A comment for an article is a xwiki comment for the document holding >>> the >>> article, the tags, star, trash are properties of the article object. >>> So any >>> change can be rolledback through the wiki interface. >> >> The problem is that the exposed interface is the Feed Reader one so I >> guess we could need some simple access to the underlying wiki pages >> or >> some admin buttons to revert changes easily. > > Both interfaces are exposed (the wiki interface is available at > Watch.WebHome), > with default "start page" in Watch.WebHome. I'm +1 to try it somewhere on xwiki.org domain. Where do you suggest? I also propose that you be the maintainer of it. This means checking every day for people doing wrong things (as we do on xwiki.org). We can always improve as we learn from people's usages of it. Thanks -Vincent >>>> Ah another point: >>>> >>>> 4) We need a RSS feeds of all actions that happen in the reader, >>>> like >>>> "adding a new feed", "deleting a feed", "commenting", "flagging", >>>> etc >>>> so that it's possible to follow what's happening and revert if need >>>> be. >>> For all changes we can use the standard xwiki WebRSS, but that won't >>> give us >>> very precise information. >> >> Yes, that's probably good enough to start. We need to improve the XE >> WebRSS content anyway to make it easier to see changes. Then later on >> we could have a Watch-specific RSS feed maybe. >> >> Thanks >> -Vincent >> >>> For some changes, the press review RSS can be used, as it is >>> possible to filter >>> on certain values for the properties (read articles, flagged >>> articles, etc) and >>> export in rss. >>> >>> Happy coding, >>> Anca Luca >>> >>>>>> 3) Good performances >>>>> Depending on the type of database used and the database setup, >>>>> XWiki >>>>> Watch can >>>>> get a little heavy for (arguable) large database sizes (~10000 >>>>> fetched >>>>> articles), but I think using it on xwiki.org would help better >>>>> estimating these >>>>> type of problems. >>>> Yes. >>>> >>>> Thanks >>>> -Vincent
Vincent Massol wrote: > On Jul 24, 2008, at 3:11 PM, Anca Paula Luca wrote: > >> Vincent Massol wrote: >>> On Jul 24, 2008, at 2:48 PM, Anca Paula Luca wrote: >>> >>>> Vincent Massol wrote: >>>>> On Jul 24, 2008, at 9:35 AM, Anca Paula Luca wrote: >>>>> >>>>>> Vincent Massol wrote: >>>>>>> On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote: >>>>>>> >>>>>>>> Hi devs, >>>>>>>> >>>>>>>> As it has been already mentioned a couple of times, I strongly >>>>>>>> believe >>>>>>>> that XWiki Watch should be accessible in a sandbox on xwiki.org, >>>>>>>> for >>>>>>>> everyone to try it out and explore its features and for us to >>>>>>>> get an >>>>>>>> open real-life test of it. >>>>>>>> There is a document dedicated to the issues that might prevent >>>>>>>> this at >>>>>>>> http://watch.xwiki.org/xwiki/bin/view/Development/ >>>>>>>> XWatchOnXWikiOrg , >>>>>>>> please fill it in with any opinions you have! >>>>>>>> >>>>>>>> Here's my +1 for having an installation of XWatch publicly >>>>>>>> available >>>>>>>> on >>>>>>>> xwiki.org, WDYT? >>>>>>> Sure, we've already discussed it as I wanted to install it but >>>>>>> discovered it wasn't possible at the time. I wouldn't call it a >>>>>>> sandbox as I think it could be used for real and contain feeds >>>>>>> related >>>>>>> to xwiki and anything relevant. >>>>>>> >>>>>>> Here are some issues I can think of: >>>>>>> 1) Allow unregistered users to view and use the reader >>>>>> Since Watch is implemented using the XWiki documents & objects >>>>>> model, user >>>>>> rights follow the same model as all XWiki. Guest users use the >>>>>> rights we give >>>>>> them: for viewing / navigating through the reader, view right is >>>>>> enough, whereas >>>>>> any edit (add feed, tag/flag/trash/mark as read articles) requires >>>>>> edit rights. >>>>>> Unless there is a problem with giving edit rights to guests, I >>>>>> don't >>>>>> see exactly >>>>>> what is the issue with having guests use the reader. >>>>> Yes we definitely shouldn't give edit rights to guests. This >>>>> leads to >>>>> spamming. We need people to be registered for getting edit rights. >>>>> >>>>> But if users can use the reader with only view rights then it's >>>>> good. >>>>> AFAIR it wasn't working before. >>>>> >>>>>>> 2) Provide ability to undo changes done by users (the revert >>>>>>> feature >>>>>>> of all wikis). This is especially important in a public instance: >>>>>>> it >>>>>>> needs to be easier to revert an error than it is to create one! >>>>>> As mentioned earlier, all Watch data is stored in xwiki >>>>>> documents & >>>>>> objects, so >>>>>> reverting is as easy as it can be in any other instance of xwiki. >>>>>> >>>>>> Now, there is a problem with what we understand by reverting >>>>>> changes >>>>>> in a "feed >>>>>> reader". The first example that comes into my mind is when a user >>>>>> adds a feed >>>>>> source, say unwanted. Since the feed articles fetched from that >>>>>> are >>>>>> stored in >>>>>> xwiki documents, revert (wiki-way) would mean deleting the feed, >>>>>> but >>>>>> that would >>>>>> not trigger deleting all fetched articles. While from a feed >>>>>> reader >>>>>> point of >>>>>> view, reverting this change would probably mean deleting all >>>>>> fetched >>>>>> articles >>>>>> too. For this particular example this is not a problem because >>>>>> deleting a feed >>>>>> with all fetched articles is implemented in watch reader >>>>>> interface, >>>>>> but there is >>>>>> a general problem of actions and concepts interpretation in Watch: >>>>>> seeing it as >>>>>> a wiki vs. seeing it as a feed reader. >>>>> We just need to check use case by use case if we have a way to >>>>> revert >>>>> changes: >>>>> * If a user adds an unwanted feed, we can remove it with the delete >>>>> feed button so that's ok >>>>> * if a user deletes a feed, how can we restore it? >>>> A feed is an object in a XWikiDocument, so restoring from recycle >>>> bin would work >>>> perfectly fine. Same for deleted articles, groups, keywords. >>>> >>>>> * if a user creates a spammy comment or tag how can we remove them? >>>>> * can a user remove a tag or comment? (probably not or maybe only >>>>> his >>>>> own tags/comments) >>>>> * same questions for the trash and starring. >>>> A comment for an article is a xwiki comment for the document holding >>>> the >>>> article, the tags, star, trash are properties of the article object. >>>> So any >>>> change can be rolledback through the wiki interface. >>> The problem is that the exposed interface is the Feed Reader one so I >>> guess we could need some simple access to the underlying wiki pages >>> or >>> some admin buttons to revert changes easily. >> Both interfaces are exposed (the wiki interface is available at >> Watch.WebHome), >> with default "start page" in Watch.WebHome. > > I'm +1 to try it somewhere on xwiki.org domain. Where do you suggest? I'm +1 for someplace around watch.xwiki.org/xwiki/bin/view/Watch/. > > I also propose that you be the maintainer of it. This means checking > every day for people doing wrong things (as we do on xwiki.org). +1 > We > can always improve as we learn from people's usages of it. > > Thanks > -Vincent > >>>>> Ah another point: >>>>> >>>>> 4) We need a RSS feeds of all actions that happen in the reader, >>>>> like >>>>> "adding a new feed", "deleting a feed", "commenting", "flagging", >>>>> etc >>>>> so that it's possible to follow what's happening and revert if need >>>>> be. >>>> For all changes we can use the standard xwiki WebRSS, but that won't >>>> give us >>>> very precise information. >>> Yes, that's probably good enough to start. We need to improve the XE >>> WebRSS content anyway to make it easier to see changes. Then later on >>> we could have a Watch-specific RSS feed maybe. >>> >>> Thanks >>> -Vincent >>> >>>> For some changes, the press review RSS can be used, as it is >>>> possible to filter >>>> on certain values for the properties (read articles, flagged >>>> articles, etc) and >>>> export in rss. >>>> >>>> Happy coding, >>>> Anca Luca >>>> >>>>>>> 3) Good performances >>>>>> Depending on the type of database used and the database setup, >>>>>> XWiki >>>>>> Watch can >>>>>> get a little heavy for (arguable) large database sizes (~10000 >>>>>> fetched >>>>>> articles), but I think using it on xwiki.org would help better >>>>>> estimating these >>>>>> type of problems. >>>>> Yes. >>>>> >>>>> Thanks >>>>> -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
On Jul 24, 2008, at 3:11 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 24, 2008, at 2:48 PM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 24, 2008, at 9:35 AM, Anca Paula Luca wrote:
> Vincent Massol wrote: >> On Jul 23, 2008, at 5:40 PM, Anca Paula Luca wrote: >> >>> Hi devs, >>> >>> As it has been already mentioned a couple of times, I strongly >>> believe >>> that XWiki Watch should be accessible in a sandbox on xwiki.org, >>> for >>> everyone to try it out and explore its features and for us to >>> get an >>> open real-life test of it. >>> There is a document dedicated to the issues that might prevent >>> this at >>> http://watch.xwiki.org/xwiki/bin/view/Development/ >>> XWatchOnXWikiOrg , >>> please fill it in with any opinions you have! >>> >>> Here's my +1 for having an installation of XWatch publicly >>> available >>> on >>> xwiki.org, WDYT? >> Sure, we've already discussed it as I wanted to install it but >> discovered it wasn't possible at the time. I wouldn't call it a >> sandbox as I think it could be used for real and contain feeds >> related >> to xwiki and anything relevant. >> >> Here are some issues I can think of: >> 1) Allow unregistered users to view and use the reader > Since Watch is implemented using the XWiki documents & objects > model, user > rights follow the same model as all XWiki. Guest users use the > rights we give > them: for viewing / navigating through the reader, view right is > enough, whereas > any edit (add feed, tag/flag/trash/mark as read articles) requires > edit rights. > Unless there is a problem with giving edit rights to guests, I > don't > see exactly > what is the issue with having guests use the reader. Yes we definitely shouldn't give edit rights to guests. This leads to spamming. We need people to be registered for getting edit rights.
But if users can use the reader with only view rights then it's good. AFAIR it wasn't working before.
>> 2) Provide ability to undo changes done by users (the revert >> feature >> of all wikis). This is especially important in a public instance: >> it >> needs to be easier to revert an error than it is to create one! > As mentioned earlier, all Watch data is stored in xwiki > documents & > objects, so > reverting is as easy as it can be in any other instance of xwiki. > > Now, there is a problem with what we understand by reverting > changes > in a "feed > reader". The first example that comes into my mind is when a user > adds a feed > source, say unwanted. Since the feed articles fetched from that > are > stored in > xwiki documents, revert (wiki-way) would mean deleting the feed, > but > that would > not trigger deleting all fetched articles. While from a feed > reader > point of > view, reverting this change would probably mean deleting all > fetched > articles > too. For this particular example this is not a problem because > deleting a feed > with all fetched articles is implemented in watch reader > interface, > but there is > a general problem of actions and concepts interpretation in Watch: > seeing it as > a wiki vs. seeing it as a feed reader. We just need to check use case by use case if we have a way to revert changes: * If a user adds an unwanted feed, we can remove it with the delete feed button so that's ok * if a user deletes a feed, how can we restore it? A feed is an object in a XWikiDocument, so restoring from recycle bin would work perfectly fine. Same for deleted articles, groups, keywords.
* if a user creates a spammy comment or tag how can we remove them? * can a user remove a tag or comment? (probably not or maybe only his own tags/comments) * same questions for the trash and starring. A comment for an article is a xwiki comment for the document holding the article, the tags, star, trash are properties of the article object. So any change can be rolledback through the wiki interface. The problem is that the exposed interface is the Feed Reader one so I guess we could need some simple access to the underlying wiki pages or some admin buttons to revert changes easily. Both interfaces are exposed (the wiki interface is available at Watch.WebHome), with default "start page" in Watch.WebHome.
I'm +1 to try it somewhere on xwiki.org domain. Where do you suggest?
I'm +1 for someplace around watch.xwiki.org/xwiki/bin/view/Watch/.
+1 for this, or for watch.xwiki.org/xwiki/bin/view/WatchXWiki/ to have an explicit watch topic. Jerome.
I also propose that you be the maintainer of it. This means checking every day for people doing wrong things (as we do on xwiki.org).
+1
We can always improve as we learn from people's usages of it.
Thanks -Vincent
Ah another point:
4) We need a RSS feeds of all actions that happen in the reader, like "adding a new feed", "deleting a feed", "commenting", "flagging", etc so that it's possible to follow what's happening and revert if need be. For all changes we can use the standard xwiki WebRSS, but that won't give us very precise information. Yes, that's probably good enough to start. We need to improve the XE WebRSS content anyway to make it easier to see changes. Then later on we could have a Watch-specific RSS feed maybe.
Thanks -Vincent
For some changes, the press review RSS can be used, as it is possible to filter on certain values for the properties (read articles, flagged articles, etc) and export in rss.
Happy coding, Anca Luca
>> 3) Good performances > Depending on the type of database used and the database setup, > XWiki > Watch can > get a little heavy for (arguable) large database sizes (~10000 > fetched > articles), but I think using it on xwiki.org would help better > estimating these > type of problems. Yes.
Thanks -Vincent
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 Jul 24, 2008, at 3:46 PM, Jerome Velociter wrote: [snip]
I'm +1 to try it somewhere on xwiki.org domain. Where do you suggest?
I'm +1 for someplace around watch.xwiki.org/xwiki/bin/view/Watch/.
+1 for this, or for watch.xwiki.org/xwiki/bin/view/WatchXWiki/ to have an explicit watch topic.
What about: news.xwiki.org? or feeds.xwiki.org? Thanks -Vincent
Vincent Massol wrote:
On Jul 24, 2008, at 3:46 PM, Jerome Velociter wrote:
[snip]
I'm +1 to try it somewhere on xwiki.org domain. Where do you suggest? I'm +1 for someplace around watch.xwiki.org/xwiki/bin/view/Watch/. +1 for this, or for watch.xwiki.org/xwiki/bin/view/WatchXWiki/ to have an explicit watch topic.
or WatchDemo. Actually any space would do it. I wouldn't say we need a specific watch topic (like xwiki), I wouldn't clean people's unrelated sources, although it could be interesting to have it all about xwiki.
What about: news.xwiki.org? or feeds.xwiki.org?
-1 for feeds.xwiki.org: Watch is not a feed reader. as for news, it could be missinterpreted as people would go there to find out what's new from us, not what's new about us from others. +0 for a new wiki. Happy coding, Anca
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Cool idea.
I'm +1 to try it somewhere on xwiki.org domain. Where do you
suggest? I'm +1 for someplace around watch.xwiki.org/xwiki/bin/view/Watch/. +1 for this, or for watch.xwiki.org/xwiki/bin/view/WatchXWiki/ to have an explicit watch topic.
What about http://www.xwiki.org/xwiki/bin/view/Main/ExternalNews then ? With a link at the top of the current news page and / or in the left panel ? Guillaume
On Jul 24, 2008, at 10:49 PM, Guillaume Lerouge wrote:
Cool idea.
I'm +1 to try it somewhere on xwiki.org domain. Where do you
suggest? I'm +1 for someplace around watch.xwiki.org/xwiki/bin/view/Watch/. +1 for this, or for watch.xwiki.org/xwiki/bin/view/WatchXWiki/ to have an explicit watch topic.
What about http://www.xwiki.org/xwiki/bin/view/Main/ExternalNews then ?
Is there really only one page for Watch? Where does it put the articles, etc? I think you need a new space. I'd be fine with http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome but I think it's better to have a top level domain name for several reasons: * better visibility * easier to go to rather than having to go xwiki.org and click on a link * easier for upgrades (XE on xwiki.org and watch are separate)
With a link at the top of the current news page and / or in the left panel ?
Yes we'll need that (in the right panel not left ;)). Thanks -Vincent
Vincent Massol wrote:
On Jul 24, 2008, at 10:49 PM, Guillaume Lerouge wrote:
Cool idea.
I'm +1 to try it somewhere on xwiki.org domain. Where do you > suggest? I'm +1 for someplace around watch.xwiki.org/xwiki/bin/view/Watch/. +1 for this, or for watch.xwiki.org/xwiki/bin/view/WatchXWiki/ to have an explicit watch topic. What about http://www.xwiki.org/xwiki/bin/view/Main/ExternalNews then ?
Is there really only one page for Watch? Where does it put the articles, etc? I think you need a new space.
Yes, you need a space. I didn't even notice that Guillaume proposed a page name, I read it as http://www.xwiki.org/xwiki/bin/view/ExternalNews/ .
I'd be fine with http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome but I think it's better to have a top level domain name for several reasons: * better visibility * easier to go to rather than having to go xwiki.org and click on a link * easier for upgrades (XE on xwiki.org and watch are separate)
this makes me +1 for a separate wiki. I would have had it in the watch wiki on xwiki.org but, since the goal is to have the latest version of watch running there, we need to make sure it is freely upgradable (which can require upgrading the underlying XE). Otherwise, I still think it should be on watch.xwiki.org rather than xwiki.org for consistency reasons, since it would be a demo of watch -- that is the main purpose as I see it, allowing people to click around and have a quick look without having to download, install, etc.
With a link at the top of the current news page and / or in the left panel ?
Yes we'll need that (in the right panel not left ;)).
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jul 25, 2008, at 10:15 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 24, 2008, at 10:49 PM, Guillaume Lerouge wrote:
Cool idea.
> I'm +1 to try it somewhere on xwiki.org domain. Where do you >> suggest? > I'm +1 for someplace around watch.xwiki.org/xwiki/bin/view/ > Watch/. +1 for this, or for watch.xwiki.org/xwiki/bin/view/WatchXWiki/ to have an explicit watch topic. What about http://www.xwiki.org/xwiki/bin/view/Main/ExternalNews then ?
Is there really only one page for Watch? Where does it put the articles, etc? I think you need a new space.
Yes, you need a space. I didn't even notice that Guillaume proposed a page name, I read it as http://www.xwiki.org/xwiki/bin/view/ExternalNews/ .
I'd be fine with http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome but I think it's better to have a top level domain name for several reasons: * better visibility * easier to go to rather than having to go xwiki.org and click on a link * easier for upgrades (XE on xwiki.org and watch are separate)
this makes me +1 for a separate wiki. I would have had it in the watch wiki on xwiki.org but, since the goal is to have the latest version of watch running there, we need to make sure it is freely upgradable (which can require upgrading the underlying XE).
Otherwise, I still think it should be on watch.xwiki.org rather than xwiki.org for consistency reasons, since it would be a demo of watch -- that is the main purpose as I see it, allowing people to click around and have a quick look without having to download, install, etc.
Then we still have a disagreement :) Right now (and I'd like to keep it this way) all wikis on the xwiki.org domain are for *real*. They are not test platforms for people to see how xwiki works and have some fun trying it. They have real usages (documentation of the xwiki software). We have one exception: this is playground.xwiki.org which is there for people to test and play around. Thus my proposal is: 1) have a new wiki (news.xwiki.org, same as we have jira.xwiki.org, svn.xwiki.org and maven.xwiki.org) which will be our news "portal". Note: It will also listen to the xwiki.org Blog feed. 2) have a Watch space in playground.xwiki.org for people to try out Watch. But I'm -1 to have a watch playground on watch.xwiki.org since I don't want to blur the lines and I want to make it very clear that demo/ testing is on playground.xwiki.org and the rest is for real. WDYT? Thanks -Vincent
With a link at the top of the current news page and / or in the left panel ?
Yes we'll need that (in the right panel not left ;)).
Thanks -Vincent
Vincent Massol wrote:
On Jul 25, 2008, at 10:15 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
I'd be fine with http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome but I think it's better to have a top level domain name for several reasons: * better visibility * easier to go to rather than having to go xwiki.org and click on a link * easier for upgrades (XE on xwiki.org and watch are separate) this makes me +1 for a separate wiki. I would have had it in the watch wiki on xwiki.org but, since the goal is to have the latest version of watch running there, we need to make sure it is freely upgradable (which can require upgrading the underlying XE).
Otherwise, I still think it should be on watch.xwiki.org rather than xwiki.org for consistency reasons, since it would be a demo of watch -- that is the main purpose as I see it, allowing people to click around and have a quick look without having to download, install, etc.
Then we still have a disagreement :)
Right now (and I'd like to keep it this way) all wikis on the xwiki.org domain are for *real*. They are not test platforms for people to see how xwiki works and have some fun trying it. They have real usages (documentation of the xwiki software). We have one exception: this is playground.xwiki.org which is there for people to test and play around.
Thus my proposal is:
1) have a new wiki (news.xwiki.org, same as we have jira.xwiki.org, svn.xwiki.org and maven.xwiki.org) which will be our news "portal". Note: It will also listen to the xwiki.org Blog feed. 2) have a Watch space in playground.xwiki.org for people to try out Watch.
it makes a lot of sense, so: +0 for 1: it would be nice to have it, it would be nice to have it working properly (having people *really* collaboratively watching) but that is not the purpose I started this thread for. +1 for 2, since this one is :). But now we're back one mail to the upgrade problem: I would like to have always the last version of watch running in the playground, which could require platform / XE upgrades, from time to time, since the plugins & modules that watch is using don't really have their own lifecycle, yet. And one more thing, I'm not very up to date with how it works, but isn't the playground cleaned daily? Happy coding, Anca
But I'm -1 to have a watch playground on watch.xwiki.org since I don't want to blur the lines and I want to make it very clear that demo/ testing is on playground.xwiki.org and the rest is for real.
WDYT?
Thanks -Vincent
Yes we'll need that (in the right panel not left ;)).
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jul 25, 2008, at 10:56 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 25, 2008, at 10:15 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
I'd be fine with http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome but I think it's better to have a top level domain name for several reasons: * better visibility * easier to go to rather than having to go xwiki.org and click on a link * easier for upgrades (XE on xwiki.org and watch are separate) this makes me +1 for a separate wiki. I would have had it in the watch wiki on xwiki.org but, since the goal is to have the latest version of watch running there, we need to make sure it is freely upgradable (which can require upgrading the underlying XE).
Otherwise, I still think it should be on watch.xwiki.org rather than xwiki.org for consistency reasons, since it would be a demo of watch -- that is the main purpose as I see it, allowing people to click around and have a quick look without having to download, install, etc.
Then we still have a disagreement :)
Right now (and I'd like to keep it this way) all wikis on the xwiki.org domain are for *real*. They are not test platforms for people to see how xwiki works and have some fun trying it. They have real usages (documentation of the xwiki software). We have one exception: this is playground.xwiki.org which is there for people to test and play around.
Thus my proposal is:
1) have a new wiki (news.xwiki.org, same as we have jira.xwiki.org, svn.xwiki.org and maven.xwiki.org) which will be our news "portal". Note: It will also listen to the xwiki.org Blog feed. 2) have a Watch space in playground.xwiki.org for people to try out Watch.
it makes a lot of sense, so: +0 for 1: it would be nice to have it, it would be nice to have it working properly (having people *really* collaboratively watching) but that is not the purpose I started this thread for.
I think we would learn a lot from it, eating our own dog food at the community level.
+1 for 2, since this one is :). But now we're back one mail to the upgrade problem: I would like to have always the last version of watch running in the playground, which could require platform / XE upgrades, from time to time, since the plugins & modules that watch is using don't really have their own lifecycle, yet.
We need to talk to Raff. I think right now playground is a subwiki on the xwiki.org farm. Right now the xwiki.org is upgraded to the latest version of XE whenever it's released (within 1 or 2 weeks usually) so I don't see a problem. When we do this upgrade we can upgrade watch too. And if the watch releases comes later we upgrade watch only. Unless final watch releases use non final XE releases. Is that the case? We can also decide that playground has always the latest release but this means potentially non stable releases and I'm not sure it's a good idea since users testing xwiki might find it non stable and decide not to use xwiki because of this...
And one more thing, I'm not very up to date with how it works, but isn't the playground cleaned daily?
Yes and that's the good thing! ;) Watch would be cleaned daily too. We just need to populate it with a few predefined items and save that DB for the restore. Thanks -Vincent
But I'm -1 to have a watch playground on watch.xwiki.org since I don't want to blur the lines and I want to make it very clear that demo/ testing is on playground.xwiki.org and the rest is for real.
WDYT?
Thanks -Vincent
Yes we'll need that (in the right panel not left ;)).
Thanks -Vincent
Vincent Massol wrote:
On Jul 25, 2008, at 10:56 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 25, 2008, at 10:15 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
I'd be fine with http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome but I think it's better to have a top level domain name for several reasons: * better visibility * easier to go to rather than having to go xwiki.org and click on a link * easier for upgrades (XE on xwiki.org and watch are separate) this makes me +1 for a separate wiki. I would have had it in the watch wiki on xwiki.org but, since the goal is to have the latest version of watch running there, we need to make sure it is freely upgradable (which can require upgrading the underlying XE).
Otherwise, I still think it should be on watch.xwiki.org rather than xwiki.org for consistency reasons, since it would be a demo of watch -- that is the main purpose as I see it, allowing people to click around and have a quick look without having to download, install, etc. Then we still have a disagreement :)
Right now (and I'd like to keep it this way) all wikis on the xwiki.org domain are for *real*. They are not test platforms for people to see how xwiki works and have some fun trying it. They have real usages (documentation of the xwiki software). We have one exception: this is playground.xwiki.org which is there for people to test and play around.
Thus my proposal is:
1) have a new wiki (news.xwiki.org, same as we have jira.xwiki.org, svn.xwiki.org and maven.xwiki.org) which will be our news "portal". Note: It will also listen to the xwiki.org Blog feed. 2) have a Watch space in playground.xwiki.org for people to try out Watch. it makes a lot of sense, so: +0 for 1: it would be nice to have it, it would be nice to have it working properly (having people *really* collaboratively watching) but that is not the purpose I started this thread for.
I think we would learn a lot from it, eating our own dog food at the community level.
+1 for 2, since this one is :). But now we're back one mail to the upgrade problem: I would like to have always the last version of watch running in the playground, which could require platform / XE upgrades, from time to time, since the plugins & modules that watch is using don't really have their own lifecycle, yet.
We need to talk to Raff. I think right now playground is a subwiki on the xwiki.org farm.
Right now the xwiki.org is upgraded to the latest version of XE whenever it's released (within 1 or 2 weeks usually) so I don't see a problem. When we do this upgrade we can upgrade watch too. And if the watch releases comes later we upgrade watch only. Unless final watch releases use non final XE releases. Is that the case?
no, it is not. But XWatch milestones do use XE milestones and, since Watch release cycles are pretty long for the moment, it would be interesting to have all milestones. Do we use milestones on xwiki.org? Happy coding, Anca
We can also decide that playground has always the latest release but this means potentially non stable releases and I'm not sure it's a good idea since users testing xwiki might find it non stable and decide not to use xwiki because of this...
And one more thing, I'm not very up to date with how it works, but isn't the playground cleaned daily?
Yes and that's the good thing! ;) Watch would be cleaned daily too. We just need to populate it with a few predefined items and save that DB for the restore.
Thanks -Vincent
But I'm -1 to have a watch playground on watch.xwiki.org since I don't want to blur the lines and I want to make it very clear that demo/ testing is on playground.xwiki.org and the rest is for real.
WDYT?
Thanks -Vincent
Yes we'll need that (in the right panel not left ;)).
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jul 25, 2008, at 11:32 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 25, 2008, at 10:56 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 25, 2008, at 10:15 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
I'd be fine with http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome but I think it's better to have a top level domain name for several reasons: * better visibility * easier to go to rather than having to go xwiki.org and click on a link * easier for upgrades (XE on xwiki.org and watch are separate) this makes me +1 for a separate wiki. I would have had it in the watch wiki on xwiki.org but, since the goal is to have the latest version of watch running there, we need to make sure it is freely upgradable (which can require upgrading the underlying XE).
Otherwise, I still think it should be on watch.xwiki.org rather than xwiki.org for consistency reasons, since it would be a demo of watch -- that is the main purpose as I see it, allowing people to click around and have a quick look without having to download, install, etc. Then we still have a disagreement :)
Right now (and I'd like to keep it this way) all wikis on the xwiki.org domain are for *real*. They are not test platforms for people to see how xwiki works and have some fun trying it. They have real usages (documentation of the xwiki software). We have one exception: this is playground.xwiki.org which is there for people to test and play around.
Thus my proposal is:
1) have a new wiki (news.xwiki.org, same as we have jira.xwiki.org, svn.xwiki.org and maven.xwiki.org) which will be our news "portal". Note: It will also listen to the xwiki.org Blog feed. 2) have a Watch space in playground.xwiki.org for people to try out Watch. it makes a lot of sense, so: +0 for 1: it would be nice to have it, it would be nice to have it working properly (having people *really* collaboratively watching) but that is not the purpose I started this thread for.
I think we would learn a lot from it, eating our own dog food at the community level.
+1 for 2, since this one is :). But now we're back one mail to the upgrade problem: I would like to have always the last version of watch running in the playground, which could require platform / XE upgrades, from time to time, since the plugins & modules that watch is using don't really have their own lifecycle, yet.
We need to talk to Raff. I think right now playground is a subwiki on the xwiki.org farm.
Right now the xwiki.org is upgraded to the latest version of XE whenever it's released (within 1 or 2 weeks usually) so I don't see a problem. When we do this upgrade we can upgrade watch too. And if the watch releases comes later we upgrade watch only. Unless final watch releases use non final XE releases. Is that the case?
no, it is not. But XWatch milestones do use XE milestones and, since Watch release cycles are pretty long for the moment, it would be interesting to have all milestones. Do we use milestones on xwiki.org?
No. XWiki.org must be stable. I'd suggest you make smaller release cycles :) That can only be good! Thanks -Vincent [snip]
On Jul 25, 2008, at 11:32 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 25, 2008, at 10:56 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 25, 2008, at 10:15 AM, Anca Paula Luca wrote:
Vincent Massol wrote: > I'd be fine with > http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome > but I think it's better to have a top level domain name for > several > reasons: > * better visibility > * easier to go to rather than having to go xwiki.org and click > on a > link > * easier for upgrades (XE on xwiki.org and watch are separate) this makes me +1 for a separate wiki. I would have had it in the watch wiki on xwiki.org but, since the goal is to have the latest version of watch running there, we need to make sure it is freely upgradable (which can require upgrading the underlying XE).
Otherwise, I still think it should be on watch.xwiki.org rather than xwiki.org for consistency reasons, since it would be a demo of watch -- that is the main purpose as I see it, allowing people to click around and have a quick look without having to download, install, etc. Then we still have a disagreement :)
Right now (and I'd like to keep it this way) all wikis on the xwiki.org domain are for *real*. They are not test platforms for people to see how xwiki works and have some fun trying it. They have real usages (documentation of the xwiki software). We have one exception: this is playground.xwiki.org which is there for people to test and play around.
Thus my proposal is:
1) have a new wiki (news.xwiki.org, same as we have jira.xwiki.org, svn.xwiki.org and maven.xwiki.org) which will be our news "portal". Note: It will also listen to the xwiki.org Blog feed. 2) have a Watch space in playground.xwiki.org for people to try out Watch. it makes a lot of sense, so: +0 for 1: it would be nice to have it, it would be nice to have it working properly (having people *really* collaboratively watching) but that is not the purpose I started this thread for.
I think we would learn a lot from it, eating our own dog food at the community level.
+1 for 2, since this one is :). But now we're back one mail to the upgrade problem: I would like to have always the last version of watch running in the playground, which could require platform / XE upgrades, from time to time, since the plugins & modules that watch is using don't really have their own lifecycle, yet.
We need to talk to Raff. I think right now playground is a subwiki on the xwiki.org farm.
Right now the xwiki.org is upgraded to the latest version of XE whenever it's released (within 1 or 2 weeks usually) so I don't see a problem. When we do this upgrade we can upgrade watch too. And if the watch releases comes later we upgrade watch only. Unless final watch releases use non final XE releases. Is that the case?
no, it is not. But XWatch milestones do use XE milestones and, since Watch release cycles are pretty long for the moment, it would be interesting to have all milestones. Do we use milestones on xwiki.org?
No. XWiki.org must be stable.
Shouldn't the watch instance (news.xwiki.org or the name we will find for it) be hosted on a different server anyway ? At least to begin with, I think it would be safer not to take the risk having xwiki.org stability and performances be affected by the introduction of the watch instance. This would allow too to have a separate upgrade cycle, and possibly upgrade to milestones as well. For the name, I have a (little) problem with news.xwiki.org : it kind of implies it is news from xwiki (like a blog feed), and we should/will watch on a wider spectrum than that IMO. But I cannot figure out a better name :p I though about wikinews.xwiki.org, wikiwatch.xwiki.org, monitoring.xwiki.org but it does not sound as good as news.xwiki.org... Regards, Jerome.
I'd suggest you make smaller release cycles :) That can only be good!
Thanks -Vincent
[snip]
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jul 25, 2008, at 12:32 PM, Jerome Velociter wrote:
On Jul 25, 2008, at 11:32 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 25, 2008, at 10:56 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 25, 2008, at 10:15 AM, Anca Paula Luca wrote:
> Vincent Massol wrote: >> I'd be fine with >> http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome >> but I think it's better to have a top level domain name for >> several >> reasons: >> * better visibility >> * easier to go to rather than having to go xwiki.org and click >> on a >> link >> * easier for upgrades (XE on xwiki.org and watch are separate) > this makes me +1 for a separate wiki. I would have had it in the > watch wiki on > xwiki.org but, since the goal is to have the latest version of > watch > running > there, we need to make sure it is freely upgradable (which can > require upgrading > the underlying XE). > > Otherwise, I still think it should be on watch.xwiki.org rather > than > xwiki.org > for consistency reasons, since it would be a demo of watch -- > that > is the main > purpose as I see it, allowing people to click around and have a > quick look > without having to download, install, etc. Then we still have a disagreement :)
Right now (and I'd like to keep it this way) all wikis on the xwiki.org domain are for *real*. They are not test platforms for people to see how xwiki works and have some fun trying it. They have real usages (documentation of the xwiki software). We have one exception: this is playground.xwiki.org which is there for people to test and play around.
Thus my proposal is:
1) have a new wiki (news.xwiki.org, same as we have jira.xwiki.org, svn.xwiki.org and maven.xwiki.org) which will be our news "portal". Note: It will also listen to the xwiki.org Blog feed. 2) have a Watch space in playground.xwiki.org for people to try out Watch. it makes a lot of sense, so: +0 for 1: it would be nice to have it, it would be nice to have it working properly (having people *really* collaboratively watching) but that is not the purpose I started this thread for.
I think we would learn a lot from it, eating our own dog food at the community level.
+1 for 2, since this one is :). But now we're back one mail to the upgrade problem: I would like to have always the last version of watch running in the playground, which could require platform / XE upgrades, from time to time, since the plugins & modules that watch is using don't really have their own lifecycle, yet.
We need to talk to Raff. I think right now playground is a subwiki on the xwiki.org farm.
Right now the xwiki.org is upgraded to the latest version of XE whenever it's released (within 1 or 2 weeks usually) so I don't see a problem. When we do this upgrade we can upgrade watch too. And if the watch releases comes later we upgrade watch only. Unless final watch releases use non final XE releases. Is that the case?
no, it is not. But XWatch milestones do use XE milestones and, since Watch release cycles are pretty long for the moment, it would be interesting to have all milestones. Do we use milestones on xwiki.org?
No. XWiki.org must be stable.
Shouldn't the watch instance (news.xwiki.org or the name we will find for it) be hosted on a different server anyway ? At least to begin with, I think it would be safer not to take the risk having xwiki.org stability and performances be affected by the introduction of the watch instance. This would allow too to have a separate upgrade cycle, and possibly upgrade to milestones as well.
For the name, I have a (little) problem with news.xwiki.org : it kind of implies it is news from xwiki (like a blog feed), and we should/will watch on a wider spectrum than that IMO. But I cannot figure out a better name :p I though about wikinews.xwiki.org, wikiwatch.xwiki.org, monitoring.xwiki.org but it does not sound as good as news.xwiki.org...
It depends how you view xwiki. If you think of it as an ecosystem it's less of an issue IMO. However you're right, it raises the question of what we want to survey. Several options: * news only related to xwiki, i.e. articles, blogs, etc * news related to wikis in general * news related to collaboration tools I don't think we can say right now what it'll be. wikinews is too restrictive for collaborative news. I think I still prefer news as it's generic, short and concise. We can explain on the home page what it's about. Thanks -Vincent
I'd suggest you make smaller release cycles :) That can only be good!
Thanks -Vincent
[snip]
I'm +1 for news.xwiki.org . For a start it could be news from feeds on XWiki coming from blog search engines. Other topics we might want to watch are news related to other Open-Source projects used with or within XWiki (such as hibernate, Tomcat, GWT, MySql). Let's start small, we can always add additional sources later on. We could also write a customized homepage for news.xwiki.org with a number boxes : news on XWiki from XWiki, news on XWiki from outside, general wiki news, news on Open Source projects used by XWiki and manage the articles displayed on them using tags in the reader interface. About the name : news.xwiki.org sounds good to me, it's generic enough and says that, well, news that are somewhat related to XWiki are available on the page. I'm also +1 with having a Watch space on playground.xwiki.org, which would be cool for people willing to give it a quick look. Guillaume On Fri, Jul 25, 2008 at 12:54 PM, Vincent Massol <[email protected]> wrote:
On Jul 25, 2008, at 12:32 PM, Jerome Velociter wrote:
On Jul 25, 2008, at 11:32 AM, Anca Paula Luca wrote:
Vincent Massol wrote:
On Jul 25, 2008, at 10:56 AM, Anca Paula Luca wrote:
Vincent Massol wrote: > On Jul 25, 2008, at 10:15 AM, Anca Paula Luca wrote: > >> Vincent Massol wrote: >>> I'd be fine with >>> http://www.xwiki.org/xwiki/bin/view/ExternalNews/WebHome >>> but I think it's better to have a top level domain name for >>> several >>> reasons: >>> * better visibility >>> * easier to go to rather than having to go xwiki.org and click >>> on a >>> link >>> * easier for upgrades (XE on xwiki.org and watch are separate) >> this makes me +1 for a separate wiki. I would have had it in the >> watch wiki on >> xwiki.org but, since the goal is to have the latest version of >> watch >> running >> there, we need to make sure it is freely upgradable (which can >> require upgrading >> the underlying XE). >> >> Otherwise, I still think it should be on watch.xwiki.org rather >> than >> xwiki.org >> for consistency reasons, since it would be a demo of watch -- >> that >> is the main >> purpose as I see it, allowing people to click around and have a >> quick look >> without having to download, install, etc. > Then we still have a disagreement :) > > Right now (and I'd like to keep it this way) all wikis on the > xwiki.org domain are for *real*. They are not test platforms for > people to see how xwiki works and have some fun trying it. They > have > real usages (documentation of the xwiki software). > We have one exception: this is playground.xwiki.org which is > there > for > people to test and play around. > > Thus my proposal is: > > 1) have a new wiki (news.xwiki.org, same as we have > jira.xwiki.org, > svn.xwiki.org and maven.xwiki.org) which will be our news > "portal". > Note: It will also listen to the xwiki.org Blog feed. > 2) have a Watch space in playground.xwiki.org for people to try > out > Watch. it makes a lot of sense, so: +0 for 1: it would be nice to have it, it would be nice to have it working properly (having people *really* collaboratively watching) but that is not the purpose I started this thread for.
I think we would learn a lot from it, eating our own dog food at the community level.
+1 for 2, since this one is :). But now we're back one mail to the upgrade problem: I would like to have always the last version of watch running in the playground, which could require platform / XE upgrades, from time to time, since the plugins & modules that watch is using don't really have their own lifecycle, yet.
We need to talk to Raff. I think right now playground is a subwiki on the xwiki.org farm.
Right now the xwiki.org is upgraded to the latest version of XE whenever it's released (within 1 or 2 weeks usually) so I don't see a problem. When we do this upgrade we can upgrade watch too. And if the watch releases comes later we upgrade watch only. Unless final watch releases use non final XE releases. Is that the case?
no, it is not. But XWatch milestones do use XE milestones and, since Watch release cycles are pretty long for the moment, it would be interesting to have all milestones. Do we use milestones on xwiki.org?
No. XWiki.org must be stable.
Shouldn't the watch instance (news.xwiki.org or the name we will find for it) be hosted on a different server anyway ? At least to begin with, I think it would be safer not to take the risk having xwiki.org stability and performances be affected by the introduction of the watch instance. This would allow too to have a separate upgrade cycle, and possibly upgrade to milestones as well.
For the name, I have a (little) problem with news.xwiki.org : it kind of implies it is news from xwiki (like a blog feed), and we should/will watch on a wider spectrum than that IMO. But I cannot figure out a better name :p I though about wikinews.xwiki.org, wikiwatch.xwiki.org, monitoring.xwiki.org but it does not sound as good as news.xwiki.org...
It depends how you view xwiki. If you think of it as an ecosystem it's less of an issue IMO. However you're right, it raises the question of what we want to survey.
Several options: * news only related to xwiki, i.e. articles, blogs, etc * news related to wikis in general * news related to collaboration tools
I don't think we can say right now what it'll be. wikinews is too restrictive for collaborative news.
I think I still prefer news as it's generic, short and concise. We can explain on the home page what it's about.
Thanks -Vincent
I'd suggest you make smaller release cycles :) That can only be good!
Thanks -Vincent
[snip]
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi devs, the following idea seems to have emerged from the discussion: we will have 2 instances of XWatch open for public - a quick test playground hosted in the playground - and real-life instance of collaborative watching for the community, hosted at news.xwiki.org, preferably on a different server (I myself prefer to have it safely away from xwiki.org server). As for the watch subject, I propose it to do it the standard way: xwiki (for a start) and (potential) similar projects ("competitors"). If no one has anything against it, I will look forward into implementing it the next days. Happy coding, Anca Anca Paula Luca wrote:
Hi devs,
As it has been already mentioned a couple of times, I strongly believe that XWiki Watch should be accessible in a sandbox on xwiki.org, for everyone to try it out and explore its features and for us to get an open real-life test of it. There is a document dedicated to the issues that might prevent this at http://watch.xwiki.org/xwiki/bin/view/Development/XWatchOnXWikiOrg , please fill it in with any opinions you have!
Here's my +1 for having an installation of XWatch publicly available on xwiki.org, WDYT?
Happy coding, Anca
P.S: Sorry for the duplicate email, I forgot the subject in the previous one and I thought it's important enough to deserve duplicating. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Anca Paula Luca -
Guillaume Lerouge -
Jerome Velociter -
Vincent Massol