Small features (those that take less than ~3 hours to create) are usually simple enough that they don’t need any formal design/development process. After the idea has been approved by the Community team, contributors can go ahead and build them in whatever way seems best to them.
Any projects that are larger than that, though, usually benefit from a more intentional approach. This helps to save everyone’s time in the long term, and to avoid situations where key parts of the feature need to be redesigned or refactored after they’ve been reviewed by the Community and Meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. teams, which can be demoralizing for everyone.
The process outlined below doesn’t have to be followed rigidly, but it captures the team’s intent, which is to gather detailed feedback (on both design and development) early and often.
- Follow the process for gathering stakeholder input and feedback before moving on to design.
- Once the idea has been accepted and iterated on, the design process starts by creating UI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. wireframes. They don’t have to be pretty (something hand-draw on a napkin is enough), but they should be comprehensive. The act of creating wireframes forces you to think through details that are often overlooked when just talking about an idea.
- If you prefer, you can build the raw HTML/CSS instead of wireframes, but try to avoid spending a significant amount of time on things that might change based on stakeholder feedback.
- Publish a new post on make/Community asking for feedback on the wireframes. Make sure to describe any user actions, inputs, etc, that weren’t able to be captured visually in the wireframes.
- Iterate on the wireframes based on the feedback from the community.
- Once the feature has been designed, you can start thinking about code. A few things to keep in mind before you start writing:
- Don’t rely on any 3rd-party dependencies, unless they’ve been discussed with WordCamp.org committers first. We generally use them far less than typical sites, due to security and maintenance considerations.
- Strive for lean and simple code, don’t over-engineer things. Follow the YAGNI principle. Don’t use OOP unless it fits the problem well.
- Follow the WP coding standards.
- Similar to the design process, it’s helpful to get feedback early and often. The Meta team will need to review and approve any code contributions before they’re merged, and they often request changes (both big and small). You’ll save yourself time and frustration by getting small reviews along the way, rather than a big one after you’ve built everything.
- It’s usually helpful to break the project into small components, and work incrementally. One way to do this is with Agile sprints, where each short sprint produces “working software” that can be deployed Launching code from a local development environment to the production web server, so that it's available to visitors. now, even if it only does a small piece of the end goal. Use whatever feels best to you, though. Another approach is requesting reviews at key milestones (e.g., 10% completion, 30%, 70%).
- When the feature is complete and the code has been approved, the Meta team merge the code into the official repository, and deploy Launching code from a local development environment to the production web server, so that it's available to visitors. it to production.