Contributor Wants/Needs for 2.0 Dev Cycle

Today, during the #buddypress-dev chat on irc the community chatted about things they wished to contribute during the 2.0 dev cycle.

“I believe that individual features get built quicker and in a more robust way when more than one developer/designer/plumber/etc is directly involved in that process. I think this is the most important workflow change we could and should make this year.” – Paul Gibbs

I’ve compiled a list of things from todays dev chat that contributors want to accomplish before the 2.0 release. The ideas discussed today along with the results of the recent BuddyPress survey will help determine additional milestones. You can track the milestones for 2.0 release here: 


  •  Personally, I’d like to try to clean up the Future Release abyss, but that’s another discussion all together.
  • Officially retiring old bbPress and the old bp-forums component; Rewrite Rules; and incorporating a plugin of mine to move profile field visability into the Settings component.
  • I hope we’re able to concentrate heavily on moderation and administration functionalities, including integrating more things into wp-admin where it makes sense. Plus, I’d really like to talk about what a default media / photo album experience looks like, which I know imathfromparis has mentioned recently too.
  • I plan on dedicating more attention to 2.0 than any release in my recent history, so know that I’d like to around and available and a resource for any questions, tickets, ideas, thoughts, the entire cycle.


  • I’m teaming up with Brajesh Singh (of buddydev fame) to work on overhauling the current implementation of xprofile field types. Core has hardcoded pieces of validation and field templating littered throughout itself, and that makes it hard for plugins and themes to add new profile field types. We’re planning to make all this much more sane, and give the power to plugin developers to add bespoke field types. At the very least, we plan to put together a demo plugin alongside these changes to show people how new field types can be added, and I’d like to see if we can find one or two new profile fields which would make a nice addition to core.


  • My primary interest for 2.0 is in the activity component
  • Getting last_activity out of there will greatly increase the efficiency of our members queries. Splitting the query will allow us to scale much better with millions of items
  • Begin to implement object caching for certain parts of the activity component, with an eye toward better caching throughout BP
  • Helping along karmatosed’s template project
  • Helping the CPT/activity ticket that’s been in the works for a long time
  • Lurk and commit other people’s patches. Want to give fast feedback to new contributors.


  • Media is a great challenge. I have some ideas about it, mainly around the concept of attachment for other components
  • I also like the idea of having a way to manage user profile fields in the admin
  • Explore a couple ideas around activity, like using heartbeat
  • I think we should also do something for CPT and activity
  • I like to find ways to make the site tracking component more popular
  • I think about listing the registrations and give the ability to manage them
  • Group extension management in the Group Administration screen


  • Like boonebgorges, I want to make sure our object caching is up to speed. We’ve attempted in various releases to add in object caching where appropriate, but actual production environments are having trouble with cache invalidation especially when logged-in.
  • I’m also interested in the rewrite rules ticket that JJJ is tasked with. Was playing around with that on a recent project and it’s peeked my curiousity.


  • I would like to see a (template) sprint. Set a time of 2 weeks and get it prototyped. Call for more hands including core (huge thanks for offers said here). If we keep it small and get this minimal roadmap I think we could do it. Also a freeze – no new stuff.
  • The key to this is cut out the extra stuff. We may drop the side menu.. we may cull other things. The idea is we can refine this over time once have something or even over releases to add bells and whistles. We need to be mean in what is in and out. We also need to kill that long ticket and get it into sections or something that is more manageable 🙂


  • Codex has a stage two fleshed out with various tasks that must be addressed.
  • Primary amongst those is continuing to edit and update articles – now also with a view to checking for conformance to 1.9 stream retiring any specific to earlier iterations.
  • We have some re-factoring to address changing ‘getting started’ to be a ‘users manual’ and starting a general BP Glossary
  • Mercime is tackling translation issues
  • Lastly we need to follow up and complete the layout re-factoring and menuing where required and will need to speak with core devs with suitable access to these areas, also we need to address a few tickets in trac.

*If you missed the dev chat you view the irc log here:

#2-0, #dev-chat, #irc

Minutes of November 3rd dev chat: BuddyP…

Minutes of November 3rd dev chat:

BuddyPress1.2.7 release out towards the end of next week to fix a few important bugs that have been found in 1.2.6 (#2203, #2699 and #2685).

BuddyPress 1.3 roadmap items assigned to core devs, except basic profile privacy which is to be reviewed in a couple of weeks. A few new smallish features have been added, and we’ll post links to the relevant trac tickets as-and-when here.

Finally, we decided that dev chats will now happen every Wednesday at 19:00 UTC.

#dev-chat, #irc

Minutes BuddyPress 1.2.6 release Ticket …


BuddyPress 1.2.6 release
Ticket 2587 is the only blocker. 1.2.6 is likely to be released by the end of this week.
A lot of key internal functions regarding the permalinks and active components have been changed, and we’d like any more feedback from tests of non-standard installations, such as deactivating components and turning things on and off.

Release cycles
Future releases will have an improved, more predictable release schedule, such as how the core WordPress team handles releases. BuddyPress’ core dev team and contributors will be considering this when 1.2.6 is shipped and work starts on 1.3, probably in the next couple of dev chats.
Boone has been continuing to improve the website; check out the cool ‘topics I started’ page. More is on the way, and as always, volunteers are welcome to help improve the Codex: see this discussion for more details.

#dev-chat, #irc

Minutes of August 11, 2010 dev chat


There are about 10 tickets, most of them fairly small, standing between us and 1.2.6. The thorniest issue is #2000, which concerns duplicate items in the activity stream. After some discussion, it sounds like this ticket might get punted. JJJ on 1.2.6 timing: “hopefully by next week”. Ninjas
Boone reports progress on two fronts:
1) mercime has been working on an outline for a reorganization of the Codex. Dev and community feedback is requested. Check it out here:
2) Boone now has access to the theme and plugins, and will be beginning the process of applying patches next week.

A poll will appearing soon on where community members can vote for what gets put on the roadmap.

All in attendance agreed that spam is a can of worms. Several ideas for combatting spam, both on and within BuddyPress itself, were floated, ranging from foxly’s discussion from a few months back, JJJ’s in-progress Honeypot, and Humanity. peterkirn and others are planning to start a group on to continue the conversation and offer up some suggestions.

Small strides are being made, both in plugin-land and in the core, toward the possibility of a longtime dream, multi-BP (or is it BPMU?)

Finally, the all-important issue of who’s in charge was thoroughly discussed. Thanks for a good meetup!

#dev-chat, #irc, #meetup

Summary of Jan 20th dev chat

Thanks to all who participated in this first BuddyPress dev chat; same time same place next week.

We looked at the outstanding tickets for BuddyPress 1.2. Andy’s done some awesome working getting large numbers of bugs fixed in the last few days, but there are plenty which people can help out on by checking tickets and confirm validity. Andy said his plan was to get most of the major tickets, and most of the important minor tickets, resolved before the 1.2 beta. Tickets #1086, #1222 and #1445 were mentioned; they deal with i18n issues so a request was made for anyone familiar with issues surrounding i18n to take a look.

We are going to contact active WordPress bug gardeners and share ideas on ticket workflow. Andy Peatling is going to add some custom reports to the BuddyPress trac to make ongoing ticket management easier.

We moved on to discussing “bug gardening”. This involves looking at tickets when they come in and checking that the issue has enough detail for a developer to investigate and commenting, tagging and assigning a milestone appropriately. As volume of tickets begins to increase, we need more people helping out.

Testing for 1.2 now needs to concentrate on regular WordPress installs (not WPMU). So far it appears to be stable, but we are interested also in usability on regular WordPress; if anyone finds installation quirks or oddities please open a defect ticket on trac. It was confirmed and re-iterated that BuddyPress 1.2 will be fully compatible with WordPress 2.9.1+ and WPMU.

People really loved the feature poll which was on the site back in the heady days of BuddyPress 1.0. We are going to create a new sub-forum where anyone can post any ideas or features into the hat that they’d like to see in future BuddyPress versions. A future dev chat will then go through the ideas, make a selection, then put those into a poll on the site for people to vote on. This will decide what happens to BuddyPress in 1.3 and beyond.

Andy shared his thoughts on the future of BuddyPress. He’d like to see the development of BuddyPress broken down into chunks, and find people that are really interested in specific features. For example, if you really love the activity stream functionality, you could focus specifically on that and stick to patching and improving just that area. The long term goal being to get teams on components, and have that transition into core commit teams. A thread is going up on the forums to explore this idea in more detail.

John James Jacoby, GIGALinux and junsuijin have formed a documentation team to improve the BuddyPress codex. Some discussion and comparisons were made with the jQuery API website, and People in the chat were also keen on the idea of screencasts, and that discussion is continuing in this thread.

To read the full chat log, visit the IRC chat log website (the meetup starts at 19:00 timestamp, and is one hour long).

#dev-chat, #irc

Post Title

We’ve set the official dates and times for BuddyPress Development chats. Check the sidebar for changes, but we’ve decided to have them Wednesdays at 19:00UTC. (Click the 19:00 UTC link for the timezone conversion)

#dev-chat, #irc