Proposed SIG-Docs meeting agenda for 2024-11-20

[ShaunaGordon]

Meeting Details

• Date/Time: Nov 20, 2024 @ 11:30am EDT
• Location: Discord SIG-Docs Voice Room
• Moderator: @ShaunaGordon
• Note Taker: @ShaunaGordon

The SIG-Docs Meetings contains the history past calls, including a link to the agenda, recording, notes, and resources.

SIG Updates

What happened since the last meeting? - The creator of this issue is responsible for providing a brief summary here to be used as an update to start any important discussions.

24.09 release! 🥳

That's the big thing, since it's included some support for the new people, especially since GamesFromScratch picked it up basically immediately.

Open action items

• Joe to get Shauna a repo for the API docs so she can split them out of the main repository

Newly resolved items

• ✅ New docs version released
• ✅ Including new API docs

Suggesting and voting on agenda items

Our community is welcome to suggest and vote on agenda items.

While any community member can suggest an agenda item and is not required to attend meetings or participate in further discussion, we do encourage doing both, so that we can best understand your suggestion. A designated presenter is needed to present the suggestion at the meeting. This defaults to the person making the suggestion. If you will not be attending the meeting, please designate an attendee to present the issue in your stead, and provide them with as much information as possible.

If someone else has already suggested a topic you wanted to suggest, then react to it with a 👍🏼 to show your support for and agreement with the topic.

Community suggestions have considerable weight, as we use them to gauge community priorities and wishes.

Agenda item format

If you leave a comment on this issue to propose an agenda item, please use the following format:

**Topic**: The topic you'll be presenting on
**Presenter**: Who will present (may be a team name or TBD)
**Length of time**: Estimate the amount of time you believe discussion will take. This should not be more than 15 minutes without SIG approval.

Include a description of your topic. Make sure to link to any supplementary materials such as RFCs, forum discussions, issues, etc.

Remember to add the 👍 and 👎 reactions manually, so they appear and are obvious to voters!

[ShaunaGordon]

Topic: Goals for the next year
Presenter: Shauna
Length of time: 15 minutes

I want to talk about overarching goals for the SIG for the coming year that we can use as our "guiding star" for actionable changes, enhancements, and content.

So far, the main theme I've been seeing is improving user/contributor experience, namely through:

• Improving and streamlining user onboarding to the engine
• Improving and streamlining support channels so it's easier for people to get help
• Making the docs site easier to contribute content to
• Streamlining the docs site's content to reduce the number of empty pages/sections and reduce the signal to noise ratio

[ShaunaGordon]

Topic: Revisit Our Branch Process
Presenter: Shauna
Length of Time: 10 minutes

I was thinking a bit about the docs repo and our current process and have a couple of thoughts:

1. I don't think I like cherry-picking main to development or dev to main after a release. It's very difficult to tell what changes need to stay in one vs go to the other, making it difficult to sync again.
2. Do we really need a development branch in its current incarnation? Right now, we're trying to mimic the main repo and do development -> release to main, but does that flow actually work for us? With the main branch mapping to docs.o3de.org, I wonder if the development branch should match the main repo development branch only in the sense of documenting features or behaviors that aren't in the current release version of O3DE, and docs bug fixes and new documentation of features that exist in the release version should go to the main branch by default.

Regarding 2's interaction with 1, I think cherry picks between releases and a rebase at releases might be the cleanest way to go. At release time, main and development should be identical, and then all changes are guaranteed to have been made after the last sync.