A page for listing tasks that are suitable first projects for new developers.

Firefox plug-in for creating new projects

Very useful for getting people started w/ OpenPlans.  And a good bite-sized autonomous task for a developer getting started. (Why a plug-in?  Please explain more -- ianb)  Well, the idea is that someone will have an urge to create a project while on task with something else.  If it's possible to create a project by simply pushing a button on my FF tool bar and filling in the info w/o having to leave the page that I'm already on, I'm more likely to create the project than if I had to visit the openplans.org site directly.

whit: how bout a firefox plugin for managing your projects?  starting projects is a low traffic activity(a plugin doesn't make my life much easier than doing it at the site).  But if I could say manage team members and roles, especially with a task board....a simple evolution could be a plugin that starts as an information provider and grows the ability to do management(feeds, then api exposure)  (For heavy data input and manipulation, XUL might be a better-feeling experience than plain HTML; at the same time, not that many people actually go down that path, so I think it requires that XUL have a substantial benefit to really justify -- especially to justify the maintenance.  But if it's just for training, maintenance doesn't matter that much. -- ianb).  (I'd support a bit more to be added to the plug-in than just project creation.  I wouldn't want to put too much time there, however, unless the plug-in actually started to get some significant usage, and it was clear that there would be value to adding more functionality. -ra) 

Another possible benefit to creating a FF extension is that quite a number of people do actually search through the FF extensions that exist for fun things to install.  It's possible that someone might stumble upon us when browsing through the FF plugins.

 

Reimplement the OpenPlans product installation as a GenericSetup profile

This is a good task for someone getting started, BUT it would require Plone 2.5.  Upgrading to Plone 2.5, however, is not a novice task, so this one might need to wait for a bit.

Migrating to Plone 2.5

Not a novice task, but a task that novices could be very useful at helping with. They are somewhat related in the fact that both require fixing issues with the way that Product.OpenPlans overrides the default plone and kupu UI.  Involves some more fundamental issues such as CMFMember not being supported(much) by Plone 2.5.   Basically this is a big task with lots of small pieces(qa, bugfixing).   Not always the most fun work, but fairly good for getting the guts on your face. related: exposing changes made in 2.1.3.  Both migrating and exposing some of the new features from 2.1.3 involve undoing/redoing our UI patchs in Products.OpenPlans.

Client-side API consumption

Considering talk of APIs for Listen or other systems, applications that consume those APIs might be of some use.  This would be a good Python introduction, without the bulk of the entire Zope environment all at the start.

Site-ripping tools

New projects may have existing sites, which they might want to move over.  A tool that rips a site and puts it into openplans would be useful there.  This is basically an API of sorts, since I think the upload can be done through WebDAV calls.  There's a lot of usability issues if end-users are allowed to do this, like being able to re-run the import if the site transfer needs to be redone, being able to wipe the import and redo (when it is done wrong), and some controls to help identify "content" and "wrapper" (where wrapper may be dropped).  Advise: use BeautifulSoup for parsing, not HTMLParser, ElementTree, or anything that cares about "proper" markup.

Other export tools

Export tools in general are useful.  E.g., to rip a subscription list from Yahoo Groups, since it's a common tool and it's a relative lame mailing list.  Or archives.  In these cases, the data should be represented in some neutral fashion, and then a separate importer written (then other organizations can get the same benefits from the ripper).

Redirecting tool

If people are moving sites to our software, probably lots of links will be broken or weird.  We should try to keep links working, but it can't always be helped.  There should be some tool to find bad links on the site, and provide redirects (just fixing the links won't fix external links).  And/or as part of the importer, identify all the pages (whether or not they will all be imported), and use that as a set of possible links that will need redirection.  Also 404's from the logs can be used as fodder for potential redirects.

Log analysis tools

Everyone likes to know if they are popular.  There's some open source software available for log analysis, much of which is horribly ugly and useless.  There's a few more recent projects that actually have nice output.  Anyway, identify and integrate something, or write something.  I (Ian) have some old code that might be useful, maybe, if we didn't reuse some other project, in LogAnalyse. (this is huge for projects, since the main reason people do things when they aren't paid is because they know people are watching --  whit)

Small apps

Depending on how we set up applications, it may or may not be feasible to use a small application as a starting point for people.  But there are many possible small applications that could be written.  For example, (snail) mailing list software, with printable labels if at all possible.  Software to create, collect, and summarize petitions.  Leaflet distribution trackers. (voting/polling software)

Rich editing forms

Many kinds of wiki content are constrained in various ways.  Plone generally allows for that, but that doesn't mean the input is actually easy, especially when HTML forms aren't very good at handling the data input (e.g., lots of fields).  As a primarily Javascript task, some typical forms could be extended and improved.  This will probably lead to greater familiarity with ZPT and ZMI, even if not much Zope or Python. (big improvements could be made here using formlib and improving AT -- whit)

WYSIWYG Microformats

Look into getting Kupu to support Microformats in some pluggable fashion.  Maybe add microformats to some of the content already generated on openplans. (+1 this seems like pretty straight forward js work -- whit)

Generalized auto-save

Auto-save can be implemented largely in Javascript, with a small backend component.  (I feel like Anders might have already written a microapp for this, though it isn't listed.) This involves some integration into forms, as well as the small backend piece.

Chat rooms

Chat rooms for online meetings are nice.  Investigate options (it's fairly complicated, and not likely to be implementable in Zope/Plone or even Python/WSGI).  Figure out something to deploy.  Web-based chat is going to be much easier to get casual users to use, and seems like the best implementation strategy.  Or a web frontend to some existing chat system. (AJChat might have some potential for this: would be cool to hook into team security or allow for a variety of protocols: GAIM, IRC, etc  -- whit)

Privacy report

It's possible that privacy will be important for some users of the software.  We should know what privacy guarantees we can give to people, if any.  If we want to support anonymous access, we should outline strategies that users can use.  Confirming anonymity by double-checking Apache logs and elsewhere will help.

Build the DogBowl: creating a reproducible F/OSS Production environment

- irc logging
- trac(code browsing, tickets)
- buildbot
- email notifiers/rss feed for svn
- automated documentation creation/maintenance (and upload to opencore project)
- some sort of user story -> iteration tool(XP management tool?)
- automated project stub creation
- automated deployment
- integration into our current system

Feeds (ubiquitously exposing alternate format in general)

We have tons of info to expose as consumable formats; team membership, projects joined, recent changes to a project, edits to a document.  Soon we will have such things as tagging, rating, and a variety of other stuff.  Exposing formats like JSON, ATOM, RSS, etc is a straightforward task.   Recent changed to rdflib that allow rdflib's query interface to return JSON or XML directly may also aid in this general task. 

 Javascript Clients (and client generators)

These would be analogous to Ning's mashup generators or delicious's js tag widget generator: a component that takes some parameters and spits out a javascript that displays the desired information or interactivity when embedded in a user's location of choice.   Task evolution would run roughly like this:  javascript that does something interesting => a generator that can take useful parameter to alter original js's behavior => interfaces for utilizing generator(web forms, wicked extensions, etc).   This would build on feeds and client apis(a js consumer API to be specific)

Expose Existing Plone Functionality in Useful Way

Based on a conversation with cholmes: This is a catchall for all the little things that we could be using from plone but are not.   Things like feeds and client api are one way to expose this.   Creating UI is another.  I think with some careful inspection(and a ui designer) we could actually line up a series of easy wins.   

MSOffice / PDF / Other Integration

We aren't going to be writely, but this is a big winner(w/ mark and the rest of the windows world).  Plone gives us some hooks for handling this(portal transforms) and python gives us some tools(reportlab, chimera), but there is a gradient of tasks here for creating tools for handling M$/Adobe formats and doing interesting things with them.  Some things that come to mind: PDF generation, PDF slideshow generation, opencoredoc to worddoc transform and back.   Things like S5 integration could fall here too: cross browser compatible presentation can be sort of sexy (see this mochikit presentation with embedded js interaction).   

Mapping Integration

Mike will probably have created a lot of good doc with what he's done this summer; this could provide a nice starting point for a couple people interested in mapping.   The middling steps in between gis setup and full site site integration could include things mentioned before: consumer apis and javascript script client.  Integration of ways to connect content and annotate maps dynamically could be a killer app for us as could user created layers.  The former is the problem I understand better, the latter might be beyond the scope of anything anyone could start on now.

R & D

Poking around doesn't require much specific knowledge and sometime fresh mind find fresh approaches(and at worst do no harm and bring back information).  There is a  wealth of code in the zope3 repository, tiks repository, codespeak et al. that rob, ian and I simply haven't had time to try.   There are also many accessible potential clients directly involved with TOPP that new hires should spend some time gathering requirements from.   (In my heart of heart, this is maybe how thing should work.  Ian, Rob and I can do a great job of clearing the path for these guys until they can clear it for themselves, but we should capitalize on the ability to have them in a client feedback loop involving actual facetime -- whit)  (Chris mentioned that every developer might have a pet organization, so to speak, that they'd be in contact with; that's something we can do in our respective locations just like they might do in NYC. -- ianb)

Code Maid

Rob and I aren't too bad about leaving horrible undocumented messes, but there is some stuff that could stand to have more documentation, more tests, etc.  This is the classic newb initiation sort of stuff: apprentice by documenting, testing and refactoring the stupid.  A little of this might be good.   some possible housekeeping tasks:  cleaning up Products.OpenPlans to use pythonproducts, dividing out the UI into own package. 

Feed to email gateways

Feeds are cool.  But few people in our target audience use feed readers.  Ways of managing feeds that go into email would be useful.  Documentation about feed readers (e.g., links to notable, quality readers) would also be useful.  I'm not sure if we want to get the developers involved in this kind of documentation?  Ideally such general content would have a landing place more general than just openplans... (wikipedia?  Someplace else?  A well-indexed blog?)

Setting up buildbot

When there's lots of pieces working together, automated tests run on the combinations would be great.  Hence buildbot.

More functional and integration tests

Given buildbot, slow tests that combine functionality from multiple sources are okay -- they just run slowly in the background.  So, more tests that cover the specific combinations of software we are using (probably in the form of functional tests) would be excellent.  In addition to a "dev" site, this probably implies a "dev-testing" site that is regularly cleared to a known state for testing.

Automated Selenium testing

An option for functional testing -- especially of Javascript -- is Selenium.  But it's hard to automate.  But it's not impossible to automate.  Automating it would be cool.  Or, trying and failing and deciding that we just can't reasonably automate browser testing, which is a very possible outcome.

Operational testing

Operational testing is basically "are you alive?" tests, typically run directly on the production site.  I think in its best form, it opens a URL specially designed to be tested this way (that might check database connections, or other simple integrity checks).  Thus the application is cooperative when its being tested, and the tests are not functional (they should be able to hit the live site every couple minutes without cruft accumulating, for instance).  The system notifies people when something is down.  It should be easy to add services to this.

Supervisor

I'm not sure what we're using in the deployment, but I think Supervisor is kind of spiffy.  If we are deploying more than just One Big Zope Process, then Supervisor has some useful features for managing multiple processes and keeping them up.  One feature supervisor2 could use is a connection to operational testing -- to automatically restart a process when it is no longer available (using supervisor2's xmlrpc interface).

UI Makeover

There are a number of areas of our site that are already in production, but for which the UI leaves a fair bit to be desired.  The team member management and mailing list management interfaces, and the project roster in particular come to mind.  It would be great for someone(s?) to take a look at these screens and spend some time really thinking about how they can be improved.  Initial deliverable would be a proposal for a new interface, ideally with a mock-up of some sort.  Ultimate deliverable would be implementation of an interface that had been given the thumbs up from the larger group.

Upgrade some underlying dependency product in deployment

Our development and deployment setup is not extremely complex, but it does require some familiarity.  It would be very educational for someone to be tasked with upgrading the version of one of our underlying dependency products.  This would involve first testing the product locally, by running all automated tests, running any functional tests (generating them if they don't yet exist), and then deploying to the development environment and the production environment, in turn.

Member Relationship and Dashboard

We're currently lacking rich ways for members to interact with the site, such as setting favorites, monitoring documents for changes, seeing recent changes, etc.  We should add functionality to support these, and then provide members with a dashboard interface that presents all of the relevant information.  There's a lot to learn through this process about making catalog queries and putting together relatively straightforward dynamic pages.  There's a great opportunity for someone interested in interface design and implementation.

Some Google Calendar Integration Thingy

Maybe we don't want to do calendaring ourselves.  (I don't think we do, it's hard -- ianb).  Anyway,  we could try some sort of Google Calendar integration.  This would build familiarity with several APIs, both in Python and over the web.  I'm not sure what the actual task would be though; ultimately we'd probably be accessing the calendar in several ways for several purposes, but we need to start with something.  Show a summary according to some query?