Development for the BuddyPress 2.7 release cycle kicked off this week led by @mercime. Contributors chimed in during this week’s meeting to identify their wishlist items for 2.7. Beta 1 is expected September 21 and the official release is scheduled for October 12.
During last week’s meeting, lead developers John James Jacoby, Boone Gorges, and Paul Gibbs shared some of their big-picture ideas for the future of the project as well as plans for improving their development processes. Gibbs summarized their conclusions:
BuddyPress is used by many different kinds of people. We’ll improve BuddyPress by focusing on a narrower target audience: site builders and WordPress developers. This will cause many subtle but meaningful changes throughout the project. However, this is not a big change — it’s just an explicit recognition of what BuddyPress has become, and how people use it
BuddyPress, and the development decisions driving it forward, had originally been built around the idea of providing users with “a social network in a box.” According to Gibbs, the project has changed over the years to become “a set of tools or resources to let you build things with it.” The tagline has not yet been officially changed but BuddyPress core developers are now leading the project in a new direction.
“Another way to put this idea is: It will no longer be our #1 priority for BP to be 100% turnkey,” Gorges said. He explained that in the past, the core team has often closed tickets and decided against certain features in deference to WordPress’ “decisions, not options” core philosophy.
“This principle is designed to serve the non-technical owner who wants something as great as possible, immediately on activation,” Gorges said. “What the new idea suggests is that we should embrace configurability a bit more. I think we can and should continue to strive to have a great out-of-the-box experience, but we should be OK with deciding to emphasize the developer and site-assembler experience when the two are in conflict.”
Prioritizing the BuddyPress REST API
As part of embracing a more explicit focus on the developer and site builder audiences, BuddyPress will be prioritizing the BP REST API project and wp-admin management screens.
“The two key strategic priorities for the project are the REST API, and wp-admin management screens,” Gibbs said. “These are the most important because, alongside the existing front-end templates, we’ll have 3 different ‘views’ of BuddyPress data, empowering our audience to use as little or as much BuddyPress as they need, however they want.”
Gibbs said he believes the REST API is important because it will expose BuddyPress data in a different way and make it easy for developers to use that data to build things like mobile applications and JS-only React sites that don’t rely on WordPress for templating.
“In such cases where the front-end templates won’t be used, the REST API will provide a way to programatically update that data,” Gibbs said. “Also, the wp-admin management screens will let site owners manage that data, if they’re only using the REST API as a read-only data source.”
BuddyPress to Adopt Trac Component Maintainers
BuddyPress contributors will also be experimenting with a new way to work by implementing Trac component maintainers, similar to WordPress’ component maintainers. The role will be similar to how Dominik Schilling described it for WordPress:
Each component can have more than one maintainer. A maintainer triages new tickets, looks after existing ones, spearheads or mentors tasks, pitches new ideas, curates roadmaps, and provides feedback to other contributors.
The Trac components (listed in a dropdown when creating a new ticket) are not to be confused with BuddyPress components. In the near future, the BuddyPress core team will put out a call for maintainers of the two dozen Trac components available. Developers interested in taking some ownership over an area of BuddyPress should subscribe to the development blog for all the latest updates.