BuddyPress 3.1.0 is now available!

BuddyPress 3.1.0 is now available. It includes 23 bug fixes. See https://buddypress.org/2018/06/buddypress-3-1-0-maintenance-release/ for more information.

Note that there may be some manual adjustments you will need to make to fix some outstanding issues.

BuddyPress 3.0.0 “Apollo” is now available!

BuddyPress 3.0.0 “Apollo” is now available for immediate download from the WordPress.org plugin repository, or right from your WordPress Dashboard.

Read all about it at https://buddypress.org/2018/05/buddypress-3-0-0-apollo/

Check out the changelog for more information https://codex.buddypress.org/releases/version-3-0-0/

BuddyPress 2.9.3 is released: https://buddypress.org/2018/01/buddypress-2-9-3-security-and-maintenance-release/

BuddyPress 2.9.3 is released: https://buddypress.org/2018/01/buddypress-2-9-3-security-and-maintenance-release/

Our Awaiting Contributions milestone contains…

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…

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.

#3-0, #trac, #workflow

BP Codex Summary for 2017

Status Update

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…

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.