This page describes how to get involved in phpBB's development.

You can help the project in the following ways:

• Reporting bugs
• Reproducing bugs and verifying fixes
• Creating patches
• Reviewing patches
• Discussing existing RFCs
• Creating new RFCs
• Participating in development IRC channel and area51

The following sections elaborate on each of these options.

Reporting Bugs

If you came across a bug, report it to the development team. Go to the issue tracker (tracker.phpbb.com/browse/PHPBB3), login (you need a phpbb.com account to login to the tracker), then use an appropriate Improvement or Bug link on the top right to create a ticket.

Besides reporting bugs that you found yourself you can also report bugs that other users found. Some of the topics in the support forum (www.phpbb.com/community/viewforum.php?f=46) relate to bugs in phpBB or are sources for possible improvement. Take the information provided by poster(s) in support forums and turn it into a ticket. Try to include all relevant details and omit irrelevant information. Ideally you should reproduce the bugs that you create tickets for - see the next section.

Reproducing Bugs

Find an open ticket in the issue tracker (tracker.phpbb.com/browse/PHPBB3). Follow supplied instructions, if any, to reproduce the issue yourself. You can use your own board, a public board such as phpbb.com forums, or a test board installed with a tool like QuickInstall. Once you reproduced the issue add a comment to that effect to the ticket.

If the supplied instructions were insufficient to reproduce the issue and you had to perform additional steps, or configure something in a particular way, add this information to the ticket. If the issue does not always occur you can state when it does occur. If your environment differs from that of the original reporter, add your environment information to the ticket.

This is especially helpful for frontend issues where different browsers may be affected in different ways, or for issues on unusual configurations where developers may have a hard time or be unable to reproduce the environment that results in reported behavior.

Verifying Fixes

This usually happens during RC phase of a release. All tickets that are fixed in a particular release should be verified.

First, use an installation running the previous release to reproduce the issue (see the previous section). Then, use an installation running the new release to make sure the issue no longer exists. Post the result of your verification in the ticket.

Creating / Submitting Patches

If you found an issue you think you can fix, whether this is an issue you reported or someone else reported, you can create a patch for it.

Creating a Ticket

If there is no ticket for the change you want to make, the first step is creating a ticket - see Reporting Bugs above. Every commit to phpBB repository must have a ticket reference in its commit message.

Writing the Code

Changing phpBB's code is outside the scope of this document. Assuming you performed needed changes, you can create a patch from them in a variety of ways. The preferred way of submitting patches is forking the phpBB repository on GitHub (https://github.com/phpbb/phpbb3), creating a branch for the ticket, committing changes to the branch and sending a pull request. For more information please see Git. You can also submit patches in other formats, for example as a unified diff between two files or directories, or even manual editing instructions.

Commit Guidelines

If you are submitting a patch via Github you should follow the commit guidelines. This is covered in detail in Git. Please at least skim the entire Git page to see what the guidelines are. Typically you need to pay attention to:

• Base branch: should be `develop-olympus` for 3.0.x and `develop` for 3.1.x and 3.2.x changes.
• Branch name: should be `ticket/12345`, `feature/feature-name` or `task/task-name`.
• Commit message: should have properly formatted subject, branch name in the subject, ticket number in the footer.

All of the above points are again explained in Git in more detail.

Please note that patches that follow coding guidelines and are submitted as pull requests are likely to be reviewed and merged quicker because they require less developer effort to process.

Coding Guidelines

Coding guidelines apply to the actual PHP/template/JavaScript code written, as opposed to commit messages and branch names. Please take care to follow phpBB's coding guidelines. Coding guidelines are somewhat different between 3.0 and 3.1; please see the correct document for the version your patch is targeting: 3.0 and 3.1.

Create an RFC If Needed

Before starting work on an issue which may be solved in different ways, or if your solution trades something for something else (such as performance for small boards vs performance for large boards, or amount of time/effort needed from a user/administrator to perform one action vs another action) you may want to discuss your ideas in IRC or on area51. See below for more details.

New features should go through the RFC process so that everyone can comment on both the ideas themselves and their implementation. The RFC process is documented on RFC_Process.

Reviewing Patches

All changes going into phpBB go through a code review process. This applies equally to patches submitted by developer team members and outside contributors. Developer merging a patch has the final responsibility to review and test the code being merged; however, anyone can review and test any patch submitted and provide their comments on patches.

Code to review may be found at the following locations:

• Unreviewed patches report: tracker.phpbb.com/secure/IssueNavigator.jspa?mode=hide&requestId=10054
• Unmerged fixes report: tracker.phpbb.com/secure/IssueNavigator.jspa?mode=hide&requestId=10053
• Pull requests on GitHub: https://github.com/phpbb/phpbb3/pulls

Patches are sometimes provided as manual editing instructions, as an attached diff or in other formats that are not immediately mergeable. You can take such patches and create proper Git branches from them. If you did not modify the original patch, ownership should be attributed to original patch submitter via `--author "username <username@code.phpbb.com."` Git argument when you commit the code.

Discussing Existing RFCs

RFCs are enhancement proposals for future versions of phpBB. You can provide comments on these proposals as well as collaborate on their implementation.

• phpBB 3.1 RFC forum: area51.phpbb.com/phpBB/viewforum.php?f=84
• phpBB 3.2 RFC forum: area51.phpbb.com/phpBB/viewforum.php?f=108

Creating New RFCs

Nontrivial changes to phpBB should go through the RFC process. If you have a proposal that you want someone else to implement, it must go through the RFC process. If you want to implement your proposal yourself it is usually a good idea to start with an RFC to allow other community members to comment on your proposal.

Currently phpBB 3.1 is feature frozen, meaning no new RFCs are accepted. An exception is an RFC that is a prerequisite for another RFC which is already accepted.

New RFCs should be posted for phpBB 3.2: area51.phpbb.com/phpBB/viewforum.php?f=108

Participating in development IRC channel and area51

Nearly all of phpBB's development is now public (with the obvious exception for security issues). When developers want to discuss something, have a question or want to request feedback they do it either in the development IRC channel or on area51. Everyone is welcome to participate in these discussions to whatever extent they want.

IRC Channel: #phpbb-dev on irc.freenode.net