• Organization Application
• Why is your group applying to participate? What do you hope to gain by participating?
• What criteria do you use to select the members of your group? Please be as specific as possible.
• Has your group participated previously? If so, please summarize your involvement and any past successes and failures.
• If your group has not previously participated, have you applied in the past? If so, for what sort of participation?
• What is your plan for dealing with disappearing contributors?
• What is your plan for dealing with disappearing members?
• What steps will you take to encourage contributors to interact with your community before, during, and after the program?
• What will you do to ensure that your accepted contributors stick with the project after the program concludes?
• Developers
• Ideas

Organization Application

Why is your group applying to participate? What do you hope to gain by participating?

We hope to end the summer with new experienced developers that will continue to be interested in our project. We are always searching for new points of view and fresh ideas for Tryton.

What criteria do you use to select the members of your group? Please be as specific as possible.

We select members that have a good knowledge of Tryton based on their contributions. Contributions can vary from writing or translating documentation to contributing code through patches or commits. Our mentors have been chosen based on their code contributions.

Has your group participated previously? If so, please summarize your involvement and any past successes and failures.

No.

If your group has not previously participated, have you applied in the past? If so, for what sort of participation?

-

What is your plan for dealing with disappearing contributors?

If we can't get in touch with a contributor without any sort of notice we will try to reach them via all known forms of communication (email, irc, jabber etc.). If the contributor does not respond to any of our attempts to contact them for 2 weeks we will send a final warning. If the contributor still does not respond we will consider that to be a lack of commitment and it will be noted in their evaluation. We will inform contributors about this policy before we start.

What is your plan for dealing with disappearing members?

We have backup members that will follow the progress of the contributors. Therefore if a member disappears there will be other members that are ready to take over. Although, in a way similar to above, we will try to reach the member with multiple forms of communications to prevent any sort of unnecessary transition. If that member does disappear without notice they will be removed from our group. Our members will be aware of this policy before they choose to participate.

What steps will you take to encourage contributors to interact with your community before, during, and after the program?

We will encourage contributors to use the same communication tools as the community (irc and mailing list) before, during and after the program. We will make an announcement on the mailing list introducing the contributors to the community. We will treat contributors as we would any new community members.

What will you do to ensure that your accepted contributors stick with the project after the program concludes?

Overall hopefully they have such a good experience that they will want to continue to participate in the project. We will suggest new ideas so that they can continue to contribute. Additionally we will propose that they become a member of the project.

Developers

Ideas

Post your ideas for students during Google's Summer of Code 2009 here. See the FAQ entry on the ideas list for further details.

• Add CardDAV support.

CardDAV is a protocol that extends the WebDAV protocol to allow the exchange of contact lists in the standard vCard format. Tryton internally manages contact lists with the party module. Therefore to add CardDAV support an interface to the party module would need to be implemented in the CardDAV protocol. Tryton already uses WebDAV via the PyWebDAV library. End users would benefit from CardDAV support by being be able to easily exchange contact lists with third party contact management applications, such as Kontact, Evolution, Thunderbird or Outlook. Knowledge of Python, XML and http is required.

• Add CalDAV support.

CalDAV is a protocol that extends the WebDAV protocol to allow the exchange of calendar events. Tryton currently has no internal mechanism for storing calendar events. Therefore to add CalDAV support both an internal model for calendar events and an interface using the CalDAV protocol would need to be implemented. Tryton already uses WebDAV via the PyWebDAV library. End users would benefit from CalDAV support by being be able to easily exchange calendar events and scheduling with third party calendar management applications, such as iCal, Sunbird or Google Calendar. Knowledge of Python, XML and http is required.

• Add historical time-line in the PyGTK client.

The Tryton server has the capability to store versions of records as changes are made and to retrieve those past versions. The Tryton client currently does not have the capability to access this information. To add the historical timeline a view would need to be created that allowed a user of the client to browse past versions of a record based on a date and time and optionally select an old version to write over the current version. Knowledge of Python and PyGTK is required.

• Implement a web client using a JS framework: qooxdoo or Ext JS.

Both qooxdoo and ExtJS provide an extensive set of web based GUI widgets and events. Currently the Tryton server can only be accessed using our PyGTK client. The foundation for a web client could be implemented using one of the two javascript frameworks mentioned above. Additionally a new interface, possibly using JSON-RPC, will be needed on the server. Knowledge of Javascript and HTML is required to implement the client. Knowledge of Python would be helpful to implement the server side interface but that is optional.

• Add backends:
• SQLite

The Tryton server currently only has support for Postgresql as a backend. Implementing a new backend for SQLite would be very useful for development and/or embedding. A good understanding of SQL is required. An understanding of python is optional.

• Oracle

The Tryton server currently only has support for Postgresql as a backend. Implementing a new backend for Oracle would allow an alternative database. A good understanding of SQL is required. An understanding of python is optional.

• Add memcached support.

Memcached is a high performance system for storing key/value pairs in memory. Memcached support could be added by allowing the server to create cache entries for data read by a client as well as invalidate entries when data is written by a client. Such an implementation would improve performance for end users of the client. A good understanding of python and database transactions is required.

• Create a XPDL parser to load workflow.

The Tryton server loads workflow with a specific XML format. It would be great to allow the server to parse XPDL files to load the workflow in the database. Knowledge of XML and Python is required.

• Add ability to customize report templates via WebDAV.

The Tryton server exposes generated reports through the WebDAV interface. Tryton uses ODF files as templates for those reports. To make generating new reports easier an interface could be implemented on top of WebDAV to allow those template files to be customized. Knowledge of Python is required. Knowledge of WebDAV is optional.

• Add ability to translate documentation using Sphinx.

Tryton uses Sphinx to generate our documentation from RST files. To quickly translate the documentation a plugin to Sphinx could be created that would use gettext to translate the RST files. Knowledge of Python is required.

• Implement a view editor in the PyGTK client.

Tryton uses XML to define forms. A view could be created to allow the user in the client to move fields by clicking and draging to generate a custom XML file. Knowledge of Python, PyGTK and XML is required.

• Implement a model editor that allows fields to be added from the client.

Tryton stores a description of each Model and its fields in the database. A view could be created that would allow a user in the client to add fields or even Models to the database on the fly. Such a view would need to update the instances in the database as well as update the description of the models and fields stored in the database. Knowledge of Python and SQL is required.

• Add full text search on records.

Full text search allows large amounts of text to be efficiently tokenized, indexed and searched. Full text search would be beneficial to users by giving them a powerful way to search records in Tryton. Knowledge of Python and SQL is required.

• Add domain to primitive field types: Char, Date, Datetime, Float, Integer, Decimal.

Tryton has the capability to restrict the domain of any many2one, one2many or many2many field. This capability could be added to primitive fields by using regexp for Char fields, date range for Date fields, etc. This would improve data integrity. Knowledge of Python is required.

• Add zeroconf support.

Zeroconf is a standard created by Apple that makes the configuration of networking simple. Some example implementations are avahi and Bonjour. Adding zeroconf support to the Tryton PyGTK client would allow it to automatically discover servers. This would simplify the connection configuration. Knowledge of Python and PyGTK is required.

• Add Gantt chart in the PyGTK client.

The PyGTK client of Tryton already has bar chart, line chart and pie chart using Pycairo. I will be great to have also Gantt chart to display project schedule. Such implementation would need to extend the xml definition of graph views. Optionally it could be great to make an external library with all the graphs rendering engine. Knowledge of Python, PyGTK and Pycairo is required. Knowledge of XML is optional.