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.

And we’ll reward documentation contributors just like code contributors with props & a BuddyPress contributor badge on their WordPress.org profile (as shown above).

Our support forums is another strategic area we absolutely need to be better on. Some figures about it are very impressive, eg: there are 127,716 posts inside the How-to & Troubleshooting category. Do we still need all these posts? I’m sure we don’t: some posts are probably about very old versions of BuddyPress and can be misleading nowadays. We should archive what’s no more up to date, have a specific tag for resolved questions, get rid of duplicates, etc. There again, I believe we need a Support leader to tackle all manner of improvements and manage a team of support contributors.

Last but not least: how do we collaborate about plugin features or fixes?

I believe it’s what’s at the root of the 3 last key feedbacks. I can understand some frustrations you shared because I’m feeling the same regularly when it comes to contributing to WordPress code. As a contributor it’s difficult to be pushed back for reasons we do not agree on or that we don’t understand, to see a ticket postponed indefinitely or even worst to be ignored. I personally try to always write a few words in my ticket replies to say « hi, thanks for your feedback » or explain why I’m not sure we should do what you’re suggesting because I value your contribution & I know it’s important for you. We can agree or disagree, we can change our minds, we can take bad decisions, the most important is to act at some point with BuddyPress community interests in mind. We can always act again to revert some mistaken changes. We all learn from our mistakes and I’d rather make a lot of mistakes than stay still. Here’s my advice if you strongly believe we should fix an issue or add a new feature: have it built and share it with us as patches or pull requests. Most of the time doing is half deciding!

Yes we currently have a « low number of contributors » and yes I believe BuddyPress deserves more love ❤️. Again you are all welcome to express yourselves on code, documentation, support, events, etc. Don’t hesitate to contribute even if you just started BuddyPressing, we’ll always help you and believe my experience, you’ll learn a lot. I had no ideas about PHP Object Oriented programming, PHPUnit, Continuous Integration, React, SASS etc.. I’ve learnt all this contributing to BuddyPress.

Oh, one more thing: let’s meet during a BuddyCamp, a BuddyPress online meeting or at least do talk about BuddyPress during as much as possible contributor days or WordCamps! If you need help with your contribution table or with your slides, don’t be shy or afraid: ask us about it here!

Props 🤗 !

First: many thanks to @dcavins for his review 😍.

Many thanks for your feedbacks, it’s a great first step, what about contributing to your ideas with us as a next step?

David McCan, Derin Tolu, basicD, Tom Watts, Sander van Dragt, Mr David Hoy, Tara, Jann, Vicent Nemeyimana, Bryant, muhittinsahilli, johnjamesjacoby, ok2net, espellcaste, riversdale1844, djpaul, dimensionmedia, sunsetcowboy, egyptimhotep, staion, shahriar83, unsalkorkmaz, osmor1, giannis4, gomle, fanvid, fawp, coolhunt & imath.