Google Summer of Code 2013: welcome and ideas

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

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.

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.

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.

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:

1. From Evergreen's GSoC 2011: Joseph Lewis' "Bring Sanity to the Evergreen Configuration Interface"
2. From Python's GSoC 2010: Aaron Meurer's "SymPy: Improving the Symbolic Integrator"

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

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.

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

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:

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

• 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