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.

Please join us on July 26 at 19:00 UTC (Wednesday) in #BuddyPress, here’s our agenda:

• The first version of the new documentation contribution tutorial via Github had been published by @imath on the previous BP Docs-Chat summary:
  • 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.

#agenda, #contribution, #docs-chat