Proposed RFC Suggestion =Maintaining O3DE Roadmap=

[vincent6767]

Summary

A document that describes the process to maintain O3DE Roadmap. By having an up-to-date O3DE roadmap, the marketing committee, release manager, and the community have visibility to understand what are things the team is currently working on and what will be done in the future.

What is the motivation for this suggestion?

It's important to have an up-to-date O3DE roadmap for the following reasons:

1. There is no easy way for the community to see the O3DE roadmap right now. All they have is a features status grid that doesn't tell what comes next.
2. There is no easy way for the marketing committee to take a look at what comes next and what their key focus is. They need to ask people around and that takes time.
3. There is no easy way to know at a high level what should be written in the release notes. The release manager needs to wait for the SIGs to tag which high-level items are worth being called out in the release notes.
4. We do have an O3DE roadmap, but no one owns and maintains it.

The goal of this proposal is to define processes to keep the O3DE roadmap updated so it provides visibility of what O3DE is doing right now and in the future.

Suggestion design description

Ownership

SIG release is accountable to make sure all processes are in place so the O3DE roadmap is updated.

O3DE Roadmap

Instead of having one global roadmap, each SIG has its own roadmap project board. This is due to there would be a ton of traffic to a global board, and it'd be harder to digest and maintain.

Roles and responsibilities

Here are the roles that involved keeping the O3DE roadmap up-to-date.

1. SIG Chair/Co-chair.
   1. Responsibilities
      1. Responsible to maintain the roadmap and keep the roadmap updated with the latest updates.
      2. SIGs are responsible for understanding all of the contribution channels to their roadmap and reviewing these sources regularly. For example, reviewing any corporate or community roadmaps that may be published, RFCs, and other issues.
2. SIG-Release.
   1. Responsibilities
      1. Responsible to remind SIGs to keep the roadmap updated.
      2. Responsible for continuously reviewing the roadmap maintenance process and improving it.
3. TSC
   1. Responsibilities
      1. To give feedback or ask questions about the roadmap item updates in the TSC monthly meeting.

Processes

Roadmap item

1. Definition
   1. It's an issue that shows in the O3DE public roadmap. The issue communicates the initiative and vision of the SIG.
   2. The roadmap item is an issue labeled as kind/roadmap.
2. Roadmap Item Description
   1. By default, it follows the RFC Features request format like this one (which I believe is the same across all SIGs). The format: https://raw.githubusercontent.com/o3de/sig-release/main/.github/ISSUE_TEMPLATE/roadmap-item.md
   2. Roadmap item example: Network: Support for network versioning to prevent client and server mismatch o3de#13206
   3. It contains tasks (link to GitHub issues) to complete the roadmap item.
3. Responsibility
   1. It's each SIG's responsibility to maintain the status of the item, including closing the issue and adding labels as suggested in (2).

Roadmap Review in TSC monthly meeting

1. Purpose
   1. To provide visibility for TSC and other SIG members for the key roadmap items ahead. Key roadmap items could be items that impact another area of the product or key features.
2. Participants:
   1. SIG chairs (mandatory).
3. Agenda
   1. Each of the SIGs informs others about the key roadmap items ahead as part of their monthly updates. The roadmap should be updated prior to the meeting.
4. When
   1. Every TSC monthly meeting

SIG Roadmap View setup.

1. Purpose:
   1. This is to help readers read and consume the roadmap items easier by organizing the issues in a table structure
2. Each SIG creates a public project board under each SIG's repositories.
   1. Based on the discussion here, it’s the current practice to have everything related to the SIG in each respective repository.
3. The project title follows this template "O3DE - [SIG Name] Project Board". Example: O3DE UI/UX Project Board
4. The board contains a view named "Roadmap View". The view contains all issues with a kind/roadmap label.
5. To reduce redundancy, hide the "Status" column in the project so we can reuse the existing label to communicate statuses.
   1. needs/triage.
   2. triage/accepted - when the issue is accepted and planned to be done in the future.

Add a new template "Add a roadmap Item"

1. Purpose
   1. To increase awareness of the expected information in the roadmap item.
2. Content
   1. The template contains the information explained in the section Roadmap Item - Format.
   2. By default contains labels: needs-triage and needs-sig.
3. Location
   1. The new template is in the O3DE repo.

A Roadmap Page in the Documentation portal

1. Purpose
   1. To show all roadmap boards (including SIGs, O3DE corporate roadmap, etc) on one single page. This is so we have a page that tells the community where the roadmap is located.
2. Ownership
   1. The ownership on SIG-release to make sure it's updated, but it's not necessarily the one that updates the websites.
3. Content
   1. The page contains all roadmap links.
   2. The page contains a disclaimer the roadmap is subject to change as the maintainer considers feedback both from the community and others.
4. Location
   1. The page is located at the o3de.org/docs/roadmap
   2. The page can be accessed from the navigation menu.

Use Cases Flow

Roadmap item creation

1. Contributor (including chairs) creates the roadmap item in the SIG repositories.

Keeping the O3DE Roadmap up to date

1. SIG triage each roadmap item. The triage cadence is up to each SIG.
2. Once the issues are accepted, SIG assigns the label "triage/accepted"
3. Once the issues are completed, SIG to close the issue.
4. Every month each SIG shares its key roadmap with the team in the Joint TSC-SIG meeting as part of their monthly updates. The roadmap should be updated prior to the meeting.

The next O3DE release is about to happen

1. The SIG release queries the completed roadmap items after the last release.

What are the advantages of the suggestion?

1. We have an up-to-date O3DE roadmap for SIGs. This will help give everyone visibility of what's going on right now and what's planned in the future.
2. The process helps SIG release and marketing to query issues that are worth calling out in the release notes.

What are the disadvantages of the suggestion?

1. Require awareness, time commitment, and participation of SIG chairs and co-chairs in order to make sure the O3DE roadmap is updated.
2. There will be another document that needs to be read by the contributor and chairs.

How will this work within the O3DE project?

This document will be recommended reading for all new and existing contributors (including the chairs) to O3DE to help people all get on the same page about the importance and responsibility of maintaining the O3DE roadmap.

Are there any alternatives to this suggestion?

Alternatives that have been considered

1. Use a spreadsheet and have a contributor who is available to help gather updates every X period of time.
   1. This work, but few issues
      1. Spreadsheets can't be searched through Github. This is a concern as our O3DE is managed using Github.
      2. Spreadsheets are loosely coupled with GitHub so it's hard to build awareness that Spreadsheets need to be updated as well.
      3. No clear ownership causes the roadmap left unmaintained.

Impact if we don't implement the suggestions

1. O3DE roadmap is not maintained, which affects the community, release, and marketing activities that require roadmap visibility.
2. No source of truth that shows project visibility on what's next and what's in the progress. This might impact the adoption of the O3DE.

What is the strategy for adoption?

1. Add this document to the contributor guidelines doc (SIGs can recommend reading this in their charters)
2. Send a message to all chairs in each SIG Discord channel to raise awareness and adoption of the responsibilities and the process.
3. Announce the process in the TSC meeting to further increase awareness.
   4 SIG release reminds the chairs and contributors from time to time as we understand the process might take time before it's fully adopted in the contributor workflow.

[lmbr-pip]

As SIG chairs are volunteer positions I am always loathed to add any new significant burdens on their time.

+1 on Roadmap Board in GitHub
I support having a public roadmap in GitHub that SIG chair(s) can add to and maintain, that sounds reasonable and low cost as the number of new features is low. As a SIG chair I would love to have a low cost roadmap for the SIG.

It would probably good to also look for learning opportunities to aid SIG Chair(s) here including any training or sharing of best practices as tribal knowledge grows.

-1 on an all SIG Chair meeting just to cover the roadmap

I do see problems with having another all SIG Chair meeting, we have the board for a reason; it should accurately reflect what SIGs are working on, so having a "verbal readout" seems to be a large demand on time for low value IMHO. If we need really need a meeting, I would propose we use the SIG of SIG meetings for this (as TSC already requested that SIGs provide update of whats been happening at that meeting).

Having to get all the SIG Chairs(s) together in same meeting across multiple time-zones for another meeting, is hard and difficult and we struggle even with the SIG focused TSC meeting.

Quite a few SIGs already have a roadmap focus to their primary SIG meeting, that could be another point of engagement. Or we could do this async where SIGs can provide written roadmap updates to SIG/release every two months.

[vincent6767]

Thanks for the feedback @lmbr-pip !

It would probably good to also look for learning opportunities to aid SIG Chair(s) here including any training or sharing of best practices as tribal knowledge grows.

What kind of training are you thinking of?

I do see problems with having another all SIG Chair meeting, we have the board for a reason; it should accurately reflect what
SIGs are working on, so having a "verbal readout" seems to be a large demand on time for low value IMHO

The reason I put this in place is so we have a mechanism to motivate each SIG to make sure the roadmap is updated. If they don't see the roadmap is used, then there is no reason to update it. Does SIG of SIG meetings talk about the current and future tasks? If yes, then I agree we don't need to have the roadmap meeting. Thoughts?

we could do this async where SIGs can provide written roadmap updates to SIG/release every two months.

We can start this way and evaluates the process in the six months period. But let's have a discussion around the second topic before we decide on this.

[Ulrick28]

The release manager is a temporary position that is created a few months before each release. Instead of assigning duties to the release manager, we should instead assign responsibilities to sig-release. Sig-release then handles how those responsibilities are accomplished. I agree with @lmbr-pip concern with 'yet another meeting'. Maybe we can spend some time discussing the roadmap in the tsc all sigs meeting?

[sptramer]

I do see problems with having another all SIG Chair meeting, we have the board for a reason; it should accurately reflect what SIGs are working on, so having a "verbal readout" seems to be a large demand on time for low value IMHO. If we need really need a meeting, I would propose we use the SIG of SIG meetings for this (as TSC already requested that SIGs provide update of whats been happening at that meeting).

Major 👍 on the roadmap not requiring an all-chairs meeting. Instead it seems like each individual SIG should have a designated person who maintains their part of the roadmap, with some kind of regular update interval. It may work best to have the TSC/TAC review the roadmap on some kind of regular cadence, which also provides clear deadlines and checkpoints for evaluation to ensure the roadmap is aligned with the TSC/TAC direction/priorities for the product.

[vincent6767]

The release manager is a temporary position that is created a few months before each release. Instead of assigning duties to the release manager, we should instead assign responsibilities to sig-release. Sig-release then handles how those responsibilities are accomplished.

Understood. I updated the RFC. Thanks! @Ulrick28

It may work best to have the TSC/TAC review the roadmap on some kind of regular cadence, which also provides clear deadlines and checkpoints for evaluation to ensure the roadmap is aligned with the TSC/TAC direction/priorities for the product.

I agree @sptramer! This provides bigger motivation for the SIG chairs and co-chairs to keep the roadmap updated as it will be evaluated. Few questions

1. Are there any suggestions on the interval?
2. Who should I talk to verify whether this idea works with TSC? Am I only need to bring this up in the Discord TSC Channel?

[jeremyong-az]

Thanks for the proposal! A few thoughts:

• I'm wondering if we should have a roadmap board per SIG instead of trying to maintain a single global board
  • There would be a ton of traffic to a global board, and it'd be harder to digest and maintain
  • SIG-specific boards would let SIGs maintain the board contests independently as part of their normal triage process
• I'm also not sure about the utility of an all-SIG meeting as others here have mentioned. There is already a burden on chairs/co-chairs that are in many cases operating on a volunteer basis

[vincent6767]

Hi @jeremyong-az !

I'm wondering if we should have a roadmap board per SIG instead of trying to maintain a single global board

Makes sense given how the O3DE aspects are structured around SIGs. We can then review the need of having one single view over time. I agree with this one. I'll update the RFC.

I'm also not sure about the utility of an all-SIG meeting as others here have mentioned. There is already a burden on chairs/co-chairs that are in many cases operating on a volunteer basis

Yep understood the pain here. @sptramer suggests having the roadmap reviewed regularly by TSC, which provides the motivation for each SIG to keep the roadmap regularly. Do you have any thoughts about that?

[jeremyong]

That sounds good we can certainly review the roadmap key items as an agenda item on the monthly joint TSC and sig meeting

[vincent6767]

Sorry for the late reply and thanks for your opinion. I'll update the RFC soon! @jeremyong

[vincent6767]

RFC updated with the latest feedback. Highlights.

1. Remove the Roadmap meeting.
2. Add a process that says each SIG updates their key roadmap item in the monthly TSC meeting instead as suggested.
3. Suggest using the notable label for all completed issues to help RM and marketing to create release notes and themes.
4. Add board setup guidelines.
5. Add information on how the community finds the roadmap.

[Kadino]

I'm trying to think of where this can call for more specific action by stakeholders. Right now it appears fairly unspecific on the motivation, requirements, and cadence of different participants. Perhaps the rough ownership outline is appropriate for now, and the details can be left to a case-by-case discussion.

The main requirements owners being considered seems to be SIG-Release and the TSC. I don't see a clear through-llne from how an O3DE customer/contributor would engage with the roadmap information in one of these boards, or to find how to participate on a milestone. Are all the boards going to be summarized somewhere? Will there be a documentation page with a link to all the boards? Even if both are provided, it's a bit unclear how adding the boards addresses public need.

It may be useful to provide a heuristic of what scope of project/milestone gets communicated on this roadmap. Obviously not every GHI in the O3DE or SIG repos should be tracked on these boards, as that would be extremely noisy and low value. Similar to that, why should any feature milestones be tracked which is not "notable" for release notes? And what about impactful bugfixes such as for a crash, which are important in release notes but aren't really a plannable milestone?

Aside: Over in SIG-Testing we transitioned to reviewing RFCs as Pull Requests, which has a better commenting UI than issues.

[vincent6767]

Thanks for contributing to the discussion! @Kadino

I'm trying to think of where this can call for more specific action by stakeholders.

Do you mean it's not clear what each stakeholder of the RFC (Marketing, SIG release, SIG chairs, TSC, and community) needs to do in this RFC? Can you elaborate on what you mean further?

I don't see a clear through-llne from how an O3DE customer/contributor would engage with the roadmap information in one of these boards, or to find how to participate on a milestone. Are all the boards going to be summarized somewhere? Will there be a documentation page with a link to all the boards? Even if both are provided, it's a bit unclear how adding the boards addresses public need.

Thanks for raising this! Agree, this RFC doesn't specifically call out which items to put on the roadmap and addresses the community's needs in terms of visibility. Do you know what the public needs based on your experience so far? I only find this so far in Discord.

Specifically, for the point "Are all the boards going to be summarized somewhere?", in my opinion, yes. That's why I propose to start to put it in the docs community as a start. Do you have other suggestions on where we place the roadmap?

Aside: Over in SIG-Testing we transitioned to reviewing RFCs as Pull Requests, which has a better commenting UI than issues.

This is a good suggestion. I'll use this next time!

[Kadino]

I'm trying to say that the proposal may need to be more specific about who, what, where, and why.

SIG-Testing has had very low exposure to external customers/contributors, which I expect to stay true until after many studios have shipped a game. I feel relatively disconnected to customer need, and would be delighted to have a process which helps surface it.

[tonybalandiuk]

For use cases "Keeping the O3DE Roadmap up to date" I think it is important to clarify what we are asking from SIGs. If we step back and consider all of the contribution channels for this project, they include:

1. O3DE Community members (1 or more working together) - purely volunteers
2. Corporate O3DF-members teams contributing work. - they may (or may not) publish their own roadmaps, for example https://github.com/orgs/o3de/projects/11
3. Corporate Non-O3DF-member teams contributing work. - similar to above, they may optionally publish a roadmap

The change I propose is to Use Cases "Keeping the O3DE Roadmap up to date". I suggest we add a step in the beginning:

1. SIGs are responsible for understanding all of the contribution channels to their roadmap and reviewing these sources regularly. For example, reviewing any corporate or community roadmaps that may be published, RFCs, and other issues.

[vincent6767]

@tonybalandiuk Thanks for the feedback. I will incorporate your feedback in the RFC. Please take a look and review.

Changelog

1. Add another SIG responsibility: "SIGs are responsible for understanding all of the contribution channels to their roadmap and reviewing these sources regularly. For example, reviewing any corporate or community roadmaps that may be published, RFCs, and other issues"
2. Add information on how community members utilize the board in the "GitHub Board Setup"
3. Add a suggestion to add a page containing all links to the roadmap, including the corporate members.

[chanmosq]

I appreciate the further clarity here, and I support this RFC.

sig-docs-community has started a project board. We'll refine the process as we go and with suggestions/best practices from other TSC/SIGs. Currently, our project board contains general issues / initiatives. Specifically for roadmap items, our plan is to set their label or milestone accordingly, and apply a filtered view on the project board that clearly indicates it's for roadmap items.

[tonybalandiuk]

@vincent6767 I suggest "Once the issues are completed, SIG chairs put move the issues into "Done" and assign the label "notable" if the issues are worth calling out in the release notes."

Becomes
"Once the issues are completed, SIG chairs put move the issues into "Done" and assign the label "notable" if the SIG chair considers the issue noteworthy for the marketing committee, who may want to use the issue in blog posts, press release, tweet, etc. "

other than that, the RFC looks great. I think it's good to go.

[vincent6767]

@chanmosq Thanks for sharing your plan in the SIG Docs community! SIG release will also oversee the labeling best practices and post guidelines along the way.

Updated the RFC based on your comment @tonybalandiuk

Other than that, I would like to get anyone's thoughts on the section "A Roadmap Page in the docs portal".

[Kadino]

The ownership of reporting status falling to SIGs seems appropriate. However I'm mildly concerned with mandating specifically how SIG chairs will continually update the status of every issue, which seems to scale poorly for larger SIGs. I recommend keeping mandatory process steps to a minimum.

"Todo" sounds like a default label, and doesn't appear to add useful context versus an unlabeled issue. Any issue not in this state is either not yet cut, or already closed. Propose we ditch it, or at least not mandate its use. (There are already labels for needs-triage and triage/accepted, Todo appears to be described as a duplicate of accepted)

Other than that, I would like to get anyone's thoughts on the section "A Roadmap Page in the docs portal".

Unclear what is suggested by The page also contains to community members that page the roadmap is subject to change as the maintainer considers feedback both from the community and others which may be about including a warning notice? No direct concerns about including a warning.

[tonybalandiuk]

@Kadino from SIG-Release perspective, " SIG chairs will continually update the status of every issue" I think it's fine to instead say "SIG chairs are responsible for updating their roadmaps. The frequency of updates is up to each SIG, but it is recommended that roadmaps be updated in advance of each release to help facilitate the creation of accurate release notes". What do you think?

[vincent6767]

Unclear what is suggested by The page also contains to community members that page the roadmap is subject to change as the maintainer considers feedback both from the community and others which may be about including a warning notice? No direct concerns about including a warning.

Thanks for catching this! It's indeed the warning notice. I'll update the RFC.

[lmbr-pip]

Minor typo: RFC has phrase DIG chairs

SIG Chairs triage each issue regularly.- regularly is ambiguous language, we should set expectations, maybe monthly? If this is to be reviewed in the TSC all SIG monthly meeting, should we have language that you update the roadmap prior to this meeting?

Beyond that it sounds good. Assume RFC should be archived and added as a guide in https://github.com/o3de/community/tree/main/sigs?

[vincent6767]

Discussion about the page that shows all SIGs roadmap continues here: o3de/sig-docs-community#102

We're gearing toward having a dedicated page in the docs and main websites.

[vincent6767]

One of the action item of this RFC is following

Add this document to the contributor guidelines doc (SIGs can recommend reading this in their charters)

I just realized no one commented about this. @tonybalandiuk I wonder if it is a good idea to add roadmap maintenance responsibility as part of each SIG charter. The goal is to officially acknowledge this responsibility.

[tonybalandiuk]

@vincent6767 Good idea. While we need to limit the amount of responsibilities we put on SIGs, this one seems like it's now a basic project requirement. I suspect TSC would be onboard too because of the value this has for the community and end users.

[vincent6767]

Thanks, Tony. I think the next action item is to propose this to TSC and see whether they have any concerns if we create a PR on each charter. I'll do it sometime this week. CC: @tonybalandiuk

[vincent6767]

https://discord.com/channels/805939474655346758/816045972865155082/1089015752213929985
Proposed in the channel. Waiting for TSC's response.

[nick-l-o3de]

fwiw, attempted to bring this up to the TSC All-Sigs meeting but attendance was too poor to broach the topic. I'll try to think of other ways to reliably broadcast this.

[vincent6767]

#79 (comment)
We can close this topic as the SIG Docs and Community published the document that contains maintaining a roadmap as part of the SIG responsibilities: https://github.com/o3de/o3de/wiki/SIG-and-Documentation-Management

That's the last action item for this issue. I'll close this as all action items are completed.

CC: @tonybalandiuk

[Naomi-Wash]

This process has been documented on the wiki: https://github.com/o3de/o3de/wiki/Maintaining-O3DE-Roadmap

[vincent6767]

Thanks for moving it into the wiki @Naomi-Wash !