Development on BuddyPress 2.6 began this week with a meeting to set the schedule and scope for the release. The BuddyPress project recently moved to adopt release leads as part of the core development process.
“The release lead gets a sense at the beginning of the dev cycle what he/she would like to accomplish, as well as what others want and are willing to contribute,” Boone Gorges said during last week’s development meeting. “Within those parameters, there is likely lots of room for the lead to make decisions about what the focus should be.”
- Beta: May 25
- RC1: June 8
- Official Release: June 15
Cavins said that 2.6 will focus on performance and UI polish, as many of the tickets filed for the milestone fall into those general categories. Contributors chimed in during the meeting to express interest in working on specific goals and tickets:
- A new API to manage single items navigation (#6534)
- Incrementor-based caching for ID queries (#6643)
- Explore implementing Behat to add a functional testing capability to the project
- Extend BuddyPress’ use of caching to group memberships
- Framework for bulk data handling after updates (#6841)
Cavins is also organizing a few “BuddyPress Work Parties” early in the release cycle where contributors can get together to collaborate on tickets, documentation, testing patches, and answering support questions.
In addition to the new release leads concept, the BuddyPress core team is also considering implementing component maintainers, similar to the way WordPress core is organized.
“It gives newcomers a sense of where to look if they have questions about a part of BP, or want to get involved in contributing,” Gorges said. “It also creates a sense of ownership for people who are already doing the practical work of triaging certain kinds of tickets, and encourages people to step up and take a role of responsibility.”
BuddyPress project lead John James Jacoby said that component maintainers has been one of his personal leadership goals for BuddyPress for a long time, with individuals and eventually teams “owning” components to make them shine.
“The main reasons to do it are empowering people to make decisions, and to elevate everyone’s contributions by promoting within and creating goals for contributors to graduate to, to celebrate their value,” Jacoby said.
Specific maintainers and/or teams have not yet been identified but the core team is working towards making this more official to streamline contributions.