User Tools

Site Tools


dev:summer_of_coding_ideas

Google Summer of Code 2013: welcome and ideas

Notes: Please review and work with the template listed on our GSOC project page for Evergreen.

Welcome

If you've found this page, you might be interested in making a valuable contribution of your development time to the Evergreen project. The primary goal for our mentors this summer is to enable students to successfully contribute working code to our project and gain experience with the tools and social norms of open source development. We'll expect you to use the same communication channels, code repositories, and bug tracking systems as the rest of the developers, while we help you commit code early and often in your efforts - and we, in turn, will learn from your insight as a newcomer to our community. We want the experience to be positive for each student, each mentor, and for the project as a whole.

In solidarity with the Software Freedom Conservancy's participation in the GNOME Foundation's Outreach Program for Women, we particularly invite and encourage eligible women to apply.

Expectations

We expect students to communicate their progress publicly with the project, either via blog posts or posts to the mailing list, on a regular basis: weekly, at a minimum. Much more communication should also occur between the student and the development team on a daily basis through the normal modes of IRC, bug tracker, and mailing list.

Application requirement

As part of their application for the Google Summer of Code, we expect any student applicants to submit an SSH key to the git administrators and gain working access to the Evergreen git repository. One can follow instructions on the dev:git page, which contains other useful information on use of git for the project. Additionally, students are required to submit a patch or point to a branch that addresses some problem or adds some small enhancement. Bite-size bugs and new unit tests are good candidates to tackle.

Application guidelines

To increase your chances of being selected and having a successful summer of code, please read the GSoC Student Guide, including the section on Writing a Proposal. A good application will have the following properties:

  1. It will describe in some detail what features you hope to implement and how you will implement them
  2. If it is based on one of the project ideas below, it will provide additional detail – it's not really enough just to quote the idea.
  3. It will include a timeline listing a few milestones for your project.

We strongly encourage all applicants to publicly discuss their proposals on the development mailing list for Evergreen.

Here are examples of what we would consider to be a good application:

REMEMBER: Applicants must submit a patch or pull request that makes a small improvement to Evergreen

Project ideas

The following project ideas are the result of brainstorming within the Evergreen development community. They are not the only project ideas that would be valuable to the Evergreen project - hopefully they serve as a starting point for your own initiative.

Testing: units, stress, regression, UI

  • Problem: Evergreen and OpenSRF have a testing problem. It isn't failing tests; it just doesn't have many tests to pass. As the functionality and configurability of Evergreen has grown significantly over time, simply setting up a clean environment with reasonable sample data in order to test a small patch requires a large investment of time. Then, testing a reasonable set of combinations strains the bounds of sanity of mere mortals. Luckily, computers don't have to worry about sanity (or mortality), and they are very good at doing repetitive tasks very quickly and looking for anomalies in the results. Your job, should you accept it, is to harness the power of computing to build out Evergreen's fledgling test suites into something that will make bugs and brittle code tremble with fear - and make it easier for other developers to QA their own and each other's code. You can build upon the existing infrastructure Evergreen already has in place:
    • A Buildbot configuration for a continuous integration environment
    • The constrictor custom stress-testing framework
    • Various unit tests written in Perl, Python, JavaScript, and C
  • Required skills: A passion for quality. Basic knowledge of testing in one or more of Perl, Python, JavaScript, and C.
  • Level of difficulty: Variable, depending on what you put into it!
  • Category: Infrastructure/Automation
  • Bonus points: PostgreSQL testing via pgTAP, browser testing with Selenium or Windmill.
  • Mentor: TBD

Modernize Evergreen's Web interface

  • Problem: Evergreen was an early adopter of the Dojo Toolkit, as its JavaScript widgets provided a powerful, approachable Web-based user interface. However, we are stuck using the 1.3 branch of Dojo (released in March, 2009) due to our dependence on some deprecated features such as the original Dojo Grid. Recent versions of Dojo offer more functionality, improved usability, better browser support, and greatly enhanced accessibility. Your job is to overcome the forces of inertia and enable Evergreen to adopt Dojo 1.8.
  • Required skills: JavaScript
  • Level of difficulty: Medium
  • Category: Low-Hanging Fruit
  • Bonus points: Use Dojo test harnesses, or some other JavaScript testing framework, to build a test bed that ensures the quality of your own work and prevents those who follow you from desecrating your heavenly creation with regressions.
  • Mentors: TBD

Mobilizing the Catalog

  • Problem: Evergreen's web catalog is not well optimized for mobile devices. There are still hard-coded styles lying around in the code, table layouts, and other visual elements that should be changed or updated to work better when viewed on different platforms. While applying various concepts of responsive web design, let's improve the web catalog to be more friendly on mobile devices.
  • Required skills: Template Toolkit, HTML, JavaScript, Perl
  • Level of difficulty: Low
  • Category: Fun/Peripheral
  • Mentors: TBD

Enable metadata formats other than MARC21 to be first class citizens

  • Problem: While Evergreen is built on an advanced platform, much of its database schema, search indexing and results display, and tooling assumes that the loved-by-libraries-but-oh-so-limited MARC21 is the sole format in which metadata will be stored and maintained. To support a broader base of knowledge-based institutions, many of which use more modern metadata formats, Evergreen needs to be taught how to ingest, index, display, and edit other metadata formats without requiring them to be converted to MARC21.
  • Required skills: SQL, XML, XSLT
  • Level of difficulty: Medium to hard
  • Category: Risky/Exploratory
  • Mentors: TBD

Offer management and integration of full-text search of objects within Evergreen

  • Problem: Evergreen is currently limited to searching metadata, but our knowledge institutions are increasingly moving towards offering either born digital objects (ebooks, electronic journals, theses and dissertations) or digitized works. Consequently, a frequently asked question is whether there is a way to search full-text objects along with just metadata, and the current answer is “no”. One way to change this answer is to tightly integrate Evergreen with an existing digital repository such as DSpace or Fedora; alternately, one could add full-text digital object support directly to Evergreen.
  • Required skills: Full-text search (Solr, Sphinx, …)
  • Level of difficulty: High
  • Category: Risky/Exploratory
  • Mentors: TBD

Overhaul internationalization support in Evergreen

  • Problem: Internationalization (i18n) support in the public interface and most of the staff client was added several years ago, but while an effort was made to standardize on GNU gettext as an intermediate format, the effort was somewhat rudimentary and many new interfaces have subsequently been added that lack i18n support. The adoption of Template::Toolkit for new web interfaces offers many i18n advantages over the DTD and JavaScript-based i18n used in legacy web interfaces. Given the increasing adoption of Evergreen outside of North America, the time is right to revisit some of the initial i18n approaches and deliver a consistent approach to i18n throughout the application, with an eye towards the addition of right-to-left support for bidirectional languages; locale-sensitive currency, time, and date support; and use of a shared system across timezones.
  • Required skills: JavaScript, Perl, XML
  • Level of difficulty: Medium
  • Category: Core Development
  • Mentors: TBD

Build easier configuration interface for indexing definitions

  • Problem: Currently Evergreen requires the use of XSLT and XPath to configure the mapping of metadata field to search indexes. This is not the friendliest of interfaces for many librarians to use. A interface that allows the expression of index definitions in terms more familiar to librarians (e.g., MARC tags, headings, and named metadata fields) would make it much easier for librarians to customize their use of Evergreen.
  • Required skills: JavaScript, XML, XSLT, Perl
  • Level of difficulty: Medium
  • Category: Core Development
  • Mentors: TBD

Build a customizable dashboard to show library usage and server health

  • Problem: Up-to-date information about the use of the library and the health of its servers is available in reports and logfiles, but few stakeholders have the access, expertise, and initiative to check those sources. A dashboard framework with useful starter components would make this information ambiently available with just a glance. It would be useful to be able to show the current number of loaned/overdue items; current total overdues owed; average number of renewals per circ modifier; number of circulations in/out per n minutes. For internal use, it would also be useful to show server load, free memory and disk space, etc. as recorded by nagios, MRTG, et al. http://library.brown.edu/dashboard/info/ has some great ideas.
  • Required skills:
  • Level of difficulty:
  • Category: Fun/Peripheral
  • Mentors: TBD

Contacting us

While documents have their place, there's generally no substitute for talking to existing community members - whether you're working through a tough piece of code, or putting together a patch, or just getting your development environment up and running - and you'll find that our development community tries to support newcomers like you. If you have questions, the #evergreen IRC channel on Freenode is the best place to start. You can also use the Evergreen development mailing list (open-ils-dev) if you prefer.

If you have questions about the following project ideas or want to kick around some new ideas that you have, you can contact the project mentors as follows:

GSoC 2013 Administrators

  • Benjamin Shum - IRC nick: bshum, email: bshum@biblio.org
  • Galen Charlton - IRC nick: gmcharlt, email: gmc@esilibrary.com

GSoC 2013 Available Mentors

  • Benjamin Shum - IRC nick: bshum, email: bshum@biblio.org
  • Jason Stephenson - IRC nick: Dyrcona, email: jstephenson@mvlc.org
  • Dan Wells - IRC nick: dbwells, email: dbw2@calvin.edu
dev/summer_of_coding_ideas.txt · Last modified: 2013/05/01 11:39 by dbs

© 2008-2014 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a member of Software Freedom Conservancy.