GiveWP Development Handbook

Introduction

This handbook defines the standards by which GiveWP developers and contributors may work together to maintain and improve the code base over time.

The GiveWP approach to development can be described as a modified agile workflow. This workflow leverages aspects of Scrum and Kanban frameworks with a focus on transparency, inspection, and adaptation. The goal is to release usable code more frequently with continual testing along the way.

Agile Development Principles

The Manifesto for Agile Software Development is based on twelve principles:

1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

GiveWP's Take on Agile Development

GiveWP's development workflow borrows heavily from agile development with some tweaks to reflect the remote nature of the team and its tools. This handbook documents the processes, tools, and standards by which we communicate.

Adhering to the standards within this handbook will result in:

• Improved clarity of the relationship between issues, commit messages, and pull requests.
• Faster comprehension of changes without having to dig into the code.
• Reduced difficulty of naming things through formal guidelines.
• More granular version control in the event that changes need reverted.
• Faster onboarding of new team members through well-documented guidelines and procedures.
• Less friction for community contributors wondering how to communicate changes.