Component Maintainers

@dcavins would like notifications from Trac for new tickets under the Group components. He mentioned different workarounds like getting Slack notifications for the Groups component to getting the RSS feed from Trac for the specific component. @johnjamesjacoby: “We’d need to merge into our Trac what’s already in WordPress Trac. That’s probably Dion and/or Nacin.” @netweb noted after the chat that there’s a ticket in Meta Trac to get this underway.

BuddyPress 2.7.4

Can ‘change’ visibility on registration form even for fields marked “Enforce field visibility” (#7391) Ticket has been reopened to address coding standards.

Notice: Trying to get property of non-object (#7329) Has patch. Requested dev feedback from @rayisme

@djpaulgibbs: We are incompatible with PHP 7.1 as things stand – and I think we may have to rely on a fix in WordPress 4.7.x as well – so that’s the sort of thing that will likely go out once it’s ready.

BuddyPress 2.8 Tickets

Some more enhancement for translators (#5784) @slaffik recommended to close the ticket.

PHP Fatal error: Uncaught Error: Call to a member function get_do_autolink() on null (#7337) @slaffik has patch. @djpaulgibbs noted that patch should extend beyond preventing fatal errors to making the function usable outside the template loop.

Uninstall button and routine (#2755) This ticket would have to be put on hold until decisions are made on routines and details required to export/copy then delete/drop BP DB tables and other options.

Trac Gardening

@slaffik has been reviewing old tickets, closing some, adding others to 2.8, and “providing feedback where I see fit.” A friendly reminder to core devs to review tickets marked with `2nd-opinion`⁠⁠⁠⁠ and `⁠⁠⁠⁠dev-feedback`.

All the BuddyPress development takes place in Trac. All the tickets, most of the feature discussions and confirmed bugs, are all managed via Trac. For better tickets management, we use milestones, components, keywords and other ways to categorize everything. So far we have 24 components:

WordPress (as well as some other OSS) uses an interesting approach where a person or a group of people are responsible for a specific component of a software project. The contributors have a specific interest in their chosen component, and enjoy or see the need to focus most of their contribution time on it.

In the long run, this helps that contributor quickly triage tickets in their preferred component, as they specialize in it and build up a knowledge advantage. The overall project benefits by faster review and prioritisation of new tickets.

I propose to implement BuddyPress component maintainers, with the hope that this will help move development even further and faster.

Some components, like Activity, Extended Profile, and Groups, need special love, as the number of tickets there is 50+. These components will benefit from having multiple component maintainers assigned to them.

Component maintainers don’t need to do anything special – just consider reviewing Trac tickets for your component, when you have a will and time to contribute to BuddyPress. You will be expected to look through all existing tickets, as well as new ones, provide feedback and help the larger project prioritise bug fixes and new features.

If you have any thoughts about this, or want to volunteer to become a component maintainer – please write in comments. And remember, it’s good to have several people per component, so join in even if you see someone’s mentioned your favorite component!

Trac Clean Up

@slaffik proposed the following actions to address the 654+ tickets in the Future Release milestone:
1) Go through tickets with 2nd-opinion and dev-feedback – and reply, close, or consider working on it.
2) Go through tickets that were updated years ago – and consider them to be closed by default, but read and investigate the value. If a ticket has been left for a long time in Trac, it’s either not that important, a duplicate, hard, or forgotten.

@johnjamesjacoby noted, “Proper organization, along with timely responses, I think are more important, but I agree that keeping it tidy reduces the cognitive burden of ‘holy moly there are 500 things to do.'”

BuddyPress 2.4.1

(#6675) WP 4.4. deprecates wp_title() will be moved to BP 2.4.2 which is scheduled sometime after WP 4.4.0 is released.

BuddyPress 2.5.0

@djpaulgibbs proposed start of dev cyle on Wednesday, Dec. 2, and release by March 2, 2016. He also mentioned that “we will lose probably a few weeks’ worth of development over Christmas, but I’d rather keep the pace up even if that means a smaller release.”

@boonebgorges noted that “in the last couple releases we’ve done fairly long beta/RC periods. I think it’s been good to be conservative. But they’ve also been too long for what we’ve actually needed. So if we think the release might be a bit smaller, we might consider a somewhat condensed period between feature-freeze and release. Not something we have to decide today.”

Wishlist

These are a few of our favorite things and suggestions for this dev cycle:

Improve BP Navigation from @im4th. @boonebgorges has started work on ticket last week refreshing the `BP_Nav` ideas. He will “dive into it after WP 4.4 comes out.”

xProfiledata_meta from @boonebgorges. Fix the way xProfile field visibility is stored (move from usermeta to xProfiledata_meta), which will make the data schema saner and also allow us to fix some search-related bugs.

Improved caps from @im4th. Currently doing it in his template pack project.

Hashtags from @jconti. @slaffik noted that there are two BP-compatible hashtag plugins in WP repo. Chat continued on whether hashtags will be used for search vs. auto-completing hashtags or both. @rayisme has worked on a fork of etiviti’s older hashtags plugin, will require at least some form of unicode support. He will be working on “Better compatibility when using ‘BP_ENABLE_USERNAME_COMPATIBILITY_MODE’ and UTF-8” which would also support emoji hashtags mentioned by @djpaulgibbs.

BP Template Versioning from @hnla. Feedback requested on current ticket to move the project forward. (#6642)

developer.buddypress.org from @mercime. @djpaulgibbs noted the logistics required and testing will be needed before deployment. @boonebgorges mentioned some devs expect projects with stable APIs to have web-based documentation generated even when they are already big fans of the inline documentation.

Add “semi-private group” from @mercime. @boonebgorges pointed out that there were a couple tickets about separating the various parts of group status into standalone bits, so that you could make custom group types like visibility vs join/invite vs who-can-invite etc. A version of “semi-private” would be some combination of these things. (#6094)

Bulk mentions for Groups from @jconti. Feature is akin to Slack’s @ {here} {channel} {etc}. @djpaulgibbs noted that “the complexity there is around updating the notifications and probably a per-group setting to turn that on/off, when I rewrote the auto-suggest lookup stuff about a year ago, I had it in mind to be able to support group mentions, so there’s some work done already. @im4th brought up concern about notifications (emails) if a group has 200,000 members.

Reactions instead of favorites, dream from @im4th. @boonebgorges replied with “A dream: BuddyPress Relationship Table and API.”@djpaulgibbs: both ideas fill me with memories of many hours spent on those, I have like a quarter-done github branch somewhere porting Posts2Posts over if anyone’s really really keen. “

Update default templates from @hnla. Explore what we can do to update the default templates – perhaps with a focus on markup in core that can be extracted out to template directories.

There are more features, bug fixes, and enhancements not mentioned above that already have tickets in Trac and some that will have tickets soon. Join the fun in making this dev cycle another awesome one for the community!