Hi BuddyPress contributors!

Can I bother you to contribute a few more minutes of your time to fill out the 2015 contributor survey? It helps everyone establish some baselines around the contributor experience so that we can gauge how things change over time.

This is being posted to all the Make teams, so if you subscribe to a bunch of p2s and keep seeing this post, know that you only need to fill the survey in once, not once per team.

The survey is anonymous (so you can be extra honest), all questions are optional (so you can skip any that you don’t want to answer), and we’ll post some aggregate results around the end of January. It took testers 5-10 minutes to complete on average (depends how much you have to say), so I bet you could crank it out right after you read this post.

There are two sections of the survey:
* The first has questions about team involvement, recognition, and event involvement, and is pretty much what you’d expect from an annual survey (which teams did you contribute to, how happy are you as a contributor, etc).
* The second section is about demographics so we can take a stab at assessing how diverse our contributor base is. All questions are optional, but the more information we have the better we can figure out what we need to improve. If there’s some information you’d rather not identify, that’s okay, but please do not provide false information or use the form to make jokes — just skip those questions.

The survey will be open until January 15, 2016. Whether you have 5 minutes now, or 10 over lunch (or whenever), please take the 2015 contributor survey. Thanks, and thanks again for making 2015 awesome!

The $bp global

Way back in the early days of BuddyPress, the $bp global variable was king. Just about everything BuddyPress related was connected to it in some way (other than the template loops themselves.)

This approach is not uncommon. Even WordPress does something similar in wp-settings.php:

$GLOBALS['wp'] = new WP();

The major difference between WordPress and BuddyPress here is that the $wp global has always been a WP() object responsible for setting up the WordPress environment, while our $bp global used to be just a big collection of random attributes.

We’ve been fairly open and relaxed about latching on to the object as a global data store for all of BuddyPress’s runtime variables. Several third-party BuddyPress plugins use it, and our BP_Component interacts with many of its variables directly.

Fast forward to 2012, and $bp is transformed into a real BuddyPress object, complete with methodology and best practices, and ready to be a bit more intelligent than it was in the past. Since then, we’ve slowly removed our dependence on touching the $bp global directly, and instead encapsulated it in a call to buddypress() to retrieve the object into the current scope. You can read more about the overall initiative on Trac Ticket #5138.

This evening, I replaced all of our remaining global touches with one sweeping changeset. In most cases, this should be a completely invisible change that means very little to anyone not working on BuddyPress core. For the small group of us constantly building and maintaining core, this means a few different things:

• No more defining the $bp global. Use the buddypress() instead.
• Even though the global is still hanging around for backwards compatibility, touching it directly should be avoided to prevent accidental breakage.
• We can start to introduce magic getters and setters for commonly referenced or manipulated variables to ensure their evocation and ongoing validity.
• We can start reliably moving other BuddyPress globals into this object, and architecting what the next generation of extensions to BuddyPress core will look like, and how BuddyPress core will react to them.
• We can sleep a bit more soundly knowing that the $bp global has an extra layer of protection against being unknowingly overridden by unexpected plugin conflicts or other WordPress environmental oddities. (Though it’s been years since BackPress and BuddyPress were actively loaded together, between BuddyPress, BackPress, and bbPress, the “bp” namespace was very easily polluted.)

Though developer impact should be minimal, this represents a sweeping code change for BuddyPress 2.3 that should not go unrecognized or uncelebrated. This bit of clean-up was years of iteration and testing, and it feels pretty darn good to have it over and done with so we can move on to other more pressing issues.

#5138

Trac Updates

It can be cumbersome to navigate, intimidating to learn, and difficult to master. We know Trac isn’t always the most user friendly tool, but we love it anyways because it works really well for managing the type of project BuddyPress is and the workflow we use.

These issues are exacerbated when Trac is out of date, or has not been “gardened”, which usually refers to general pruning, tidying, and making sure there’s a place for everything and everything is in its place.

Over the past year or two, we’ve focused on improving the software and the build tools, and (other than software updates to keep up with WordPress’s Trac) haven’t revisited our Components, Milestones, or Resolutions in a long while.

This morning I made some rearrangements I think will help us stay better organized and on-target, outlined below:

• Added the “Under Consideration” milestone, for issues that the core team has reviewed but hasn’t decided on exactly where it belongs yet. This is good for keeping Awaiting Review empty, and getting feedback to ticket authors sooner.
• Components are now namespaced by what exactly they are intended to be. This should help tickets get categorized appropriately sooner, and help the core team better assess what areas need what improvements.
• Several components were renamed to more approximately reflect our intentions for them.
• Removed (4) beta and RC releases from Versions. Any related tickets were moved to their closest appreciate version. We were hugely inconsistent with these versions, and much of the time these were not accurate.
• Deleted old milestones for Unit Tests and TestBP.org. These had 4 total tickets that were moved to more apprpriate milestones.
• Added the “regression” ticket type, to help draw attention to issues that should be tested more quickly and prioritized higher.
• Tens of tickets were shuffled around to better match the above changes. Sorry for the barrage of emails this probably sent out to several of you.
• Updated current and future milestones to loosely set the pace for 2.2.1 and 2.3, which will start not-long-after 2.2 is released.

Like most things, all of these changes are open to criticism and scrutinization. If it turns out they hurt more than they help, we can try something else. These changes are inspired by years of interacting with Trac and witnessing repeated workflow hang-ups.

We aren’t exactly agile; sometimes members of the core team don’t intersect on issues for a few days, and tickets go unloved for weeks or months. I think we do great in the face of this, and hope our slightly modified arrangement feels like a natural progression of our growing team and project.

Some agenda items for today’s core developer chat:

• Activity stream performance improvements: https://buddypress.trac.wordpress.org/ticket/5349
• BuddyPress profile editing within wp-admin: https://buddypress.trac.wordpress.org/ticket/5197
• General BuddyPress 2.0 goal and expectation setting

Tomorrow we’ll be releasing BuddyPress 1.9 With it…

Tomorrow, we’ll be releasing BuddyPress 1.9. With it comes a host of fixes, improvements, WordPress 3.8 compatibility, and a shiny new Notifications component.

Once BuddyPress 1.9 is released, the core team will be taking some time off for the holidays before getting started on 2.0. Each of us have a wish-list of things we’d like to see in our next major iteration, and we know you do too. We’ll be putting together a brief questionnaire after the beginning of the new year, to make sure our vision is on track with yours, and so we can course correct if necessary.

More here tomorrow after 1.9 goes out!

We’re going to be packaging up BuddyPress 1.7…

We’re going to be packaging up BuddyPress 1.7 imminently. Last chance to hit us with any issues regarding:

• Theme Compatability
• Groups Admin
• Users queries
• Security issues

Spent some time today cleaning up the many…

Spent some time today cleaning up the many international subdomains we have at BuddyPress.org. If you are an admin for one of these sites, take a look around and make sure things aren’t too broken. A few things:

• Cleaned up about 5k pending spam comments across all the sites. Yikes!
• It’s using some unified header magic right now. You don’t have control over the menus yet.
• If you want forums, just ask. I activated bbPress on a few of the recently active sites, though I didn’t make any forums for them.
• If you’re not an admin for any language, but want to be, post here and I’ll be in touch.
• If you’re an admin and don’t want to be anymore, speak up in case someone else wants to take it over.
• If you want to trick out your subdomain i18n site beyond what is immediately obvious, comment here so we can figure out how to make it happen.

#i18n

Updated BuddyPress org to use the latest bbPress…

Updated BuddyPress.org to use the latest bbPress trunk, which enables forum wide search.

Finally.

We’ll keep iterating on the templates, sidebar, and layout. Right now it’s a little wonky.

In BuddyPress 1.7 we’re concentrating on simplifying as…

In BuddyPress 1.7, we’re concentrating on simplifying as much of the experience of using BuddyPress as we can. Part of this involves removing the update/installation wizard and replacing it with simple automation; because making out-of-context decisions immediately after activating BuddyPress didn’t really make anyone happy.

We’ll take care of the complexities and decision making, and redirect to a “What’s New” page similar to WordPress and bbPress.

Developers: if you somehow managed to write a plugin that used the old wizard (we purposefully did not make it very extensible) consider this your warning that it is already gone in BuddyPress trunk. 🙂

Those of you that really liked it, we think you’ll like the new experience even more. If not, be sure to let us know what you think and why when 1.7 is released.

An agenda item for this coming weeks BuddyPress…

An agenda item for this coming weeks BuddyPress core dev chat, is determining what components we’d like to have on by default. From #4671:

In Vancouver, the core team (minus Paul) discussed the idea of switching up the default components that BuddyPress comes activated with. I think the “all-on” approach is overwhelming for new users, can be confusing, and isn’t a very rewarding experience.

Since every component is pretty awesome, and they all rely on each other in some way, the idea of turning components off at all is a little weird at first. Each component has strengths, weaknesses, and potential to be extended into something more than it starts as.

I’m mostly agnostic about which components make the most sense as the default ones, but if I had to pick a favorite, I think having activity streams and profiles turned on, with everything else turned off, would make the best starter experience, and here’s why:

• Profiles are completely missing from WordPress.
• Friends don’t make sense without profiles.
• Groups don’t make sense without users and profiles.
• Settings doesn’t make sense without profiles.
• Private messaging is useless without a profile to connect it to.
• Forums come with bbPress now, and don’t need profiles to function at all.
• Activity streams don’t make sense without profiles, but they can run pretty silently in the background and aggregate activity.

It’s true that even with the XProfile component off, BuddyPress still fakes the profile experience pretty well. I’m imagining an activation experience without a setup wizard. One where when BuddyPress is activated on a new installation, the admin is greeted with a message like:

Welcome to your new community! Check out your new profile to get started

With a tabbed What’s New/Credits page like WordPress core has, we could easily explain what the components are, and why they might want to roll them out over time. Opening this up for discussion here, with the intention of getting this decided shortly after this weeks dev chat, and into trunk soon after.

Join in on Wednesday (time/location in the sidebar) and help us shape the new user experience in BuddyPress 1.7.