Attendance:
@crstauf, @chaion07 , @tacitonic , @justinahinon , @atachibana , @estelaris , @bph , @kmhazari, @stefanocassone , @engramium, @mkaz, @collinsmbaka, @milana_cap, @tomjn, @paaljoachim, @clorith, @annezazu, @kenshino, @themiked , @joyously, @ashiquzzaman,
Housekeeping:
Where: #docs channel on Slack.
Find the complete Transcript of the meeting on Slack.
When: Monday, April 19, 2021, 14:00 UTC
Meeting Facilitator: @ashiquzzaman
Meeting Note Taker: @kmhazari
Note Reviewer: @ashiquzzaman
Next Meeting: Monday, April 26, 2021, 14:00 UTC
Project Updates:
From @bph, Block-Editor End-user documentation –
- Getting ready for the 5.8 release.
- Need volunteers to help with prep and writing.
- She will create a post for the team blog to outline a plan proposal
- This week she will check back with contributors work in progress and Need changes cards in Trello and see if there are blockers.
- A Few 5.5, 5.6, and 5.7 residues to finish.
- Please read the post by Josepha the final scope for 5.8 for the block editor
From @tacitonic, No substantial updates for the Style Guide, 21/28 articles have been completed in the Word list.
From @tjnowell, VVV project regarding contributor day –
- He’s liaising with @paaljoachim and @macgraphic to improve some core docs
- VVV installation docs were heavily simplified over the weekend and uninstall instructions added, documenting these in handbooks is no longer necessary, a link will do
- Adding a new site was overhauled with basic Trunk/Meta env instructions
- Changing instructions from installing to
vagrant-localtovvv-localinstead, lots of people think VVV and Vagrant are the same thing which is confusing, this should avoid some of that. Some .org docs will need updating
Team goals updates:
From @tacitonic,
For the Style Guide:
Priority: Completing the last remaining section.
Challenge: Parser inconsistencies.
Big Win: Style Guide was published.
From @justinahinon,
Restructuring of the block editor handbook:
Priority (for next quarter): Continue iterating on the current documentation
Challenge: The fact that the doc is synced on GitHub and parsed sometimes leads to challenges (redirections, syncing errors, live updates, etc..)
Big Win: The initial restructuring plan was completed.
From @atachibana, Content team completed the hooks and classes migration.
From @paaljoachim,
As soon as the Code block is fixed in Learn. He plans to publish
Setting up a local WordPress Development Environment for Core and Testing a Trac ticket or a Github PR.
He plans to create a Learn tutorial for VVV/Vagrant when he and Tom are finished with the VVV/Vagrant docs.
New Member Mentoring:
We have 16 members joining the #docs team since March 29, 2021. Please welcome the following Contributors
@knutsp, @Kim-Agape3.com, @greduan, @dirgha, @Dulé, @sebastienserre, @Meghaa, @Tyler Baldwin, @Gaston Rubiolo, @Amit Dudhat, @Arnold W. K.@Vince, @Sahil Mepani, @igdeman, @Chris Bell and @itowhid06
We have a Mentoring Team consisting of a few contributors in the #docs Team. One of the members from the Mentoring Team might reach out to you to assist you with your inquiries on contributing to the team. Thank you!
Google Season of Docs:
Update from @justinahinon, doc team applications have not been accepted for this year’s Season of Docs. He added some details and next steps to move forward as a short update on this post.
Unified Doc License page:
From @kenshino,
For the Unified Doc License page, he’s written a draft here. The doc team can use the text as written to make clear out intentions. The next 2 steps for this are sending the text to @chanthaboune so she can get the lawyers to review
Adding a link to the licensing page on the documentation page footers (or some other appropriate unified mechanism)
If there’s anything anyone like to add or comment, now is the time.
Author attribution to docs:
From @kenshino,
For Author attribution. The doc team should start recording and showing results. The team can start with DevHub (HelpHub has forums installed on the /support site so it’s a more complicated setup and should be tackled after some testing).
Recommended plugin – authorship, Beyond the ability to denote multiple authors, it also has the ability to do so via CLI (not just UI), so in the ideal case (with some custom dev) we can integrate that with the RESTPlain setup so Gutenberg, official function/hook docs when synchronized from Git / SVN can attribute authors via CLI. There’s obviously more to talk about and this is likely a project in itself.
April Coffee Break:
Due to both @chaion07 and @Sunday Ukafia not being available for the past few weeks. The coffee break for March wasn’t commenced, they will write a P2 ask for hosts if interested in April.
Process gap between dev notes release stage:
@clorith requests the doc team to make it ready before dev notes, dev notes usually land around the Release Candidate, which only gives 2-3 weeks. Even if screenshots may need updating near the end, the concepts should land before RC, when the merge deadline is met. This is to help the support team to make support easier for them.
@estelaris raised the issue to Josepha but haven’t got an update yet.
@mkaz also agreed, getting features being released in a major version should be documented to coincide with the release, there are numerous tickets open to address.
Open Floor/Q&A:
From @mkaz, A short update for block editor handbook discussion, looks like consensus the “block editor” name covers all editors since they all are block editors. So next steps are to build out a good landing page with FSE docs with a focus on what is going out in WP 5.8 as decided here.
@estelaris stated it’s best to continue the discussion about this topic and post a P2 explaining the gap and any solutions the doc team suggests. She also commented on the issue with @Matt said he is willing to support the work of the docs team (on the HelpHub front). She stated the doc team need to raise the importance of end-user documentation, within the release squad, there is never a plan for writing end-user documentation
@milana_cap thinks, one of the ways could be having lists explaining new features in bullets after which the doc team can go and ask more questions if needed deeper explanation. But what the doc can’t know and would need for sure is what the feature is about, why is it important, what problem it solves.
@clorith mentioned, as soon as a feature proposal is accepted, work is started on the features that are already marked as “final”. Then once the merge deadline hits, start documenting the concepts and how the feature works in broader terms. This means once you reach RC, all that should be missing is screenshots and maybe a few adjustments for labels, and the documents can be published.
By publishing at the same time as RC goes live, Dev can help both the Doc and Support team, since they can get familiar with the material, but also users who are willing to test the RC can find information on the features, to know what is there that they can test
@bph agrees that the release team only considered Dev Notes, not end-user documentation. The docs team is fairly new and still doesn’t have enough people around to scale up the operation. With her work on Gutenberg Times, she’s in a unique position to keep up-to-date on the development and learn early when features arrive and how to get a task list going.
With the help of @geheren the team has a good system in place. What’s missing are the contributors to update existing pages, write the new pages, and are proficient enough in the new features to guide the users on exploring the new features. Most contributors who are new to the feature need guides themselves unless they have a certain curiosity and explore each feature deeper.
@geheren and @bph will review all the changes from the plugin (Gutenberg 9.9 – 10.7) release notes to see how the existing page needs updates. Update the Trello cards of existing pages and also review the template page editor and the new blocks to determine an outline