GSoC 2013 Project Ideas

GSoC Logo

Welcome to the GSoC 2013 Ideas Page

phpBB was a mentor organisation in Google Summer of Code 2013. On this page you can find ideas for potential projects that were listed in 2013.

Make sure to also read the GSoC Instructions.

Content

Core Ideas

Website

Extensions Ideas


Core Ideas

phpBB 3.1

Summary

Under the guidance of the 3.1 Release Manager, this project will involve getting phpBB 3.1 to a releasable state. The primary tasks of this project are:

  1. Fixing bugs marked as Blocker and Major and affecting phpBB 3.1. There are quite a few of these already and more are expected to be filed as phpBB 3.1 moves through Alpha and Beta stages. Generally speaking, all bug fixes will require test coverage, either through phpBB's own test framework or through Wolis. There are some patches/pull requests for some of the issues which either need to be finished or need to have tests written. The student will be responsible for investigating the cause of the bugs, creating failing tests, fixing the bugs and making tests pass as necessary. It is expected that all Blocker priority bugs are fixed promptly, with as many Major priority bugs fixed as remaining time permits.

  2. Implementing features that are deemed required for phpBB 3.1. These are expected to come from community feedback after Alpha and Beta are released. If a new feature already implemented in phpBB 3.1 is missing some functionality that significantly affects said feature's usability, we will consider implementing this functionality for phpBB 3.1.

Expected results

All outstanding phpBB 3.1 blocker bugs fixed rapidly throughout GSoC program. Some number of phpBB 3.1 major bugs fixed. Regression tests written for all fixed bugs.

Knowledge Prerequisite

A bit of everything with particular emphasis on testing (phpunit and phpBB functional tests or Wolis).

It is expected that the student will be doing most of the work in debugging reported issues, fixing them and writing tests for the fixes. Familiarity with phpBB as a user or board administrator will be very helpful. Being able to debug code is a must. Successful candidate will have submitted at least one pull request fixing a major or blocker bug in phpBB with unit or functional test coverage and will have authored at least one unit and at least one functional test. Ability to write Wolis tests is a big plus (because phpBB's own tests are much more limited in scope than Wolis' ones). Ideal candidate will have written at least one Wolis test.

Additional Notes

This project will not have a predefined schedule. Depending on how quickly the blocker bugs are fixed and how much community testing ends up happening, phpBB 3.1 may go through several Alpha releases during the summer with a Beta release possible by the end of the summer. There are more open bugs than can be fixed in the GSoC timeline, therefore it is expected that the student will fix Blocker priority bugs as soon as they are filed and spend the remaining time fixing Major priority bugs and developing regression tests.

Available mentors

  • Oleg Pudeyev

Social Sharing

Summary

Create an extensible system supporting via an object oriented plugin system any number of 3rd party services to share content to. There may be different options, sharing a link to a topic or a particular post or maybe even a forum, or sharing complete posts or extracts of posts.

Expected results

  • User interface changes for sharing buttons/dialogs/etc.
  • administration control panel page with options on configuring the various services which might require API keys to work
  • extensible interface that allows extensions to supply further sharing backends.

Knowledge Prerequisite

  • Required: Object-oriented PHP and Javascript
  • Useful: familiarity with social sharing APIs (Facebook/Twitter)

Available mentors

  • Nils Adermann

Improved E-mail Options

Summary

The current emailing options in phpBB are somewhat lacking. Mass-emails can only be sent to specific users or a single specified group (not multiple groups and users). Administrators cannot choose specific or all forums to trigger notifications for all users. Subscriptions are currently limited to specific forums; there is no way to subscribe to all forums with one click). This is a very commonly requested feature for small community forums where users do not regularly check for updates.

Expected results

  • Merge gap between forums and something like Google Groups
  • Improve email notifications system for users as well as the mass-emailing system for administrators
  • Maintain "good practices" philosophy and ability for users to opt out of receiving notifications (even if enabled by default by the admin)

Knowledge Prerequisite

PHP, familiarity with "good email practices"

Available Mentors

  • Nils Adermann
  • Marc Alexander

Command Line Interface

Summary

A number of maintenance tasks, such as updating a forum could be made more accessible to system administrators by making them run on a console. Some tasks, for example phpBB's cron can already be run on the console and it would be great to unify these into a single phpBB CLI utility. Further functionality could include installing and updating phpBB, the management of extensions or modifying phpBB configuration settings. The command line interface should be built using the Symfony Console component. Please keep in mind that you should not duplicate code. So when building a command line interface for something that already has a web interface you will be expected to refactor the web interface into a backend that can be shared by the web frontend and the command line utility. When planning command line features you need to consider how much time this step will consume.

Expected results

A phpBB command line utility making a number of administrative and maintenance available without a web browser. Clear separation of functionality into reusable APIs shared by web based and command line based tools, and a command line frontend.

Knowledge Prerequisite

Object-oriented PHP required, familiarity with command line utilities useful but not mandatory.

Further information

RFC on Area51

Available Mentors

  • Nils Adermann
  • Andreas Fischer

Session Backend Abstraction

Summary

High traffic websites can already make use of fast in-memory stores (such as memcached or Redis) for improved caching. However volatile session data is still handled by the (relational) database, occasionally causing load problems. First very complete test coverage of current session code should be achieved to be able to guarantee the continued correct functionality of the session mechanism, which is of critical importance to running a board. The session code should then be refactored to provide an abstraction of the storage mechanism used, to allow for faster backends to be implemented.

Expected results

A properly designed storage interface for session data and working backend implementations for relational databases and memcached. A Redis implementation would be useful but is optional.

Knowledge Prerequisite

Object-oriented PHP required, familiarity with key-value stores useful but not mandatory.

Further Information

Available Mentors

  • Nils Adermann
  • Andreas Fischer

Wolis

Summary

Wolis is an external test suite for phpBB. It serves a similar function to phpBB's functional tests but goes about achieving this task in a markedly different way. Unlike phpBB which is primarily implemented in PHP, Wolis is implemented 3/4 in Python and 1/4 in JavaScript.

There are several possible subprojects within this project:

  • Expanding Wolis' test coverage of phpBB. This means writing new tests using existing tests as a guide. This is the most straightforward of the subprojects, requiring pretty basic understanding of Python and JavaScript as well as phpBB.
  • Implementing new tests. The difference from the previous subproject is that there are no existing tests that are similar. One example of a new test would be solving captchas during registration. Another would be testing that emails are correctly generated and submitted. This subproject will require more extensive Python knowledge.
  • Porting JavaScript tests to Capybara. Rather than using CasperJS, frontend tests can be rewritten to use Capybara, ideally with PhantomJS as the backend. Part of this subproject is getting Capybara working with PhantomJS. This subproject also involves writing the test framework/runner code to invoke Capybara tests from Python test runner. Reasonable Python knowledge is required as well as significant Ruby knowledge.
  • Somewhat alternatively to the previous subproject, the entire Wolis project may be rewritten to use Capybara. There are benefits in using a single language for writing tests. This subproject will require extensive Ruby knowledge and significant Python knowledge. You will be rewriting test runner and framework as well as tests themselves.

Available Mentors

  • Oleg Pudeyev

Auth Plugin Refactoring

Summary

This is a subset of 2012 GSoC "Auth Plugin Refactoring & User Integration" project. There is a fair amount of code that was written in 2012 that can be built upon. It consists of a new interface as well as a proof of concept integration with Zend's OpenID libraries, but changes may be necessary.

This particular project concentrates on refactoring of existing authentication plugins/backends into an object oriented, modern PHP structure. The expected result is the same functionality that already exists in phpBB implemented in a modular and extensible manner.

Implementation or integration of additional authentication mechanisms such as OAuth can be done under the umbrella of this project with the goal of demonstrating modularity and flexibility of new auth plugin architecture.

Further Information

Available Mentors

  • Oleg Pudeyev
  • Nils Adermann

OAuth

Summary

This is a follow-up project to "Auth Plugin Refactoring". If it is attempted, it should likely be done by the same person.

The goal of this project is to implement OAuth to the extent where it is usable using the architecture developed in auth plugin refactoring project. This project concentrates on implementing OAuth functionality. Naturally, some changes to auth plugin achitecture and/or other auth plugins may be required, which is fine.

To avoid repeating work that was already done, existing code from 2012 attempt at OAuth should be used to the extent it is possible and practical.

Available mentors

  • Oleg Pudeyev
  • Nils Adermann

Website Ideas

Documentation & KB System

Brief Explanation

We are currently consolidating our old Knowledge Base, Flash Tutorials Section and Documentation into a new web application. This will be released to the wider community as an add-on to the phpBB system. Much of the groundwork has been completely, however there is plenty left to do before the system is ready for production. Primarily, much of the UI could use improvement. Please contact Yuriy Rusko (Marshalrusty) with any questions.

Expected Results

The flash (video) tutorials section merged into the Knowledge Base system. A search implemented for both the Knowledge Base and Userguide. Improvements to the UI so users are able to contribute fixes/improvements to the documentation that they are reading (a comment system exists already, but a better system would be preferred, with the ability for team members to confirm fixes before they are merged). Your work should be broken into manageable phases (one per feature or bug fix) and your timeline should detail these phases.

Knowledge Prerequisites

  • Object Oriented PHP (essential)
  • Basic git (necessary)
  • phpBB (preferred)
  • UI and jQuery (strongly preferred)

Available Mentors

  • Yuriy Rusko

Area51/Development Micro-Site

Brief Explanation

Area51 is a micro-site for phpBB.com for development of phpBB. It contains the Continuous Integration, Development Discussion Board, API Documentation, Bug Tracker and more. We would like this revamped in either a frontend way (new design that can have a header shared by all the web applications and design for the main informational pages) or new pages/features or both. Some suggested changes are below but you are not just limited to these and can suggest others in your proposal:

  • A New Getting Involved Page
  • More Statistics using data from Bamboo (CI), JIRA (Bug Tracker), Github and the development board
  • Integration with JIRA, Bamboo and Github
  • Moving to phpDocumenter2 for API Documentation
  • New Area51 Style
  • Creating a parser for events docblocks and a UI to present the documentation in (Could be made a plugin for phpDocumenter2 if you choose)

Expected Results:

We expect all proposed features/improvements/changes completed. It should be able to be broken down into smaller manageable phases/chunks (one per feature or bug fix) and your timeline should detail these phases.
Existing code: GitHub phpBB Area51

Knowledge Prerequisites

  • PHP (Essential)
  • Web Design & Usability (Essential)
  • HTML (Essential)
  • Symfony (Preferred)
  • Git (Preferred)
  • Javascript (Useful)

Available Mentors

  • Michael Cullum
  • Paul Sohier (Backup Mentor)

Extensions Ideas

In 3.1, we would like to encourage the creation of extensions, rather than MODs, for 3rd party contributions. The major difference between the two is that MODs require a core code modification of some kind, whereas extensions are designed to be self-contained plugins that modify behaviour through responding to events triggered in core code, rather than modification of the code.

The difference between the two is rather drastic so we would like to provide a few real-world examples. MOD authors can then familiarise themselves with the new extension system by looking at these. While we do not necessarily want all GSoC students to focus on creating extensions, as opposed to improving the core project itself, we would appreciate one or two extensions to act as fully-functional examples. As a student, you will not be required to support or maintain the extension beyond the timeframe of GSoC, unless you wish to do so. And we certainly hope you'll stick around!

It is a good idea to become familiar with the basic aspects of the extensions system prior to the start of GSoC. However, the extension you create is going to be one of the first extensions ever built, so the examples available to you are very limited. You are of course welcome to ask any questions you might have on IRC.

Karma

Summary

While you don't necessarily have to name it "Karma" (reputation, etc. also work), the idea behind this extension is to add a way for users to publicly give positive or negative feedback about a user based on their contributions to the community (i.e. posts and topics, but should have a way for other extensions to add items that can receive Karma). This MOD may be of use when researching features to include.

Expected results

Creation of a fully functional extension that adds a Karma system.

Knowledge prerequisites

  • PHP
  • HTML
  • JavaScript/jQuery

Available Mentors

  • Joas Schilling
  • Marc Alexander

Points

Summary

Points/cash MODs have proven very popular for both phpBB 2.0 and 3.0. They basically allow users to give other community members virtual "cash" or "points" that can be used for various things. This extension should create a way for other extensions to interact with and use members' points. This MOD may be of use when researching features to include.

Expected results

A fully functional points/virtual cash system

Knowledge prerequisites

  • PHP
  • HTML

Available mentors

  • Joas Schilling
  • Marc Alexander

Proposing your own idea

For non-website ideas, RFCs on Area51 are a good source of ideas as they represent what our users already told us they want. Most mentors are available in phpBB's Discord or phpBB's IRC development channel #phpbb-dev and on Area51.

If you propose an original idea it will have a higher chance of being accepted if it satisfies the following two criteria:

  1. Checkpointable - it should be possible to break down your project into pieces that are by themselves meaningful. In practical terms, this means you should be sending a pull request every 1-2 weeks reflecting your work during that period, and the pull request should be individually mergeable. Avoid proposing a project that cannot be split into 1-2 week chunks.
  2. Likely to be completed - this involves several factors, but at the end of the day the goal is for your work to be finished within the GSoC timeframe. You should start by detailing components of your project to sufficient extent that they can be estimated. Then, honestly estimate how long you think it will take you. Then double that estimate. If you exceed 3 months, your proposal is probably too ambitious and you should reduce its scope.

As always, if you are unsure about anything or have questions please don't hesitate to contact us. Also, please discuss your idea first before proposing it in your application.



check out our sponsor