Projects/Ideas for Contributors

This page is a listing of ideas for projects that new contributors can get involved with, either by contributing code or by helping define specs for how such functionality should/would work. The listing is in no particular order.

Markup language support

• Markdown, Textile, rST (?), HTML
• Already fields to handle this (body vs body_html, summary vs summary_html), but code still needs to be written in models' save() functions, and possibly an additional non-editable model field to store which markup language is used for that entry's field. Alternatively, use a setting, but that means migration work if site ever decides to change markup language.
• Add custom syntax to markup languages to support inserting special types of content, like internal links, or embed media items in-line. Markdown has good support for extensions, other languages should have something similar or else we can do some pre-processing upon save.

Flesh out comment functionality and UI

• Take advantage of Django's new support for custom comment apps to customize functionality.
• Replace comment-utils with either django-gatekeeper or else functionality now built into contrib.comments.
• Test integration with Akismet and reCaptcha
• Ajax-powered moderation actions (approve/reject) - see YDN
• FB Connect (see below
• Add support for threaded comments.
• For reference, see the original spec from the project planning process.

Facebook Connect/integration

• Support FB connect login in lieu of creating a site user account
• Support FB connect for posting comments and events
• Support sharing of site links, media content, comments, etc. via their Facebook feed/wall

Email functionality

• Mail queue - optionally use django-mailer as the base
• Verify and possibly refactor core.emailthis to use queue and to work properly. Ask Rob for details.
• Headline/notification emails
  • Create admin actions so editors can select issues or articles to send headlines for
  • Create forms for users to sign up for various email options (headlines, breaking news, etc.)
  • Extend core.countthis to track click rates from emails
  • Extend core.countthis to include tracking of email views using 1x1 pixel counter image. Granted, this will only track those people using Rich/HTML view for emails, and of those only ones who download images; but this will be a useful number to sell to advertisers, since it shows how many times an ad would be seen (or, by subtracting this number from the total number sent, you can determine how many would see a text version of the ad).
• For reference, see the original spec from the project planning phase.

Search

• Evaluate replacing django-sphinx with Haystack.
  • We originally chose Sphinx to power search because of its lightning fast indexing and search, and the desire to avoid installation of anything Java-based (tend to be memory hogs, which is bad for memory-constrained VPS accounts which most news sites will run on).
  • Advantage of using Haystack would be the ability to bundle Whoosh (pure-python search), which means search could work without installing any external dependencies (e.g., Sphinx, Solr, Lucene).
• Replace search registration system with declarative syntax. Required if switching to Haystack, but desired even if keeping with django-sphinx.

NewsMixer

• Integrate NewsMixer as alternative to Django contrib.comments-derived comments functionality.

Improve core.sharethis

• Add support for using AddThis
• Do we really need core.sharethis functionality? Sites can either use AddThis or will hard-core such links into their templates. Perhaps just provide an easy means to extract a truly absolute url (including http:// and domain name) for content.

Additional media types

• Flash objects - for interactive features/graphics
• Charts/graphs/tables - functionality to make it easier to create data-powered features. Could be powered by Google Charts API, or any number of JavaScript based solutions, or even rendered server side using Cairo or similar graphics library.
• Hosted videos - currently Video model only supports OEmbed-providers, specifically YouTube presently. If a site wants to host their own videos, we shouldn't stop them from doing so. Perhaps set up an OEmbed server to serve up the hosted videos via the OEmbed protocol, in which case they could continue to use the normal Video model for actually posting them, while simultaneously allowing other sites to embed the videos.

Polls

• Simple or advanced polling functionality. Doesn't necessarily need to replace advanced services like Wufoo, but at least basic polling (single question?) would be useful.
• If it can do analytics, all the better, but just simple votes counts are probably sufficient.
• Restrict votes to one per IP/user account?

Sources/Citations

• Add a way to track the sources used in writing the story. Staffers would add these sources as the article is written/edited.
• Allow for sophisticated searching of the sources database (in admin).
  • Most useful would be to search by the tags used on the article for which the source was used. For example, if I was writing a story about the city Board of Education, I could search for that tag and see all sources used to write stories about that topic (probably sorted by # of times used or by most recent uses). This could be a very powerful tool for the reporters and for story planning.
• This should probably include contact information for the sources, although it would be necessary to have a means of restricting access to such contact info for some sources (e.g., restrictive sources like the president of the university).
  • White-list access control. Can default to "everyone", but should be able to limit to a desk or to a set of individuals.

Support for print workflow

• Allow ability to store the print headline for an article that also appears in print. While it may often be the same depending on the news org, the ability to have a different (e.g., more verbose) headline online is a key component of publishing online.
• Similarly, store the print publication date, which may be different than the online edition. For exapmle, a weekly publication may continually post online but only print once a week.
• Give ability (read-only?) to P&D staffers to access all the article information at any given point in the workflow, so that they can do layout in parallel with the editing process.
• Export in a format importable by InDesign and/or InCopy.
• Export/print a formatted page to facilitate doping process (integrate with Digital Newsroom).

Analytics

• Daily morning email to administrators/top news org positions with recap of previous day's traffic numbers, including breakdown by page and overall numbers. See YDN stats email (ask Max).
• Integrate with new Google Analytics API to show some stats on admin dashboard.
• Possible Python client - http://blog.clintecker.com/post/100021441/python-google-analytics-client-how-to-use-it-and-how

Default site theme

• Create a default theme for distribution with the project. The current set of templates shipped with Courant are a bit outdated, and may be broken due to changes since they were created earlier in the project.

Locations

• Add locations to events, articles, etc.
• Can either use Google Maps API (or similar API) or potentially GeoDjango?.
  • GMaps is much easier to work with, and doesn't require difficult-to-install prerequisites like GeoDjango?.

Article Templates

• Expand Article's detailed view to support a more robust template search path for easier customization.
  • Rather than requiring a new DisplayType? for every single variation, have the view search for a template for the DisplayType? by section path. Basically, use the same search pattern as section view uses, but look for the DisplayType?'s template name instead (and start within the 'articles' template directory).
  • A main use case would be for creating different templates for articles in a given section, like a "Blogs" section or something like that.
  • Could be further expanded by adding a date+slug-based path as the first option. So if I want to do a one-off template for an article "King Kong invades NYC" on 4/15/2009, I create a template "articles/2009/04/15/king-king-invades-nyc.html". This would effectively ignore the DisplayType? designation for that Article, so maybe Courant should ship with a fixture that has a DisplayType? called "Custom" by default. I'm not sure that it necessarily needs to be special-cased by the code, but it would serve as a notification to the writers/staffers that the page uses a special template.

Tests

• Help create test suite for all the Python code (models, views, template tags, etc.).

Media

• Import images from a Flickr account or group (use AgroApp??)