Summary for Docs Team Meeting October 26, 2021

Attendance

@kenshino @mkaz @mburridge @juanmaguitar @chaion07 @ashiquzzaman @donaldwmoorejr @muhammadfaizanhaidar @kafleg @atachibana @femkreations @sasiddiqui

Housekeeping

Find the complete Transcript of the meeting on Slack.

Open Floor

5.9 Release (Documentation)

@mkaz will be the Docs Lead for WP 5.9 with help from @audrasjb and @zzap on core docs, and @annezazu for user docs

@femkreations @mburridge offered to help with these docs

Design refresh for Org sites

@mkaz comments the Meta team is working on a design refresh for Org sites starting with /News, see work-in-progress here: https://wordpress.org/news-test/

They are building them as block themes, with the idea of other handbooks would be child themes off them.

Licensing Legal Text

 @chaion07 comments a few weeks back we were discussing on Licensing Legal Text with Josepha to assist us (saw this in the #team-reps channel)

@kenshino says the text is expected to be with the lawyers this week because Gutenberg docs are also on WordPress.org, it makes things slightly more complicated

The main issue is that general contents are CC0 and code is GP, but Gutenberg is also dual-licensed – GPL + MIT, so this info has been passed to the lawyers for them to sort out

#meeting-notes

#docs, #meetings

Summary of Docs Team Meeting Sep 21, 2021

Housekeeping

Project updates

@tacitonic:  The WordPress Documentation Style Guide has been completed. This includes all the remaining articles, the word list, and the usage dictionary.

15 min repo triage:

Issue 1(labeled needs-discussion): Some end-user docs are too technical

@milana_cap: Agrees we shouldn’t have technical details in the end-user docs. But raises the question – where, in DevHub, should that info live?

End-user docs are for people who don’t code and most likely don’t deal with hosting/server issues but rather contact support. We need a place in DevHub that will be dedicated to tasks like .htaccess, internationalization, localization, etc that are shared throughout developing with WordPress. These are neither plugin/theme topics nor common APIs but also are not the end-user concerns. 

She suggests we collect all the articles in the support section that are technical. This will help to get a better picture of the dedicated space we will need to create in DevHub.

@basilh  – Suggests hyperlinks to a dedicated space on wordpress.org for topics related to Apache and Nginx, etc. 

@milana_cap: Agrees to move all such info to another location on wordpress.org. And maybe say something like “For more advanced server settings take a check out this link”

ACTION ITEM: Please add your thoughts in the comments for the issue in GitHub.

Issue 2 (labeled good-first-issue): Update links inside the posts-screen DOC

  • @muhammadfaizanhaidar is unable to recreate the issue and will update in the comments for that issue. 
  • @TC to take a look at the issue, if needed.

Summary for Docs Team Meeting September 14, 2021

Housekeeping

Attendance

@atachibana, @mburridge, @TC , @ashiquzzaman , @femKreations,  @kmhazari , @estelaris , @Basil, @joyously , @danfarrow , @Kenshino (Jon) , @themiked ,

Where: #docs channel on Slack

Find the complete Transcript of the meeting on Slack.

Meeting Facilitator: @TC

Note Taker: @ashiquzzaman

Project Updates

From @atachibana For contents side, all issues in the repository were labeled and active discussions are on going.
Stats: 18 Open / 9 Closed.

Open Floors

estelaris highlighted on using both Google Spreadsheet and GitHub for different issues. Upon discussion it was agreed that we

#meeting-notes

[Announcement] New workflow for reporting documentation issues

For a few weeks now Documentation team is testing out new workflow for reporting issues – a GitHub repository which will be a single, centralised place for reporting all documentation issues. How and why we decided to do this can be found in team’s meeting notes.

What we hope to achieve with this workflow:

  • Easier contribution in form of reporting issues – even though this workflow still requires another account from contributor (the GitHub one), with this workflow contributor doesn’t need to know which part of documentation is issue for. They can just report the issue and move on, if they so wish. We lost many one-time contributions due to the complicated workflow for reporting issues.
  • Easier contribution in form of fixing issues – with all projects and their different reporting issues tools, contributor who wanted to join team and work on fixing issues had to decide which project they wanted to work on before even seeing issues. With everything in one place they can browse all the issues, find the ones that seem interesting and then look for advice on fixing it.
  • Some projects didn’t have any way for reporting issues except for coming to #docs Slack channel and hoping that someone will see it. This way is deprived of a place where the issue would be discussed as many things get lost in Slack noise. Also, this way is almost impossible to keep track of contributors and give them credits for their contributions.
  • Easier managing of projects and documentation in whole – team members have better overview of everything that’s happening in every Docs project, can help out in projects they usually don’t work on and have a general picture of WordPress documentation as a whole.
  • Easier contributions tracking – with every issue, comment, contribution being saved in one place, we have a better understanding of how certain parts of docs were created and who worked on them.
  • Better planning and setting goals with GitHub projects.
  • Better understating and following progress and statistics for each project by structured labeling system.
GitHub issue discussion.
GitHub issue discussion

We are still configuring labels, templates and the repo itself; and still figuring out the best way to work on/with issues. For the future we hope to connect this repository with the actual documentation at WordPress.org so that contributions can be make directly on the page with the issue which would automatically create new issue and apply proper labels.

In the next phase, which will be soon, we will start using GitHub Projects for managing all the issues.

GitHub Project board for managing all GitHub issues from the repository.
GitHub Projects board

Documentation Team is managing all documentation as an unified project and is adopting appropriate tools in order to do so.

As always, if you have any questions or suggestions, please leave the in comments bellow.

Summary of Docs Team Meeting Sep 7, 2021

Housekeeping

Attendance

@TC, @femkreations, @milana_cap, @atachibana, @kenshino, @themiked, @joyously, @estelaris, @kartiks16, @kafleg, @kmhazari 

Where: #docs channel on Slack

Find the complete Transcript of the meeting on Slack.

Meeting Facilitator:  @TC

Note Taker: @femkreations

Next Meeting Facilitators: @kmhazari  and @TC

Project updates

@milana_cap – Work in progress on the P2 post about the doc team’s new workflow that we can share with other teams.

@atachibana – From the content site, processing as many related issues as possible. 

@femkreations: Added labels to the existing issues in the repo.

Handling issues across all documentation

Discussion on adding a dedicated time for repo triage :

by @milana-cap

The easy and straightforward issues don’t need triage but for issues that need discussion and the team’s decision, we could add a label like “discussion” or “needs discussion”.

Based on the number of issues under that label we can plan the meeting time for triage.

@kenshino: The triage is required so we can build the habit and for people to pick up issues.

DECISION: Dedicate 15 mins to triage issues during the weekly doc meetings. Depending on the number of issues we can make changes to the triage time if needed. Keep this in mind when making meeting agendas.

Discussion on adding labels to issues requesting new document/article:

by @milana-cap

This is related to the PR – issue template that’s requesting a new page/article.

@milana-cap has added labels for 5.6, 5.7, 5.8, and 5.9 for releases.

@kenshino: At some point, we should have documentation tied to specific releases.

DECISION: Add “new document” label to the issues requesting new document/article, for now. @femkreations to update the issue template with the label.