From phpBB Development Wiki
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 almost always require a core code modification of some kind, whereas Extensions are designed to be self-contained plugins that do not actually change anything in the core.
Because the difference between the two is rather drastic, we would like to provide a few real-world examples for MOD authors to be able to use to becoming familiar with the new Extension system. While we do not necessarily want all GSoC students to focus on creating an extension, as opposed to improving the core project itself, we would be happy with one or two extensions to be created to act as fully-functional examples. As a student, you will not necessarily be required to support or maintain they extension beyond the timeframe of GSoC, unless you wish to do so.
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 ever extensions, so the available examples for you are limited. You are of course welcome to ask any questions you might have on IRC.
Brief explanation: 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.
Brief explanation: 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.
Expected results: A fully functional points/virtual cash system
Knowledge prerequisites: PHP, HTML
Rich Text Editor Integration
Expected results: Integration of a Rich Text Editor into phpBB core, making the use of the bulletin board a lot easier by allowing users to pick the editor that fits their needs.
Session Backend Abstraction
Brief explanation: 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.
Available Mentors: Andreas Fischer
There are several possible subprojects within this project:
- 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.
- 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
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 may be of use, or not.
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.
Available Mentors: Oleg Pudeyev
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
You do not have to use one of the ideas listed here. For non-website ideas, RFCs on Area51 are a good source of ideas as they represent what our users already told us they want. However, 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.