As discussed and scheduled at the end of the meeting, a minor release was published on August 24 to fix 3 bugs and a security issue. About the security issue we’ve decided to also build minor releases for branches 5.0 to 10.0 and cover 89% of active BuddyPress installs (thanks a lot to @dcavins for his great contributions to this huge packaging task).
12.0.0-beta1 testing results
With @dcavins we’ve noticed @vapvarun did a great job testing this beta release. We were able to fix some issues about the way BuddyPress helps administrators in adding BuddyPress links to their navigation menus using the Menu Admin screen or the Menu Customizer panel.
About the issue @vapvarun raised concerning the fact bbPress wasn’t ready for 12.0 yet, we’ve discussed on the patch @im4th shared on the bbPress trac environment to make the forum extension compatible with BP 12.0. It was a good opportunity to talk about the small changes BP Plugin authors need to include into their plugins to enjoy the coming BP Rewrites API.
@im4th announced he would soon release a new BP Attachments version showcasing these small changes: he’s a bit late on his schedule though (as it’s not yet done when writing these lines 😬).
@im4th & @dcavins shared some worries about the fact this topic did not receive much replies or questions about the important change we’re introducing in 12.0. Building the BP Classic backwards compatibility plugin was definitely the right decision to take.
The tests made by the WordPress Meta team about the BP Classic plugin really helped us improve it (thanks a lot to them 😍).
@im4th will carry on documenting some important changes starting with the new need to register BP Ajax actions when using BP URI globals inside this context.
We finally talked about packaging a beta2, now @dcavins recently improved the community visibility feature to include a filter to redirect the user to the WordPress login screen, it should happen very soon.
Schedule
12.0.0-beta2 : TBD (but soon!),
12.0.0 : October 30.
Next Dev-Chat
It will happen on September 4 at 21:00 UTC in #BuddyPress. If you have specific points or ideas you want to discuss about, don’t hesitate to share them in comments.
BuddyPress 12.0.0-beta1 is not yet available, it will soon be 👌, but as explained into the following post, considering the important change we’re introducing in 12.0.0 about the way BuddyPress builds, parses and analyses URLs from now on, we thought it was a good idea to make this backwards compatibility Add-on directly available from the WordPress plugin directory.
We started to talk about documentation, first to officially introduce @jasonrouet, our new Documentation team leader, to the Core team, then to insist on the fact documenting 12.0.0 changes was very important. We also discussed about how its content inside repository’s /docs directory would be synchronized to a future site of the BuddyPress network.
FYI: BuddyPress Documentation Chat is taking place on Slack on a regular bi-weekly frequency. Everyone is welcome, the discussion is expected to last one hour. If you have any questions, please contact @jasonrouet on Slack.
The current focus is on starting a new Documentation and organising the team effort. Please note that we have a packed agenda this week as this is our first proper meeting, so we won’t have enough time to cover everything and will focus on the codex import and initial actions. Any remaining items will be discussed async or at the next meeting.
First, it has to be properly documented on Github! 🤓
Then, @bouncingsprout suggested expanding it: adding a visual presentation (a flowchart?) highlighting the process from when a documenter logs in to GitHub for the first time, how to fork the repo, work on the forked version and then prepare a PR and then who is reviewing and accepting the PRs.
Additionally, once the website will be ready to host the new documentation: we’ll have to include the steps that lead to the documentation being published from the Github repository to the official website.
Starting the new documentation:
How to import properly the current content from codex.buddypress.org to the Github repo (by properly, I mean checking that the formatting is in Markdown once the content has been imported).
Sorting and ordering the content imported from the Codex: what content is up-to-date, to be updated or out of date/to be removed?
Once the old content is sorted and ordered, we’ll have to think about the structure and start producing new content/update content imported from the codex.
Documentation coordination and workflow:
Who will approve the PRs on Github besides BP core committers? Could the Documentation team lead have sufficient permissions? Can we plan a quick training?
How to coordinate with the core team about new releases: tracking changes, addition… Case study: version 12.0.0 is about to be officially released, how to track changes and document it?
How do we want the new Documentation to be friendly for end-users and also for developers?
Also, how will the Documentation be split between the use and developer subdomains?
How will one Documentation communicate to the other on specific topics?
What will be the process for choosing which documentation should be prioritised? (This should maybe be a recurring item of our Doc-Chat meeting?)
Language quality check: how can we ensure that the documentation is written in proper English? Is en-US the default language localisation?
Misc
Is our workflow similar to that of the WP Documentation Team? If we are creating docs differently, how and why? How can we learn from what our colleagues in this team are doing? Is it a good idea to move towards the same workflow? (@bouncingsprout offers to be the link to the WP docs team, to try and get some best practice and their guidance?)
What would be a reasonable plan for retiring the current Codex and publishing the new Documentation? No rush, but a deadline (even a vague one) might help to keep us motivated.
We don’t have cookies (yet), but let’s have a friendly and efficient meeting! See you tomorrow 🤗
Props to @bouncingsprout and @im4th for adding their ideas and for reviewing this post.
BuddyPress Docs are primarily directly available from the main BuddyPress SVN repository. We’ve created a docs directory which contains 2 sub-directories: 1 for the « developer » documentation & the other for the « user » one.
BuddyPress GitHub repository
As each commit on our SVN repository is synced with our GitHub repository, documentation is also available there and we’ll be able to enjoy GitHub browsing service to improve the reading experience.
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.
How to contribute to BuddyPress Docs?
The first steps a contributor needs to accomplish once are (everything remains totally free):
Create a new branch (from the command line or directly from GitHub website)
Write in Markdown the documentation resource inside the user or developer docs sub-directory (using a text editor or directly from GitHub website) & commit locally the changes.
From the created branch, pull a request to the BuddyPress repository to merge the changes (from the command line or directly from GitHub website).
Update the branch if a BP Team member asks for changes after their review.
Once a Pull Request is validated by a member of the BuddyPress team, a BP Core Committer will include the changes to the BuddyPress SVN repository so that they will be synchronized with the BuddyPress GitHub repository (It’s very important PR are not merged from the BuddyPress GitHub repository). At this point, contributors will need to synchronize the main branch of their fork (master) with the BuddyPress GitHub repository. This synchronization can be achieved before building a new contribution (Step 1 of the above list).
Who are the first members of the Documentation team?
During the chat, @bouncingsprout and @im4th (both developers) shared the same intuition: it’s best to have a Documentation leader that is not a developer. Developers are always attracted by code & we need to put the focus on end-users instead. @im4th also shared what he thinks are important tasks the Documentation leader needs to accomplish:
Lead the BP docs-chat
Fix priorities
Review contributions (PR)
Everything the leader thinks is important to do!
@jasonrouet seemed the best candidate of us 3 to lead the Documentation team. If he felt a bit « trapped » at the beginning, he finally volunteered for the role & @bouncingsprout also did so as a deputy.
@dcavins & @im4th from the development team will also contribute to docs and all code contributors are invited to do so. Contributing to docs is a good way to improve code, for instance @im4th lately opened/patched a few tickets after writing some documentation contributions (See #8932 & #8933).
Support contributors are also strongly encouraged to contribute to docs and attend Docs Chats.
More globally every BP user is very welcome to give a hand, as @jasonrouet said: completely reorganizing the BP Documentation is a huge challenge & we’ll need more motivated people around to progress quickly.
We’ll start us 4 because we absolutely need to improve Documentation and prepare the important change about URL Parsing we’re introducing in BuddyPress 12.0. We are confident new contributors will be attracted by the first improvements we’ll add ourselves.
As @jasonrouet suggested, once there will be more contributors to docs, we’ll be able to share leading tasks between several volunteers.
When do we meet & how regularly?
Here’s @jasonrouet first decision! BuddyPress docs-chat will happen every other Wednesdays at 19:00 UTC.
Next Docs-Chat
It will happen on July 26 at 19:00 UTC in #BuddyPress. If you have specific points or ideas you want to discuss about, don’t hesitate to share them in comments.
It’s been almost a month we last met to talk about BuddyPress. To get ready for our next meeting (tomorrow), let’s remember what was the topics we discussed about.
Documentation
The /docs directory was created inside our code repository, some resources were already added to it and a docs-chat took place last week (a summary will soon be published).
During June 19’s development chat, @dcavins confirmed he thinks the new community visibility feature (turning a full BP Community to private) was very doable in 12.0.0. Community administrators would be able to activate it from a unique option at first, and we’ll make it more granular in future versions of BuddyPress so it will be configurable for each component.
Documentation is very important, we all agree about it: it’s about time to act concretely, again!
An important change about how BuddyPress parses URL requests is right around the corner: BuddyPress 12.0.0-beta1 is slated to July 30. We absolutely need to provide informations about it to end-users and developers.
Documenting BuddyPress is a huge job and we really need a lot more hands and energy to satisfy end-users and developers needs.
We’ve already tried to raise your attention about helping us on documentation in February 2022. Today I’m renewing this call to documentation contributors hoping it will be more successful than last year’s one (no new contributors showed up 😭).
BP Dev Updates 