Last but not least! This is the final episode of our post series about the new direction we plan to take regarding the BuddyPress project. If you’re just discovering this series, we advise you to read about the 4 first episodes of it.

BuddyPress has a new purpose
Let’s better organize the BuddyPress plugin
What new features will be coming to BuddyPress?
How should back-end & front-end BuddyPress Interfaces evolve?

This post is finally focusing on the feedback you shared with us here & there about the BuddyPress community & BuddyPress contribution.

Key feedbacks about BuddyPress community

  • « A better website would help. No amount of new features will help if they can’t be discovered »
  • « Lack of documentation for developers and code examples. Codex must be improved. »
  • « BuddyPress still remains the best in the plugin industry but it needs more love from the community. »
  • « BuddyPress has been suffering from a low number of contributors in recent years. »
  • « ideology and maybe personal politics superseded the pushing of features that users wanted »
  • « there was way too much push back on fixes and new features »
  • « Key features never materialize »

A new theme for this community website is a must-have, I agree. Although our current theme does a good job, it has remained unchanged for years. We had begun to work on this but in a way that wasn’t in line with my conviction on this topic. That’s absolutely fine with me as long as we ship! It didn’t happen unfortunately, we didn’t manage to attract enough contributor energy. So I’m back with my conviction: we should build the Block Theme I told you about in episodes 3 & 4 with the secondary goal of using it for BuddyPress’ network sites! In my opinion, we’d kill two birds with one stone 🥌.

Ideally, all BuddyPress code should be available on our Trac environment. It’s fine to use GitHub as it’s using Git which is more intuitive than SVN, but at some point (eg: when the feature is stable), the code should be mirrored on Trac. We need a central place where people can open tickets, contribute to any parts of our project and be sure to be rewarded with our lovely contributors badge. Although I believe optional components (or any new Add-ons) should live in their own repository on the WordPress.org plugins directory, I also think they should primarily live into our Trac when it’s about contributing to their code. This way it will be easier for us to maintain all Add-ons making sure they behave nicely with each other when they are all activated. The confusions about where to contribute to the BP REST API experience convinced me that maintaining it on Trac once a stable version has been released (or included into Core for this API) is the right move to make (not to mention the fact I need to explore many different places to credit all contributors to a major BuddyPress release).

Contributors shouldn’t be confused about where to contribute to BuddyPress, there’s only one ☝️URL to know: https://buddypress.trac.wordpress.org/.

Documentation is very important and, let’s face it, we’re not good at it 📕. The codex is not updated as frequently as it used to be, the « wiki » model where everyone can contribute to docs is no more efficient.

The first 4 to 5 months of 2022, we’ve tried to organize contributors meetings to update the codex. The results were not at the level of our expectations:

  • No new contributors showed up, code contributors – including me -(many thanks to David and Varun) did their best but we missed some new energy to ship something concrete.
  • As coders, we naturally put our efforts on the tools putting up this staging site, and retrospectively, I think these efforts should have been directed on content.
  • We couldn’t work on any plugin major release during this period. 

I believe we need a Documentation leader 👨‍🏫 to organize this part, lead a documentation team and carry on the work we started on splitting resources between two targets (end-users and developers) :

  • use.buddypress.org: would replace the codex and contain resources about using BuddyPress
  • developer.buddypress.org: it was built during BuddyPress 5.0 development cycle to provide our REST API endpoints reference. We need to complete it with a Plugin an Add-on handbook, a Theme handbook and BuddyPress code reference.

We have recently decided to include a docs subdirectory to our main BuddyPress repository. This is where documentation (and its history) will primarily live from now on! This move reflects the fact we acknowledge documentation is as important as code.