1. I prefer GitHub discussions for easy indexing and browsing compared to email, due to the volume that I experience of the latter.
2. No opinion as I rarely submit PRs. For PRs related to SIG governance, it seems fine.
3. RFC process - I agree that it is more heavily biased towards synchronous conversations to async ones. I think we are still also experiencing some places where it is not clear whether the scope of change/proposal necessitates an RFC, but that the process itself generally is satisfactory.

1. I prefer Github discussions, my mailbox is already pretty stacked and its hard to separate discussions properly.
2. So far so good. I tend to forget to sign-off my commits, but that's all.
3. No opinion here other than that the synchronization points will sooner or later really make everything crawl, given that we only have so much discussion time.

Personal views (have added as a discussion item for next SIG-Network meeting to get official SIG response, if thats required).

1. I think GitHub discussions are easier and more open than email. Puts users in charge and you have more control over the content you want to follow.

2. PR process is mostly working. However, I do not see extensive use of drafts for early engagement, I do see inconsistencies esp on testing (either in description or unit/integration test changes that come with changes), makes it very hard to see whats actually been tested. I also see very few references to RFC in large changes which makes it hard to go back and find technical details. New process of ensuring PRs are assigned to SIGs seems to be working great.

3. RFCs: We should have a central notification point for each SIG and across O3DE for RFCs as it all seems very siloed inside a SIG. Concern that SIGs are all following their own path for archiving, which is going to be confusing in the future (no consistent naming etc). Do not have clear guidance to ensure that cross SIG RFCs are accepted by all impacted SIGs. We are also not archiving the RFCS centrally (no use of o3de/rfcs) which is confusing, we either use this repo or we drop it.

2. PR process is pretty good when AR works and the PR is medium to long. Unfortunately AR still has seemingly random failures which can be quite frustrating, and sometimes fails for reasons that are hard to call blocking (saw someone's AR fail not too long ago because a piece of the code had tabs instead of spaces, we really shouldn't be blocking submission and forcing engineers to re-run AR for something like this). On the review side, I would still love a bypass button for tiny changes like fixing typos in comments and tweaking default values etc, there's no reason for engineers to have to randomize two other engineers and run AR if they're just updating a comment or making some extremely trivial change.
   No strong feelings about 1. or 3.

I asked the TSC (because of concerns raised by others external to this thrad) to get some guidance on RFC archiving and how we should utilize o3de/rfcs at the 12/7 meeting. Unfortunately TSC did not have time to discuss so has moved to next meeting (ETA 12/14).

Have concerns also around low engagement around RFCs in SIG. Many do not attract comment or discussion. Unsure if low engagement is part of the start-up process, or if we are missing learnings from other open-source communities.

1. I prefer to keep everything in GitHub. Things to improve:

• its hard to filter the questions/ideas/etc that need feedback. I would suggest to create some labels to track what was already addressed (e.g. if it is an idea maybe label it as "accepted").
• be more aggressive on marking things as "solved". If they are not really solved, the author can comment and the tag removed. I find myself re-reading and going through the same questions over and over. Most of the times the author just didnt reply which likely indicates that they are not running into the issue anymore.

2. PR is satisfactory. Things to improve:

• would like a bot to trigger dco check (sometimes dco doesnt trigger, like when the base branch is changed)
• would like a bot to trigger jenkins (currently have to go and find the job in jenkins)
• would like more cleanup on PRs. Some PRs take a long time to go through or get closed. We need to increase the amount of active reviewers and establish rules on how long a PR can stay open without feedback from the author. I would like to see an auto-close if the author has not addressed feedback after X amount of time.

3. No comments yet, I need to go through it a couple of times to give some feedback.

1. For non-realtime communication (i.e. not Discord), what is your preferred medium of communication and why? (between Github discussions and email lists)

• I would prefer to keep everything in GitHub. It makes it much easier to know what is the source of truth and where to go looking for things.
• It would be great to take advantage of GitHub features such as Discussions as well as Issues to spark conversations and discuss changes/improvements.

2. Do you find the PR process to be satisfactory? Are there things you would like to see changed?

• I think it's pretty good on the whole, but I'd definitely be in favour of reviewers being much stricter about tests. All contributors should be thinking about tests and making sure coverage is added for as many things as possible. The coverage doesn't have to be exhaustive but it's super important to have something that ensures the feature you've added won't break if someone else touches it.
  • The mentality should be if contributor A changes some code, and it inadvertently breaks contributor B's feature/system, it is contributor B's fault for not having a test in place to catch the breakage, not contributor A.
  • This of course would need some flexibility (especially for legacy systems) but that will help encourage tests for PRs as a matter of course. We should all be doing this to set a good example that this is the standard we want.

3. Do you find the RFC process to be satisfactory? Are there things you would like to see changed?

• To be brutally honest right now it seems like a box ticking exercise, as there just isn't enough engagement with the RFCs themselves. They often get posted, sit there for a while, and then development on them starts as no one has voiced opposition (reminds me a little of the Hitchhikers Guide to the Galaxy demolition notice 😉). We likely should persevere with them, they do have a place, but right now it doesn't feel like they're having the intended effect.