mirrors/i3

To avoid annoying merge conflicts.

Perl script is provided for convenience and simple format checking in
PRs.

2021-11-05 10:13:22 +01:00

Contributing

i3status/i3lock bug reports and feature requests

Note that bug reports and feature requests for related projects should be filed in the corresponding repositories for i3status and i3lock.

Read the debugging instructions.
Make sure you include a link to your logfile in your report (section 3).
Make sure you include the i3 version number in your report (section 1).
Please be aware that we cannot support compatibility issues with closed-source software, as digging into compatibility problems without having access to the source code is too time-consuming. Additionally, experience has shown that often, the software in question is responsible for the issue. Please raise an issue with the software in question, not i3.
Please note that i3 does not support compositors (e.g. compton). If you encountered the issue you are about to report while using a compositor, please try reproducing it without a compositor.

Read the project goals on the website and make sure that they are compatible with the feature you want to suggest.
We are generally happy with the current feature set of i3 and instead focus on maintenance such as stability and fixing bugs. New features will rarely be considered if they require additional configuration and/or commands, or if they add significant complexity (either through the exposed configuration or mental complexity) to the project.
Explain in detail what problem the feature addresses and why existing features fall short.
Consider whether the feature could instead be implemented using the IPC or other external tooling.

Before sending a pull request for new features, please check with us that the feature is something we want to see in i3 by opening an issue which has ”feature request” or ”enhancement” in its title.
Use the next branch for developing and sending your pull request.
Use clang-format to format your code.
Run the testsuite
If your changes should be reported on the next release's changelog, also add a small single-line file starting with a number (see examples) containing a short explanation of your change either in the changes or the bugfixes folder. Example of changes that should be reported are bug fixes present in the latest stable version of i3 and new enhancements. Example of changes that should not be reported are minor code improvements, documentation, regression and fixes for bugs that were introduced in the next branch.

Find a reproducible bug from the issue tracker. These issues have been reviewed and confirmed by a project contributor.
Find an accepted enhancement from the issue tracker. These have been approved and are ok to start working on.

There's an overview of the codebase available to get you started.