r35 - 02 Aug 2006 - 16:12:54 - HeikkiToivonenYou are here: OSAF >  Projects Web  >  DevelopmentHome > SelfAssignProjectProcess

Self Assigned Projects Program

Objectives

As OSAF staff members, we are very close to the core of our products. At the same time, we are less free to experiment with whatever ideas come to our mind: we have a roadmap to follow, products to deliver to users, bugs to fix, work assigned by our management, commitments to fulfill, etc... Sometimes we wish we could just be a volunteer and implement that very cool idea we had yesterday but have no chance to fit under the current plan, or just try out something new to see "if it works".

The main objectives of the "Self Assigned Projects" program is precisely to allow OSAF staff members to explore ideas that are not necessarily part of the short term product map but are potentially important. It will be our way to "scratch an itch". This could take multiple forms:

  • Explore unconventional ideas
  • Try new technologies and learn from them
  • Understand our products ecosystem better through experimentation
  • Extend the use cases of OSAF products
  • Implement vertical ideas, specific to a narrow user population (e.g. K-12 schools)
  • Implement ideas and features ahead of schedule
  • Have some fun coding...

The hope is that some of these unconventional ventures will make it up in the products or even open up new venues for development.

Since it's still an experimental program, we decided to give it an initial trial period of 3 months. After that time (by mid June), we will assess what worked and what didn't and make adjustments.

Framework

Those projects can't however be anything, they need to have some relation to OSAF objectives and are not just "free time". Here's an outline of the framework for such projects:
  • Projects should align with OSAF's charter.
  • Projects can take risks and are not expected to succeed or end up as shipping code
  • Projects can experiment with features either not on the (scooby, chandler, or cosmo) product roadmap or in a different timeframe from the product roadmap
  • Projects can be associated with any of the OSAF products (scooby, chandler, cosmo), not necessarily the one a contributor regularly works on
  • Projects can be associated with 3rd party projects (twisted, wx, jackrabbit) that have some relationship to OSAF goals

Also, in the spirit of "free" as in "freedom", note that:

  • The program is elective : staff members are free to elect out for a period of time if they don't feel the need to take over such a project. There is no mandatory participation to the program.
  • The program is open to any OSAF staff member : it is not limited to developers, i.e. QA engineers, build engineers, managers, designers, etc... can participate
  • The program is part of the work load : participants will reserve 20% of their regular work schedule (i.e. 1 day a week) to work on the project and that time is taken into account by their managers as part of the participant workload

Process

Even if those projects are by nature highly experimental and might fail, this doesn't mean we're not accountable for the time spent on them. At the very least, we should learn something from them and it's important to share this with the rest of the team. Here's an outline of how the process will work for any project:
  • Individuals propose projects to their manager for approval (add it to the table in the "Current anc Completed Projects" here under)
  • The project must contain a brief description and a timetable for intermediate steps (if any) and when the project is expected to be completed
  • Individuals will devote 20% of their weekly time (typically 1 day) to the project. Time can't be cumulated from one week to the next. The exact time plan should be agreed upon with your manager.
  • Individuals maintain a Wiki page for their project (must contain the here above mentioned project description and timetable)
  • At the end of the project timetable, individuals will present at staff meetings, on IRC or other venues the result of their project and what they learned in the process
  • If applicable, projects can then be submitted as "patches" to the product and go through the regular OSAF approval process for external contribution on the dev list

Current and Completed Projects

How to use this table:

  • Check the other projects so to make sure that there's not a similar project in progress. If there is, please contact the owner and propose your help or choose another project.
  • Add your project in it
  • Create and link a Wiki page for your project right in there
  • Update the status when appropriate. Only 3 choices:
    • Under review : when the project plan is being shaped up but it hasn't been approved by your manager yet
    • In Progress : as long as you're working on it
    • Done : when it's completed. Keep it in the table so that others know about it and can consult the result.

Project Owner Start Date Completion Date Status
TurboChandler - webframework exploration with the repository on the backend AlecFlett 2006/03/06   In Progress
HCalendarParcel - Subscribing to events stored on a regular XHTML page using the hCalendar microformat PhilippeBossut 2006/03/10   Under review
MeTooCrypto - Release M2Crypto 0.16. The M2Crypto homepage has the roadmap, link to bugs to be fixed etc. HeikkiToivonen 2006/03/14 2006/07/05 Done
Python 2.5 - get various enhancements into Python 2.5, especially ones relevant to Chandler PhillipEby 2006/03/24   In Progress
GooglePersonalProject - widget for viewing Chandler mail within Google's personal page JedBurgess 2006/03/24   Under review
CosmicSynk - iSync conduit for syncing calendar data in Cosmo to your iSync devices (including iCal) BobbyRullo 2006/4/7   In Progress
ChandlerSyncServices - a parcel that registers Chandler for syncing Calendar data with Apple’s SyncServices (iSync) API. GrantBaillie 2006/04/13   In Progress
I'd like to work on some bugs, which don't have high enough priority to get done any time soon, but will simplify writing Parcels or simplify Chandler's architecture. JohnAnderson 18 April 2006 I've made a fair amount of progress and there is no completion date In Progress
Scoophy?. - Create a PHP backend that will allow development work on Scooby JS code without Java MatthewEernisse 2006/04/27   In Progress
Subzilla - command line tool to work with Subversion and Bugzilla. HTTP SVN URL: http://svn.osafoundation.org/sandbox/jeffrey/subzilla/ JeffreyHarris 2006/5/11 2006/5/15 Done
PyObjC/PyGame - experimental UI using PyObjC and/or PyGame, PySDL, PyOpenGL ReidEllis 2006/6/23   Under review

List of Example Projects

This is a non exhaustive list of potential projects, very Chandler centric so far. This list is meant to be inspirational, not limitative. Developers are encouraged to propose their own personal project in relation or not with one of the project listed here under. Some projects were gathered through discussions with developers so you may recognize some of them here :
  • Improve scripting (based on Donn's CPIA Script) to make it easier for users to script Chandler
  • Write a XUL prototype
  • Integrate Gecko for HTML rendering, NVU for HTML editing
  • Host a browsing window in Chandler (using WebKit or IE ActiveX control or ??), get Chandler to manage bookmarks
  • Allow HTML pages (or clip of HTML pages) to be stored and displayed in Chandler
  • Create a Kind for files and index them in Chandler, read file metadata and store them as attributes in Chandler
  • Chandler (or may be just access to the repository) as an OpenOffice plug-in
  • Scooby as a Firefox plug-in
  • P2P : do a P2P Chandler thing...
  • Multiple windows in Chandler, something like a block browser (first step toward visually editing CPIA blocks)
  • Alternative Views of data : graphs, projections, MindMap (to create and link tasks), Pert, Gantt
  • Implement multivariate analysis tools for search and data exploration
  • Analytics - Set of stat tools for Chandler
  • Get Chandler to analyze and learn from the user behaviors and evolve accordingly: 1. pattern behavior 2. extraction of predictive behaviors 3. test of prediction (evolve them using some genetic algorithm) 4. implement auto behavior
  • Natural Language Parsing : extract date, contact, etc... from emails and allow creation of items in Chandler from them
  • Parcels for microformats (support hCalendar for instance)
  • Various parcels (e.g. stock viewer, see a longer list in this Question of the Week section)
  • Improve 3rd party libraries Chandler uses (OpenSSL, M2Crypto, ICU, PyICU?, ...)
  • Improve infrastructure tools (Tinderbox2, Bonsai, LXR, viewcvs, websvn, ...)
  • Incorporate hCalendar into Scooby calendar views
  • Add some task management GUI to Scooby
  • Cosmo/Chandler/Scooby and Exchange interoperability (pull calendars from Exchange Journal.WebDAV?)
  • Create a portal plugin for Scooby (UPortal?)
  • Add searching to Scooby
  • Work on Scooby internationalization or accessibility
  • Work on the wiki - ie: help reorganize the information, rewriting stuff, getting rid of out of date content
  • Allocating time in usability studies and collecting data
  • Design work to support 20% developer projects
  • Market research on other PIM products, AJAX calendars
  • Writing a paper on some interesting aspect of design... not directly related to Chandler features
  • Have the PPD team collaborate to write a parcel
  • Get Chandler to build on some "not officially supported" Linux distro
  • Localize Chandler in a new language

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r35 < r34 < r33 < r32 < r31 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.