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 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 Docs-Chat Summary March 28, 2024

    BP Documentation tracker stats

    • BP Codex contains 271 pages.
    • 279 total tasks were created (migrate + ignore + add + update).
    • 267 tasks related to the pages reviewed were created (migrate + ignore).
    • 43 Open | 15 Closed « migrate » tasks.
    • 0 Open | 209 Closed « ignore » tasks.
    • 5 Open | 4 closed « add » tasks.
    • 2 Open | 1 closed « update » tasks.
    • Approximately 82% of 279 tasks have been reviewed (229 / 279).

    Multisite and Multiblog Testing:

    @vapvarun is testing multisite cases to prepare new screenshots and documents. Discussion on issues and complexities related to multiblog setup, including configuration and potential bugs.

    Object Cache Testing:

    @espellcaste mentioned limited testing against plugins like Redis and plans to set up CI for testing against Memcache. #9076

    CSS Issues and Tickets:

    Identified CSS issues with the “hello” screen and other areas. Discussion on related tickets and ongoing efforts to resolve them. @emaralive tasked with investigating a specific #9111 ticket related to BP Hello menu. Discussion on focusing documentation efforts on multiblog configurations for BuddyPress.

    Multiblog Feature:

    @vapvarun working on documenting various multiblog configurations and use cases. Consensus to deprecate multiblog due to low usage and maintenance challenges.

    @imath suggest to consideration of deprecating multiblog feature. @patriciab mentioned using multiblog for multilingual communities where each subsite represents a different language. @imath reassured that deprecation is not happening soon and emphasized the need to preserve backward compatibility.

    Participants discussed the use cases and challenges of the multiblog feature, as well as potential implications of deprecation. Plans were made for further discussions and a demo of the multilingual community site.

    Next Docs-Chat

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

    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 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 Docs-Chat Summary February 28, 2024

      BP Documentation tracker stats

      • BP Codex contains 271 pages.
      • 202 total tasks were created (migrate + ignore + add + update).
      • 194 tasks related to pages reviewed were created (migrate + ignore).
      • 42  « migrate » tasks were created.
      • 152 « ignore  » tasks were created.
      • 5   « add     » tasks were created.
      • 3   « update  » tasks were created.
      • Approximately, 72% of a total of 271 pages have been reviewed (194 / 271)

      There were various comments by @dcavins & @im4th in regard to the stats:

      • @dcavins made note of the number of ignore tasks that were created and asked whether this was a indication of out of date documents.
      • @im4th made note of the progress made and responded to @dcavins regarding out of date documents, e.g,, pre 1.7 information, Theme changelog, snippets of code, etc.
      • @vapvarun & @dcavins conversed a little bit about the efficacy of code snippets.

      Review of how WP Docs teams handle discrepancies with published documentation (2 examples)

      Example 1 (one) was a DevHub (Advanced Adminstration Handbook) document and example 2 (two) was a HelpHub (End User – Support Guides ) document, of which the purpose was to plant the seed as to how the BP Team would/should handle user feedback:

      • DevHub provided a link to GitHub Advanced Admintration repository.
      • HelpHub provided a comment box, in which to provide user feedback.

      @im4th made note of some confusion regarding the use of discrepancies (the meaning thereof), of which @emaralive provided a general meaning and @dcavins expanded the meaning to include suggestions for improvement. @im4th was initially of the thought to use a method similar to how DevHub handled the situation and wanted a concrete example. @emaralive mentioned that example 2 was an actual issue (the text and screenshots are out of date, from WP v4.9.6, approx.). To move things along and not to belabor the point of this exercise, @emaralive mentioned the opening of a Discussion topic within the document tracking respository whereby further dialogue could be advanced, n,b,, @emaralive still needs to open the topic.

      Open Floor

      Earlier @vapvarun mentioned he had some documentation related Pull Requests ready to go. During Open Floor @vapvarun indicated the following would be next up for him:

      • Configure BuddyPress for Multisite ( possible cases )
      • Installation in WordPress Multisite
      • Languages and Translations

      @im4th indicated the he would review the Pull Requests that @vapvarun had ready to go. During this Open Floor time, @espellcaste indicated that he had documentation (.md files) related to BP CLI that could be placed within the BP docs folder, however, @im4th had some reservations as to where the BP CLI documents should reside. Additiionally, @espellcaste indicated that he had plans to outline the workflow related to BP CLI documents and since we were short on time, I indicated that I would open a Discussion topic in the BP document tracking repository, of which, that discussion can be found here.

      Next Docs-Chat

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

      #docs-chat, #documentation, #summary

      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

      BP Dev-Chat Summary February 5, 2024

      What do we expect from 14.0.0?

      • We started with a very interesting thread about transforming the Private Messages component as a Slack-like chat system where BP Groups could be used as channels to discuss with corresponding group members. The wp-sync package could help us to reach this goal.
      • As it’s a pretty huge change, improving the Private Messages component using pagination could be a first step on our road. The potential backwards compatibility obstacle with Standalone BuddyPress themes could be avoided improving the way we currently use the WP Theme support feature adding a list of buddypress features. Eg: add_theme_support( 'buddypress', [ 'messages_pagination', 'etc..' ] ).
      • @emaralive suggested to have a look at the Better Messages plugin.
      • We talked about #7133: Having @rayisme‘s BP Followers into our Add-ons galaxy would be a great addition. As @im4th already got in touch with @rayisme about this subject he will contact him again to ask him if he’s fine with transferring the GitHub repo into the BuddyPress org so it’s easier for the team to contribute to it.
      • @espellcaste see potential Cron related issues about #7953 (Activity Scheduling).
      • @im4th thinks we should consider improve Activity favorites to act like bookmarks or likes, see #5644.
      • About BuddyVibes @im4th is currently working on making it a WP Block only Theme first. He thinks if we’re waiting for a design contribution it will never happen, reason why he chose to work on a very basic structure.

      14.0.0 first schedule!

      14.0.0 will be a shorter development cycle than 12.0.0 (which took us almost a year). A 4/5 months development cycle was decided: 14.0.0-beta1 in 4 months, final release in 5 months.

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

      @dcavins suggested to start discussing on the tickets we should keep into the 14.0.0 milestone during our next meeting. @espellcaste suggested to start looking into it a bit before the meeting to only leave the tickets we should discuss about.

      Next Dev-Chat

      It will happen on February 19, 2024 at 21:00 UTC in #BuddyPress.

      ⏰ 🔩

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

      BP Dev-Chat Summary January 22, 2024

      Minor releases

      • Shortly after 12.1.1 release, a bug was reported in Forums about the fact 12.0 deprecated functions were not loaded when BuddyPress was first installed with 12.1.1. @im4th & @emaralive worked on #9075 and fixed the issue. Decision was taken to release 12.2.0 a day after the chat. This new minor version contains some other regression fixes.
      • BP Classic also required a minor version. 1.3.0 was released two days after the chat.

      Next major version is 14.0.0

      • After a discussion about our release packaging process which is mainly a « manual » one, @espellcaste suggested to build a GH Action to save us some time & energy, see #9080.
      • @im4th reminded us we can share our ideas about 14.0.0 from this support topic.
      • @espellcaste also volunteered to review the BP PHP Unit Tests tool to make it easier for BP plugin developers to use it. He found out installing BuddyPress into this context wasn’t optimal when working on 2 external plugins. See #9081. He reminded us he shared his ideas about 14.0.0 in a reply to January 8 dev-chat agenda.
      • @im4th informed he should update WordPress env npm package to 9.0.0 soon. This change should ease the GH Action about PHP unit tests. See #9053.
      • Talking about the ticket to bring BP 12.0 support to bbPress, @dcavins reminded us about @boone’s polyfill which can help plugin developers to move forward & stay back compatible with BuddyPress « Classic » versions (11.4.0 & lower). It’s available on Packagist.
      • @im4th thinks it’s great news @espellcaste plan to work on improving the BP REST API as it will be used a lot into the BuddyVibes BP Block Theme.
      • @emaralive asked about a tentative target date for the 14.0.0 release & we agreed to give us 2 more weeks to think about it. As @espellcaste wasn’t aware about our decision to skip the bad number 13, we reminded him this decision came from @im4th’s fear about this number 🐈‍⬛🪜.
      • We finally talked about the will we shared on feedback posts to progressively shrink BuddyPress transforming optional components into separate BP add-ons. The Blogs component will probably be the first to be transformed this way. The fact 12.0 was a huge first step towards a Modern BuddyPress is probably explaining why @im4th is not thinking about it as an emergency. @emaralive rightly said working on BP Documentation has a higher priority.

      Next Dev-Chat

      It will happen on February 5, 2024 at 21:00 UTC in #BuddyPress.

      🍀🐰

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

      BP Docs Chat Agenda: January 10, 2024

      Hello BuddyPress contributors!

      I hope you all had great times celebrating the end of 2023 and the new year’s eve. I wish a great 2024 to the BuddyPress open source project and to all of us: its contributors.

      If I have a long list of wishes to address to our project for this new year. On this very first day of 2024, my biggest wish is to complete a challenge we haven’t met last year: do the needed work so that BuddyPress can provide users, developers and contributors with fully updated documentation resources.

      Next BP Docs meeting will happen on January 10, 2024 at 19:00 UTC in #BuddyPress, here’s our agenda.

      BP Docs status

      As I’ve explained during our last 2023 development meeting: although some contributors volunteered to form a team and made great progress about organizing contributions putting together a g-spreadsheet to manage needed updates and performed tasks, scheduling & running <bp-docs /> meetings and doing benchmarks about how some other documentation teams were structured and tooled, everything stopped on October 12, 2023 😖. This interruption was following a private conversation that took place between members of the BP Docs team, myself and other members of the BP Core team.

      I take the full responsibility about this interruption as I didn’t succeed to convince the BP Docs team members the plan we previously agreed on about using our main SVN repository to store and work on the next versions of our user, developer & contributor documentation sites was the best way to progress and begin to share updated documentation resources thanks to our GitHub mirror. The main disagreement was about user documentation: results of the BP Docs team’s benchmark showed using GitHub to organize documentation contributions was only done for developer resources. I understand the main reason behind restricting GitHub flavored collaboration to developers only is due to the need for “regular” users to learn the Markdown language as well as Pull Request workflows. This last requirement seems to be considered by the BP Docs team as a blocker to further progress.

      I believe we still need to, at least, try to do what we wrote we would do before questioning it:

      If GitHub can be intimidating for the uninitiated, using it from our BuddyPress GitHub repository has interesting benefits:
      – We don’t need to wait to put up documentation sites: we can start contributing right away (and we actually started!)
      – When committing a new Documentation contribution, we can credit authors so that they are rewarded with a lovely BuddyPress contributor badge on their WordPress profile.
      – As explained into our last feedback post: having docs directly inside our repository shows we acknowledge Documentation is as important as code.

      Once we’ll be satisfied with the docs content, we’ll always be able to use the WordPress handbook plugin to synchronize it with a BuddyPress.org Network site, or better to browse documentation directly from the WordPress dashboard of the site BuddyPress is activated on.

      @im4th (BP Docs-Chat summary: July 12, 2023)

      With the BuddyPress 12.0.0 release, I realized improving the way we guide users and developers to enjoy the plugin the best way possible had now become a crucial task for the project. That’s why, for the second time, I’m renewing / relaunching a call for documentation contributions.

      Let’s meet on January 10, 2024 at 19:00 UTC in #BuddyPress to chat about it!

      Meeting’s agenda:

      • What about the BP Docs team?
      • Migrating & Maintaining (once migrated) user documentation can use 2 different workflows.
      • What was accomplished so far, what needs to be accomplished now?

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

      🥂📢

      #agenda, #docs-chat