BuddyPress 4.0.0 “Pequod”: https://buddypress.org/2018/11/buddypress-4-0-0-pequod/
Recent Updates
BuddyPress 4.0.0 RC 1 is…
BuddyPress 4.0.0 RC 1 is now available: https://buddypress.org/2018/11/buddypress-4-0-0-release-candidate-1/
4.0.0 stable is currently scheduled for Tuesday, November 27.
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.
