BuddyPress 2.9.3 is released: https://buddypress.org/2018/01/buddypress-2-9-3-security-and-maintenance-release/
Our Awaiting Contributions milestone contains 480 tickets, of which 141 are classified as bugs, with the rest (339) as enhancements. I propose that we close ~260 of enhancement tickets to help make our project more sustainable.
In a recent post, I announced some Trac workflow changes, and alluded to a problem with the “Awaiting Contributions” milestone.
Any bug report that the project hasn’t fixed in a release, or feature suggestions we haven’t implemented, or those that we hadn’t made a decision on whether to implement or not, have eventually ended up in the “Awaiting Contributions” milestone. This milestone tends to be one-way; relatively few tickets have ever made it out into an actual release.
260 of the 339 “Awaiting Contribution” enhancement tickets have not been modified since December 2016 (see list here); this means no edits, no patches, and no comments.
I believe this is because the enhancement tickets have a variety of relevance: some are good ideas that fit the project, some are good ideas but perhaps don’t fit the project any more, and some are ideas that might fit the project better in the future. Very few people know which new features might be accepted today. Historically, we have not had the discipline and the right processes in place to make hard decisions.
Are good ideas still valuable even if no-one has wanted to work on them, years after they were shared? Of course they are, but more importantly — more realistically — we will never be able to implement even a small percentage of these enhancements. We would not be saying “no” to the ideas, just being honest with ourselves and recognising that is unlikely that we will ever have enough people to implement them.
There is a psychological backlog to this number of tickets; it’s a weight on our shoulders, and for the average WordPresser, it might suggest that the project is not actively maintained.
I suggest we close these inactive enhancement tickets so we can start over, and repeat this process every year. Yes, it’s a cull. The enhancement tickets from 2017 onwards are recent enough that they might be more relevant than the older tickets, and few enough that we can thoroughly re-review these over the year ahead.
I am not proposing to close the bug reports in the “Awaiting Contribution” milestone, as they merit re-review. If I felt inclined to fix a bug, it’d be great to have an audited backlog of bug reports to pick from, with the confidence that they are still relevant, and that they contain enough direction on how they should be fixed, to be sure that my contribution would be accepted by the project.
Regular contributors, I’m looking forward to your feedback.
I have renamed BuddyPress Trac’s “Future Release” milestone to “Awaiting Contributions”, because realistically that’s what any of those tickets need in order for them to get done. I have also created an “Up Next” milestone, to try to solve the problem of contributors perpetually adding “interesting” tickets into the next major release’s milestone, without perhaps committing to work on them (I’ve been guilty of this myself on numerous occasions!).
Back in 2016, I published some ideas to try to improve milestone/workflow management. Some small improvements came out of that good discussion.
With the milestone renamed, the workflow for tickets is now, in this order of progression:
1) Awaiting Review: all new tickets start here, awaiting an initial response and triage.
2) Under Consideration: is where new tickets are placed, while we evaluate them and gather further feedback and comment.
3) Awaiting Contributions: is where accepted tickets are placed. They should have consensus and enough detail for someone new to the project to understand and work on.
4) Up Next: is a new milestone, that will contain interesting tickets that contributors have expressed in working on within the next two releases (e.g. half a year, or so).
5) Number major/minor releases: these milestones track tickets that a contributor has committed to working on for that release.
Tickets will be demoted backwards into “Awaiting Contributions” if for some reason they are moved to a more active milestone but never completed.
I hope this makes sense; we’re very limited by the ticket organisation/planning tools we have in Trac, but once we get used to this, I think it will give everyone a better understanding of what will probably be happening in the next half-year’s worth of BuddyPress releases.
I am aware that renaming “Future Release” has not solved any problems associated with that “graveyard” milestone; I have an upcoming discussion post with some ideas for improvements.
Happy to hear feedback; easy to rename or adjust course if that’s what our consensus is.
There were 2 BP major releases (2.8.0 and 2.9.0) and 12 minor releases by the all-volunteer BuddyPress contributors in 2017. These activities have generated the following updates for the codex to date:
2 New Articles
14 Release Change Logs
32 Articles Updated
The Codex in 2018
Here’s hoping that barring major technical glitches or hidden grinches, developer.buddypress.org will be launched sometime this year. We’ll be reorganizing and adding articles to the Codex as some sections will be moved to the developer reference site. Details of the changes will be posted here and we’ll be asking for your feedback and support.
Help us improve the BuddyPress Codex. If you’re interested in updating existing articles or creating entirely new ones, please read our Codex Standards & Guidelines and let us know via the #buddypress Slack channel or in comments below.
Props to Codex Contributors, 2017
Many thanks to everyone who contributed new articles / updated published posts from January 1 – December 31, 2017!
Legacy Forums support will be removed with BuddyPress #3.0, due for release next year.
If your site is still using Legacy Forums, you will need to migrate to bbPress 2. Backwards compatibility will be ceased.
The last planned BuddyPress release that will support Legacy Forums is #2.9.3.
“Legacy Forums” is what we call the bundled version of bbPress 1 that has shipped with BuddyPress for over nine years. In fact, bundled or not, bbPress 1 only runs on WordPress versions older than 4.7, because a conflict between something called BackPress, which is nested inside bbPress 1, and the
WP_Taxonomy class introduced in WordPress 4.7. So: if you’re using bbPress 1 today, you must be using an old version of WordPress, otherwise your site is broken.
This withdrawal of support is something that has been discussed for the last four years (see tickets 5351, 7502), and we feel now is the time. We will be including compatibility fixes for Legacy Forums with the upcoming BuddyPress 2.9.3 (date tbc) to help assist with any sites that are about to migrate to bbPress 2.
The removal of Legacy Forums from trunk will happen very soon.
What would you like BuddyPress to focus on in 2018? The core team has ideas of where BuddyPress can expand on and your input is important to harness the time and resources of an all-volunteer crew.
The survey will take 10-15 minutes to complete. Be assured that we will not publish your name, email address, nor IP address when we post the results of this survey at BuddyPress.org.
Thank you for your time and cooperation. Your feedback will help us improve BuddyPress for you.
A few years ago, I started a wp-cli-buddypress project. I occasionally added commands that were useful to me personally, but didn’t pretend to have anything close to complete coverage. A few months ago, Renato Alves (@espellcaste) contacted me to see whether he could help flesh out some of the missing commands. We moved the repo to the official BuddyPress GitHub account https://github.com/buddypress/wp-cli-buddypress, opened a BP ticket to track the potential integration of the commands into BP itself https://buddypress.trac.wordpress.org/ticket/7604, and got to work.
Since that time, Renato and I have done extensive work to bring basic CLI commands to all the main components of BuddyPress. Specifically, we have CRUD commands for all major content types, as well as a few helpful utility methods. The list of supported commands is too long to list here – you can explore by typing <code>wp bp</code> and digging down through the tree – but here’s a very brief summary:
activity– CRUD commands, comment management, favorite management, spam/unspam
core– Component activation and deactivation
group– CRUD commands, member listing and management, invitation management
member– bulk generation
signup– CRUD commands, activation, resending
tool– commands for running any BP repair tool
xprofile– CRUD commands for groups, fields, and user data
While there’s more to build – and refinements to be made – we’re at a point where we need real-world testing and feedback. If you are a BP developer, or administer BP-powered sites, and if you use WP-CLI, please install wp-cli-buddypress today and start using it.
There are numerous ways to install a wp-cli package, but because this one is in development, we encourage you to get a repo checkout. Something like:
$ git clone https://github.com/buddypress/wp-cli-buddypress ~/.wp-cli/commands
and then add the path to
wp-cli-buddypress/wp-cli-bp.php to the
commands subsection of your wp-cli config file https://make.wordpress.org/cli/handbook/config/#config-files.
Questions to consider while using the commands:
- Are the commands named in a way that makes sense? Note that in some cases, commands have aliases (eg
wp bp group createand
wp bp group add).
- Think about argument patterns across the commands, and whether they are consistent and make sense. Some commands take certain positional arguments (
wp bp group get my-group) while others require named arguments (
wp bp xprofile data get --user-id=5 --field-id=10)
- What major features are missing?
For specific issues, you’re encouraged to open a GitHub ticket: https://github.com/buddypress/wp-cli-buddypress/issues. For high-level discussions, you can open a GitHub ticket, leave a comment here, or drop into the #buddypress channel on wordpress.org Slack.
And for the truly intrepid: Contributions are encouraged! We’ve worked hard to ensure 100% Behat test coverage, which makes writing new commands fun.