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

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.

Release Leads: Call for Volunteers

BuddyPress 2.8 will be released in a couple of weeks, and it’s time for our community to start considering release leads for BuddyPress 2.9 and 3.0.

Our experiments with the release lead role over the last year have worked out well, and for BuddyPress 2.9 and onwards, we’re opening up the nomination process publicly for improved transparency.

The release lead works with all contributors to ensure the success of the release. The role blends aspects of being a product manager, project manager, engineering manager, release manager, and community manager. Release leads do not need to be developers, but having experience contributing to open source projects is required.

Release leads are supported by the lead developers, the project team, and deputies of their choosing. Volunteering as a release deputy is a great way to give it a try and learn about the process, but with a smaller time commitment.

For the sake of clarity, BuddyPress release leads and their deputies, between them, can expect to:

  • Run our weekly project meeting, and write and publish meeting notes on our development blog.
  • Coordinate blog posts and announcements on social media.
  • Make final decisions about whether a proposed feature is able to be put into the release.
  • Help new contributors make their contributions seen and heard in project meetings.

While BuddyPress is built by people volunteering their own time, contributing whatever they want, however they want, the release lead should take advantage of their position and use it to shape BuddyPress. For example, if the release lead feels that the next release should have a focus on specific aspects, we expect them to declare this, and try to encourage regular contributors to make that a reality.

Are you interested?

If you are interested in volunteering to be a release lead, please comment here or contact either myself (@djpaul), Boone (@boone), or John (@jjj) on Slack.

#release-lead

I’ve updated the dates in…

I’ve updated the dates in the Schedule (in the sidebar of the bpdevel.wordpress.com site) for the #2.8 release timetable.

Hi everyone. As usual, BuddyPress’…

Hi everyone. As usual, BuddyPress’ contributor chat has been moved back to 20:00 UTC on Wednesdays, after the recent DST timezone changes for the majority of our frequent contributors.

Apologies to those who get caught off-guard by this late change for today’s meeting; at least you’ll be there on time! 🙂

Build/Test tooling

It’s always fun figuring out improvements for our build and test tooling, to make life easier for regular contributors. Does anyone have any ideas for things we can do to improve this in BP #2.8 ? I’ve given this a bit of thought. We could:

  • Grunt: remove dependency on Ruby by removing grunt-scss-lint#7028 (in progress)
  • Move bbPress 1 out of buddypress.svn.wordpress.org, and manually add it in when we commit the release build to plugins.svn.wordpress.org. We already do this for the bp-default theme. ?
  • Iterate on the NPM package versions and shrinkwrapping and related requirements, and make it work 100% reliable on @boonebgorges computers. 🙂
  • Look into performance improvements using Yarn, which acts as a wrapper/CDN for NPM. ?
  • Add Git commit hooks.
    • All committers work in Git, and commit to BuddyPress via git-svn. It isn’t an option to switch to committing in Git directly as the moment. We should think about what things we could/should pre-commit hook.

Super interested to hear any feedback or other ideas or wishlists around tooling! Share in comments below!