On my sweeper installation content from channels is not getting pulled in. I keep getting messages like:

Jan 19 23:35:30     [debug] Core::Modules::SiSPS::Parsers::TwitterParser::GetForTwitterSearch [Skipped feed item as date 2011-01-19T23:12:35-08:00 less than last sucessful run (2011-01-19T23:34:29-08:00)]

and

Jan 19 23:35:39     [debug] Core::Modules::SiSPS::Parsers::GoogleNewsParser::GetAndParse [Skipped feed item as date 2011-01-19T10:47:00-08:00 less than last sucessful run (2011-01-19T23:34:39-08:00)]

The problem I think is due to lag of the internet compared with the frequency that each channel is getting updated. Each channel will be checked about once a minute and will have its lastSucecess time updated. The next time content items are looked for they will be skipped if they are older then the channels lastSuccess value.

I am not sure what the solution is here, but this is preventing any content from getting pulled.

ushahidi/Sweeper#2

It is unclear how sweeper is to be installed with swiftriver, or how to integrate with ushahidi. I also see that there is a apps/sweeper directory in the swiftriver trunk. What is the relationship? Is Swiftriver/apps/sweeper getting pulled out?

Sources can be added, activated and deactivated, but there is no way to edit them after they have been created.

There should be an option that allows users to make sure content is being aggregated otherwise if there's no new content produced by their sources, they might assume that aggregation is broken or vice versa.

Failure to do this check causes step 6 of the installer (AllowOverrideChecks) to fail with a misleading message. The following patch to head will fix this:

--- a/installer/steps/ReadWriteAccess.php
+++ b/installer/steps/ReadWriteAccess.php
@@ -45,6 +45,7 @@ class ReadWriteAccess implements IInstallStep
                                     is_writable(dirname(__FILE__)."/../../core/Modules") &&
                                     is_writable(dirname(__FILE__)."/../../core/Cache") &&
                                     is_writable(dirname(__FILE__)."/../../web/application/cache") &&
+                                    is_writable(dirname(__FILE__)."/../../web/application/logs") &&
                                     is_writable(dirname(__FILE__)."/../../web/modules");
         $directoriesCheck->text = $directoriesCheck->result
                 ? "All the directories have the correct permissions."

Have to look at this from the Sweeper app (May be a parser issue)

When adding a new feed it would be nice to be able to specify how far back in time you would like to pull in feeds from.

The content tabs (for accurate, inaccurate, cross-talk, and irrelevant) show 20 content items, but give you no way to dig into anything older.

Sweeper would greatly benefit from a tool to search content besides just tags (at the dashboard level, not the source level). If a sweeper comes in and wants to only moderate content that is matching "X", they have to just hope one of those is nearby and can click the tag, otherwise there's no easy user specified searching filter.

Apparently I can add users, but the only way to manage/delete them is to do it at the database level? If there is a tool for this in the system, it is unnecessarily well hidden.

When you click the content icon for Twitter content, the source, channel, and veracity all come up fine, but the link is not properly rendered, coming out like:
web" target="_blank">web

See screenshot: http://i53.tinypic.com/2qd1ye1.jpg

link broken, remove double url

Currently we only accept textual parameters (that is for every turbine or plugin the parameters are actually presented only in text boxes). We can make this better. For instance:

1. Text / String - Text box
2. Boolean - Checkbox
3. List - Drop down

I see in examples and documentation where content swept in from Flickr sources shows a Flickr icon and the images are displayed inline. In practice, that doesn't seem to be the case. It gets a generic feed icon, and no image is shown.

It seems the only way to actually view content is to go through the extra steps of clicking the content's icon. This is non-discoverable and unintuitive for users that are expecting the traditional convention of clickable headers.

In some cases, tags on content are being generated from attributes in HTML tags. The primary offender appears to be images, which are causing the creation of tags like "alt," "width," "height," and "src." But it looks like any HTML will do it, as you'll also see things like "title" or "href" too. The engine should ignore data inside the HTML tag markup itself, since that isn't actually "content."

For every view we offer users to display content, we should offer a JSON feed of that view