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.
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.
Phase 1 (a.k.a., BP Codex migration meta task ) was completed which resulted in a total quantity of 271 BP Codex pages reviewed, which netted 208 pages to be ignored and 63 pages to be migrated.
The actual count of issues created were:
209 ignore – the extra issue was a duplicate – 209 -1 = 208
58 migrate – there were 5 pages that were included within a single issue – 58 + 5 = 63
For Phase 2 (a.k.a., BP Documentation meta task) the main emphasis is document creation and, if necessary, the updating of documents previously created during Phase 1, as well as Phase 2.
A question was posed (by @emaralive) as to the presentation of statistics for Phase 2; IOW, what should be included? @im4th suggested:
PR created
PR reviewed
PR converted
In an effort to help facilitate the tracking and gathering of metrics for the statistics @emaralive suggested and completed action to archive the 208 ignore issues. This left a total of 71 issues of which 24 issues were completed , by @im4th and @vapvarun, (status of Done) during Phase 1, which left 47 open issues (status of Todo and In Progress) and the % of complete (as of April 10, 2024) to be 34%.
Futhermore, @emaralive created additional views within the project for documentation (although, this appeared to have gone unnoticed):
Although, not explicitly stated, the additional project views could help with the gathering of data in support of the statistics, for example:
Open
Closed
% Complete
Migrate
39
19
33%
Add
6
4
40%
Update
2
1
33%
Total
47
24
34%
Or:
Todo
In Progress
Done
% Complete
Migrate
39
0
19
33%
Add
6
0
4
40%
Update
2
0
1
33%
Total
47
0
24
34%
However, presentation of documentation statistics is still open to discussion, since this topic has not been settled.
Follow-up on BuddyPress Multiblog & BuddyPress Multi Network
A comment was posted regarding BP Docs-Chat Summary March 28, 2024 and the poster’s concern for the deprecation of the BP_ENABLE_MULTIBLOG constant and whether this would affect a plugin the poster was using.. @im4th volunteered to make a reply to the comment and completed the action.
@vapvarun reported his efforts in support of documentation for this area of interest (Multiblog/Multi Network/Multisite):
The availability of screenshots
The availability of 3 dedicated videos
Additionally, @im4th & @vapvarun conversed a bit about the logistics of embedding/including videos within GH (GitHub) documents.
@emaralive suggested and volunteered to update the main README.md for the bp-documentation repo, since Phase 1 has been completed, which makes the content outdated, along with the removal of 2 issue templates (ignore & migrate) that are no longer relevant. This task has yet to be started and @im4th volunteered to review the changes, once a PR has be generated.
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 🕵️♂️.
@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).
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.
BP Team Updates 