BP Dev-Chat Agenda May 2, 2024

Hi!

Our next development meeting will happen on May 2 at 19:00 UTC (today!) in #BuddyPress. Here’s our agenda:

  • Needed follow-up to 12.4.1 Security Release.
    • Build a new maintenance release (12.5.0) to fix some too conservative or wrong escapes (asap!).
    • Make 14.0.0 and following BP versions include a WPCS Security Escape check for each grunt commit or PR submission.
  • 14.0.0 ticket updates
  • Open floor

If you have specific/additional points you need to discuss about, please share them into the comments area of this post.

PS: this meeting as well as next week one are exceptionally happening on a Thursday (due to the fact May 1st and May 8th are days off in 🇫🇷).

#14-0-0, #agenda, #dev-chat

BP Dev-Chat Summary April 17, 2024

🧰 BuddyPress 14.0.0

We first talked about ticket #8728 (allowing group mods/admins to delete corresponding group activities):

  • @emaralive did a great job reviewing existing group roles capabilities. We now have a clear understanding of these.
  • He also worked on fixing the filter callback so that it actually do what it was built for: allowing group mods/admins to delete corresponding activities.
  • @espellcaste has prepared unit tests about it.
  • The last point we needed to take a decision about was to introduce a global community setting to let the site’s Administrator to allow/disallow group mods/admins to delete activity as well as a « per group » basis setting to let the group creator to allow/disallow this delegation for their group. We all agreed it will be a nice addition. So next steps about this ticket is to build the corresponding UIs (BP Settings Admin screen + Group’s create/manage/admin screens).
  • As this summary is being written very late, @emaralive has updated the patch on the ticket 4 days ago and suggests we don’t need a group setting: promoting members to mods or admins seems sufficient.

We then talked about the Activity Block Editor (see ticket #8319):

« Videmo » of the BP Activity Block Editor Add-on
  • It’s still a work in progress that needs improvements such as being able to use this editor to comment an activity (@emaralive noted it), making sure using the paragraph block’s alignment button actually aligns the posted activity.
  • It replaces the current Activity WP Admin screen with a specific Activity stream using this editor to post, edit & comment existing activities.
  • Goal is to first publish it as « feature as a plugin » on WordPress Plugin directory, see how people welcome/use it before eventually merging it into the BP Activity component.

We finally talked about other tickets progress:

  • #8976 Adding custom xProfile fields to registration REST API endpoint: @espellcaste has made great progress about it and should have it fixed soon.
  • #9129 Automated tests with cache services: @espellcaste informed us we’d need a specific GitHub Action to reach this goal as it doesn’t seem possible to use the WordPress env package.
  • #6123 has been fixed, 14.0.0 won’t create users during a regular WP user registration, see this developer note for additional information.

    14.0.0 schedule reminder

    • June 3: 14.0.0-beta1.
    • July 8: 14.0.0.

    Next Dev-Chat

    It will happen today Thursday May 2, 2024 at 19:00 UTC (exceptionaly as yesterday was a day off) in #BuddyPress.

    #14-0-0, #agenda, #dev-chat, #summary

    BP Dev-Chat Agenda April 17, 2024

    Hi!

    Our next development meeting will happen on April 17 at 19:00 UTC in #BuddyPress. Here’s our agenda:

    If you have specific/additional points you need to discuss about, please share them into the comments area of this post.

    🚀 💫

    #14-0-0, #agenda, #dev-chat

    BP Dev-Chat Summary April 3, 2024

    🧰 BuddyPress 14.0.0

    Although we planned to share the progress we achieved about 14.0.0 tickets, just after @vapvarun informed he will work on #9097 (Member type assignment), we focused our attention on Group roles (#8728: making sure the group’s moderator role can better assist the group’s administrators).

    Let’s clarify what can do each advanced role of a Group

    If #8728 is about letting group moderators delete group activities, we extended the discussion to group admins and a particular group admin : the group creator.

    • The bug: it looks like this filter callback is not doing the job it should. Group moderators according to this code should be able to delete group activities.
    • @im4th’s concern: deleting someone else content is a serious move. He personally thinks instead of deleting the activity, all group roles should only be able to remove the activity from the group or spam it. He also hardly understands why an activity could be deleted as it’s possible to spam & kick a group member. He asked to check what happens to activities a group member shared within the group once they are marked as spammer or kicked out of the group.
    • BP Team’s majority is thinking group moderators and admins should be able to delete group activities and understands why sometime we might need to delete one off topic activity instead of spamming the group member.
    • @emaralive suggested to leave site admins then group admins choose about whether group activities can be moderated:
      • Site owner determines whether group activities can be moderated.
      • Group creator/admins determine whether group mods can moderate group activities.
    • When Akismet is active, activities can be marked as spams. @vapvarun suggested to use the activity spam flag to allow moderation within a group. He then quicky checked if group admins or moderators can use this feature: it turned out only Site Admins can use it!
    • Finally, @im4th suggested the following steps to clarify the situation:
      • Test widely what a mod can do in a group (eg: can he ban/kick/spam a user, delete an activity etc..)
      • Test widely what a group admin can do
      • Test widely what a group creator can do
      • Understand why the `bp_groups_filter_activity_user_can_delete` filter is not doing what it should.
    • @emaralive who is assigned on the ticket agreed & will investigate 🕵️‍♂️.

    14.0.0 schedule reminder

    • June 3: 14.0.0-beta1.
    • July 8: 14.0.0.

    Next Dev-Chat

    It will happen on Wednesday April 17, 2024 at 19:00 UTC in #BuddyPress.

    #14-0-0, #dev-chat, #summary

    BP Dev-Chat April 3, 2024

    Hi!

    Our next development meeting will happen on April 3 at 19:00 UTC (today) in #BuddyPress. Here’s our agenda:

    • 14.0.0 ticket updates
    • Open floor

    If you have specific/additional points you need to discuss about, please share them into the comments area of this post.

    🌱☘️

    #14-0-0, #agenda, #dev-chat

    BP Dev-Chat Summary March 20, 2024

    📦 12.4.0 minor release

    During the chat we discussed about the opportunity to build this maintenance release a bit before WordPress 6.5. @emaralive volunteered to test the last unfixed ticket of the milestone (See #9086). At the end of our chat @vapvarun brought #9096 to the discussion. The Last activity repair tool has become obsolete and we forgot to remove it from the available BP tools. Site Admins who used it so far experienced a very annoying effect: after the last activity item are removed they are not generated back. Result is the Members directory can have no active users displayed. We’ve explained why this tool was added in BuddyPress 2.0 and came to the conclusion it should now be removed to prevent the issue about « vanishing » Active Members. We evaluated we couldn’t wait for a major release like we’re used to do for such a change and decided to fix it into this maintenance release. 12.4.0 was released on March 25.

    🧰 BuddyPress 14.0.0

    Thanks to #9086 patch, @dcavins transitioned to a ticket slated to the 14.0.0 milestone: #9063. The goal of this ticket is to be able to have BP directory pages as children of another one. Instead of doing this @im4th’s plan is to only use the WP rewrite rules improving the BP Rewrites API to make support custom root prefix (eg: replace / by /community/ for instance.

    The Site Wide Notices debate

    In short, @im4th opened this ticket #9098 to explain why he thinks this feature should become a Core feature instead of being dependent of the BP Messages component.

    • At the beginning of the debate, moving it to the BP Notifications component (probably to improve consistency) seemed a better option.
    • @im4th’s concern was not satisfied with this scenario as it’s still an optional component: using Site Wide Notices to replace the Admin Notifications workaround we introduced in version 11.4.0 couldn’t be achieved as this component might be not active on some setups. He’d rather wait for the WP Notifications feature as a plugin in this case.
    • @espellcaste then suggested to build a new BP Add-on for this Notice feature. In this case we’d still need to use the Admin Notifications workaround to inform Admin Users about the big changes we plan to achieve in BuddyPress future. As @dcavins noted « Yes, the 11.4 workaround was pretty workaroundy. » 😅
    • @espellcaste last suggestion reached a consensus: build Site Wide Notices as a Core feature but make sure it integrates well with the Notifications component when active.
    • @im4th shared the main goals of this Core change:
      • improve the Site Wide Notices feature right away so that Admin Users can read our important messages but not into the WordPress Admin Notices traffic jam.
      • & let Admin Users still using it to inform all community members at once on the front-end (the current feature).

    14.0.0 top features

    1. @emaralive suggested #8319: using the Block Editor to write BP Activities. The potential for such an editor for the Activity component is very interesting: for instance BP Attachments is already using « Activity blocks » to post media from the Activity Block Editor (feature as a plugin). We could add Polls, Links etc…
    2. @dcavins suggested #1058: being able to export / import BP Data is something we’ve been thinking about for a while and it would be nice to engage into the Data Liberation WordPress project.
    3. @emaralive also suggested #9057: being able to deactivate the BP registration workflows. Building it as an optional component is not the road @im4th thinks we should take. Instead it should be a « deactivable » Members feature. @dcavins will look at it starting slowly by only using the WP signups table and stop creating users on regular WordPress sites.
    4. @dcavins also suggested #8728: making sure the group’s moderator role can better assist the group’s administrators. @emaralive is working on it and thinks he will fix the ticket during the 14.0.0 development cycle.

    Finally we quicky talked about BuddyPress permissions management and realized there’s a lot of possible improvements to bring to this part of the software.

    14.0.0 schedule reminder

    • June 3: 14.0.0-beta1.
    • July 8: 14.0.0.

    Next Dev-Chat

    It will happen on Wednesday April 3, 2024 at 19:00 UTC in #BuddyPress.

    #12-0-0, #14-0-0, #dev-chat, #summary

    BP Dev-Chat Agenda March 20, 2024

    Hi!

    Our next development meeting will happen on March 20 at 19:00 UTC (tomorrow) in #BuddyPress. Here’s our agenda:

    • 12.4.0: let’s build this minor release soon (before WP 6.5)
    • 14.0.0:
      • Do the Site Wide Notices feature needs to be reorganized (See #9098) ?
      • Considering the current 28 tickets, what will be the top feature(s) for 14.0.0.
      • Other ticket updates.
    • Open floor

    If you have specific/additional points you need to discuss about, please share them into the comments area of this post.

    🌱☘️

    #12-0-0, #14-0-0, #agenda, #dev-chat

    BP Dev-Chat Summary March 4, 2024

    ⏰ New development meeting day/time

    @im4th suggested to change the day and time we meet to discuss about BuddyPress development so that it’s more suitable for contributors located in Asian time zones. Let’s come back to our “legacy” day/time: every other Wednesdays at 19:00 UTC!

    @emaralive @espellcaste & @dcavins agreed (even during DST, 19:00 UTC can be problematic for David’s presence during 1st meeting half).

    As Documentations chats are also happening at this day/time, we’re always meeting on Wednesdays at 19:00 UTC and depending on the current week number, we’ll be talking about development (even weeks) or documentations (odd weeks).

      🧰 BuddyPress 14.0.0

      Release lead: imath

      @im4th asked if one of us was wishing to lead this release: @dcavins won’t be able to find the time to, @espellcaste volunteered to lead next major release. To let the time to @emaralive to experience a full release development cycle, @im4th volunteered & is the 14.0.0 release lead.

      Ticket updates

      To view the full tickets list slated for this milestone, go there!

      • @emaralive hasn’t progressed yet about #8728 (Allow group moderators to moderate group activities).
      • @espellcaste has put together a local site about BP CLI commands reference (See #9113).
      • @dcavins has not progressed about #8794. It’s a pretty sensitive subject as it deals with capabilities in WP Admin. Best approach seems to be to build a specific & new Admin screen to let users having the bp_moderate cap to manage site membership requests.
      • @im4th reopened #9101 as he was worried about the fact we’re adding 2 accordion sections to the site-health debug screen. It’s closed again as using a single section is not separating nicely settings from constants when using the copy feature.
      • @im4th moved the ticket about improving Activity Favorites management out of the 14.0.0 milestone (See #5644). He was the only one of the team in favor of introducing Likes as Activity children and highlight this as one of the top features for 14.0.0. Users will need to wait for a future BP Relationships API.
      • Without any news from @rayisme, he also moved the Followers feature (See #7133) out of the 14.0.0 milestone. Moreover the plugin’s scope is larger than following members (using it, you can follow activity or blogs for instance).
      • @emaralive wanted to talk about #9098 as re-thinking the Site Wide notices feature can have implications about BuddyPress documentations. But we agreed to talk about it during our next development meeting as it was getting late.

      Finally @im4th asked the team to use the 2 coming weeks to think about the 14.0.0 top features as @dcavins said “it’s nice to have a focus, so that the release accomplishes something that seems cohesive”. So far many of the enhancements slated for next release are to make administering a BP site easier.

      14.0.0 schedule reminder

      • June 3: 14.0.0-beta1.
      • July 8: 14.0.0.

      Next Dev-Chat

      It will happen on Wednesday March 20, 2024 at 19:00 UTC in #BuddyPress.

      #14-0-0, #dev-chat, #summary

      BP Dev-Chat Agenda March 4, 2024

      Hi!

      Our next development meeting will happen on March 4 at 21:00 UTC in #BuddyPress. Here’s our agenda:

      • Development meeting day/time: let’s discuss about coming back to every other Wednesdays at 19:00 UTC (current day/time is too late for contributors located in Asian time zones).
      • 14.0.0:
        • Let’s formally nominate the Release Lead,
        • Ticket updates,
        • Considering the current 29 tickets, what will be the top feature(s) for 14.0.0.
      • Open floor

      If you have specific/additional points you need to discuss about, please share them into the comments area of this post.

      🌎 🌍 🌏

      #14-0-0, #agenda, #dev-chat

      BP Dev-Chat Summary February 19, 2024

      What do we want to keep in the 14.0.0 milestone?

      • @espellcaste reminded us why he asked about making this specific point: to have a better visibility of what’s actually planned on the milestone. He added that if there was a ticket we don’t know if we would have the time to work on, it’d be great to put in the next milestone.
      • @espellcaste then asked Team members to assign themselves on the tickets they wish to work on during the 14.0.0 development cycle. Once done, his idea was to discuss together about the remaining tickets. He actually took the lead of the meeting to run this tickets review.

      Below is the remaining tickets list:

      • About #7133 (BuddyPress followers plugin to join the BP Add-ons collection) @im4th contacted @rayisme by e-mail but got no reply from him so far. @im4th already has commit access on the plugin’s WP.org repository but he thinks it’s better r-a-y’s GitHub repository is transfered on the BuddyPress organization account before we can all eventually contribute to it.
      • About #9065 it’s an issue Dion Hulse (from the WP Core/Meta team) started contributed to due to potential fatal errors with malformed Request inputs. @im4th thinks it’s important as Dion explained to fix it in BuddyPress waiting for it to be possibly fixed by WordPress, so he assigned himself on the ticket.
      • The chat thread was going pretty quick so @emaralive informed it was difficult to follow especially when you try to read a very old ticket like #5644 (Activity Favorites management). This was actually our second point on our meeting’s agenda! @im4th wanted to take the time to explain why he thinks we really should use Activity children like comments to transform Activity Favorites as Activity Likes. @espellcaste, who was probably very focused on reviewing the remaining unassigned tickets, didn’t pay attention to this discussion and carried on his review. (1).
      • @espellcaste thought @im4th was the best contributor to work on #9063 so @im4th assigned himself on it and will try to make it possible to add a way to use a slug prefix for BP Directories rewrite rules.
      • @emaralive volunteered to work on the Group Moderator cap issue #8728.
      • @espellcaste volunteered to work on integrating Group/Member types into the BP REST API and assigned the requested member types improvement tickets to himself (See #8618 & #9092).
      • @espellcaste then decided to punt unassigned tickets to next release cycle.

      14.0.0 schedule reminder

      • June 3: 14.0.0-beta1.
      • July 8: 14.0.0.

      BP Cli documentation

      Then @espellcaste decided to talk about this subject instead of the 2 remaining points we added to our agenda. His goal is to build a BP Cli command reference like the one WP Cli has elaborated. @im4th suggested « if we can do it for BP Cli, then we can also build a code reference for BuddyPress ». @espellcaste informed he would first look into a code reference for BP Cli as a test ground to see what issues we’ll face before eventually working on a BuddyPress code reference.

      (1) imath’s Apologies to @emaralive & @dcavins

      As I’m @im4th 🤗, the one writing this summary, I’d like to say:

      Even if this tickets Review was an interesting experience and even if @espellcaste was really good at running it, I realize I should have stopped him to take the time to make sure @emaralive could catch up when he expressed his difficulties, make sure @dcavins had a chance to express his wishes during the tickets review, and make sure to respect the meeting agenda. I apologize – a hard day at work was probably the reason why I made these mistakes.

      Next Dev-Chat

      It will happen on March 4, 2024 at 21:00 UTC in #BuddyPress.

      #14-0-0, #dev-chat, #summary