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!

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.

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.

>>> 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.

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)

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.

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?