Skip to content

Latest commit

 

History

History
118 lines (79 loc) · 6.67 KB

CONTRIBUTING.md

File metadata and controls

118 lines (79 loc) · 6.67 KB
Raw

Contributing to MyBB

To report a confirmed bug or problem, create a thread the Community Forums for the appropriate version of MyBB within the Development category, if the problem was not reported already on the Forums or as Issues on GitHub. If it is, but receives little attention, you can share details on how it impacts your forum to help diagnose the problem.

To suggest changes or features, go to the Suggestions and Feedback forum. Please make sure that your feature hasn't already been suggested and is not already planned.

Help prioritize Issues by adding a "👍" reaction to new features you'd like to see in MyBB or for problems affecting you.

Learn more about contributing to MyBB by providing support to other users, improving the documentation, verifying security controls, or developing custom extensions:

MyBB — Get Involved →

Development

If you have technical or coding experience, you can help by:

  • participating in development discussions,
  • resolving Issues by submitting code changes,
  • reviewing Pull Requests,
  • verifying submitted bugs and providing additional details.

Learn more on the MyBB development page:

MyBB — Get Involved: Features & Development →

If you need any help with sending your code contributions, the GitHub Help site is a good place to start. You can also get in touch with MyBB developers and the Community through our support channels.

Running MyBB

MyBB requires a web server with PHP support and a database. MyBB Documentation — Requirements →

If you want to use a manually-managed stack, copy code from the desired repository branch to your web server's HTTP-exposed directory.

  • Code for MyBB ≤ 1.8 can be run as-is.
  • Code for MyBB ≥ 1.9 references external dependencies, installed using Composer (composer install).

To quickly setup a self-contained development stack with PHP + Xdebug + Composer auto-installation, web server, and database system(s), use Docker Compose:

$ git clone https://github.com/mybb/mybb.git
$ git clone https://github.com/mybb/deploy.git
$ cd deploy
$ docker compose up

Using MyBB's Development Stack →

MyBB on GitHub

Branches

Maintenance/Legacy Branches

  • master Currently contains legacy code of MyBB 1.6.
  • feature Currently contains code for MyBB 1.8.

Workflow for MyBB 1.9 and up

MyBB development will follow the gitflow branching strategy:

  • main — latest stable release for latest stable branch, or main-* for given older branch (e.g. main-1.9 for 1.9).

    • hotfix- — quick releases for critical issues (e.g. hotfix-1.10).

      When ready, the hotfix branch is merged back to main-* and dev-* (or release-*, if one exists).

  • dev-* — development codebase with changes that were applied after the last release.

    • release-* — release preparation: version numbers and other metadata (e.g. release-3.2.1).

      Prior to a release, security patches are merged in and the release branch is merged back into dev-* and main-*.

    • feature-* — new features being worked on (e.g. feature-custom-avatars) When completed and tested, the feature branch is merged back to dev-*.

Issues

Bugs and improvements to MyBB software packages are documented in corresponding Issues.

Issue titles should work as short summaries identifying the problem or intent:

Type Title Style Title Examples
Bugs and problems Problem declaration (declarative mood) - Moderator notes fail to get saved
- Moved thread link name not changing properly
Improvements and tasks Instruction (imperative mood) - Move Who's Online building into a function
- Omit unwanted links / buttons
Features Feature name - Goodbye Spammer Integration
- Global 2FA

Labels

Triaged Issues usually have multiple Labels assigned:

  • Branch (b:*), the x.Y release branches they are related to,
  • Priority (p:*), how important they are (1 per Issue),
  • Status (s:*), what stage the development is currently in (1 per Issue),
  • Type (t:*), what kind of problem or operation they are related to,
  • Involving (i:*), additional labels for specific modules, libraries, or types,
  • 3rdparty, assigned to external code and other third-party solutions,
  • dev-branch, unreleased, development branch issues that don't affect behavior of stable versions and are irrelevant when upgrading,
  • easy-pick, used for simple issues for new contributors that don't require extensive MyBB knowledge to resolve.

Labels are generally only used for Issues.

Milestones

Issues can have specific Milestones assigned, meaning that they are expected, or preferred to be addressed in given versions. Issues with assigned Milestones may still be postponed to prioritize other changes.

Assignments

Issues with personal assignments are expected to be handled by assigned developers. Similarly, the review process of Pull Requests can be directed by developers assigned to them.

Commits

Follow The seven rules of a great Git commit message.

Pull Requests

Pull Requests (PRs) should only be sent for confirmed Issues, and only one issue should be fixed per Pull Request.

All changes made in Pull Requests must follow the development standards:

Use imperative mood in the title, summarizing changes the Pull Request introduces, and reference the Issue ID in the message.

Include a closing keyword for each resolved Issue at the beginning of the Pull Request's description, e.g.

Resolves #123
Resolves #345

Replaces Anvil::push() with Anvil::fall().