-
Notifications
You must be signed in to change notification settings - Fork 81
Contributor Guidelines
Everyone is welcome to making participation in our W3 Total Cache project.
Examples of behavior that contributes to creating a positive environment include:
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this rules, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
Those rules apply both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
???
W3 Total Cache is distributed under the GNU General Public License, Version 2, June 1991. Copyright (C) 1989, 1991 Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110, USA
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
All discussion happens as a github issues comments.
Everyone is welcome to contribute to W3 Total Cache. Contributing doesn’t just mean submitting pull requests - there are many different ways for you to get involved, for example answering questions or reporting bugs.
No matter how you want to get involved, we ask that you first learn what’s expected of anyone who participates in the project by reading the Community Guidelines.
One of the most important and immediate ways you can support the community is to answer questions on the support forum. Whether you’re helping a newcomer understand a specific feature or troubleshooting an edge case with a seasoned developer, your knowledge and experience of W3 Total Cache can go a long way to help others.
Reporting bugs is a great way for anyone to help improve W3 Total Cache. The open source W3 Total Cache project uses github.com for tracking bugs.
When filing a new W3 Total Cache bug issue, please include the following:
-
A concise description of the problem. Describe the behavior you were expecting to see, along with the behavior you actually observed.
-
A reproducible test case.
-
A description of the environment that reproduces the problem. Include the W3 Total Cache version, as well as information about your target OS, http server used.
Before filing a new issue, take a moment to browse our existing issues to make sure you’re not filing a duplicate.
Reporting bugs is an important part of improving software. Nearly as important is triaging those bugs to ensure that they are reproducible, small, and unique.
There are a number of things you can do to help triage bugs in the bug tracker.
-
Reproduce bugs. For a bug to be actionable, it needs to be reproducible. If you can’t reproduce the bug, try to figure out why. Get in touch with the submitter if you need more information.
-
Reduce bugs. Once a bug can be reproduced, reduce it to the smallest amount of steps to reproduce.
-
Eliminate duplicate bugs. If two bug reports refer to the same underlying problem, mark the newer one as a duplicate of the older one. Doing so allows others to work more effectively.
The W3 Total Cache project uses small, incremental changes as its preferred development model. Sometimes these changes are small bug fixes. Other times, these changes are small steps along the path to reaching larger stated goals. In contrast, long-term development branches can leave the community without a voice during development.
Some additional problems with long-term branches include:
-
Resolving merge conflicts can take a lot of time if branch development and mainline development occur in the same pieces of code.
-
People in the community tend to ignore work on branches.
-
Very large changes are difficult to code review.
-
Branches are not routinely tested by the continuous integration infrastructure.
To address these problems, W3 Total Cache uses an incremental development style. Small changes are preferred whenever possible. We require contributors to follow this practice when making large or otherwise invasive changes. Some tips follow:
-
Large or invasive changes usually have secondary changes that must be made before the large change (for example, shared libraries modifications). Commit these changes before the major change, independently of that work.
-
If possible, decompose the remaining interrelated work into unrelated sets of changes. Next, define the first increment and get consensus on the development goal of the change.
-
Make each change in the set either stand alone (for example, to fix a bug) or part of a planned series of changes that work toward the development goal. Explaining these relationships to the community can be helpful.
If you are interested in making a large change and feel unsure about its overall effect, please make sure to first discuss the change and reach a consensus through discussion in the issue. Then ask about the best way to go about making the change.
Although we don’t enforce a strict format for commit messages, we prefer that you follow the guidelines below, which are common among open source projects. Following these guidelines helps with the review process, searching commit logs, and email formatting. At a high level, the contents of the commit message should be convey the rationale of the change, without delving into much detail. For example, “option value wasn't correct” leaves the reviewer wondering about which option and is wasn’t “correct”. In contrast, “List of minified files option was missing file extension” conveys almost all there is to the change.
Below are some guidelines about the format of the commit message itself:
- Separate the commit message into a single-line title and a separate body that describes the change.
- Make the title concise to be easily read within a commit log and to fit in the subject line of a commit email.
- Make body concise, while including the complete reasoning. Unless required to understand the change, additional code examples or other details should be left to issue comments.
- If the commit fixes an issue in the bug tracking system, include a link to the issue in the message via #number.
- For text formatting and spelling, follow the same rules as documentation and in-code comments - for example, the use of capitalization and periods.
- If the commit is a bug fix on top of another recently committed change, or a revert or reapply of a patch, include the Git revision number of the prior related commit, e.g. “Revert abcdef because it caused bug#”.
- For minor violations of these guidelines, the community normally favors reminding the contributor of this policy over reverting. Minor corrections and omissions can be handled by sending a issue comment.
W3 Total Cache uses WordPress Coding Standards. Those are strict rules, not guidelines or recommendations. Contributions to W3 Total Cache that do not adhere to these rules are generally not accepted. Note that not all existing code follows these rules, but all new code has to be compliant.
The only exception is external libraries included directly in the W3 Total Cache. Those are left as-is.
Plain file structure used to limit stat() calls when PHP traverses source folders or opcache modules check for updates.