From 1632e292f9f9d98382ef94edaf4e80a966072c19 Mon Sep 17 00:00:00 2001 From: Nepiki <76693803+Nepiki@users.noreply.github.com> Date: Mon, 9 Jun 2025 13:39:11 +0200 Subject: [PATCH 01/22] Expanded Rollout Process This PR merges in the discussion between myself and the Rollout team, ensuring that the Rollout process is described in completeness for full transparency to the developers. --- docs/developer-docs/rollouts.md | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 5b662416..7ce12ef9 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -19,7 +19,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - Maintaining a schedule so developers know when they are to officially claim their picks in the forum, when playtesters can start testing sets, and when the console's support will officially launch. - Ensuring the console ID is validated on the website when support launches, or at least be in contact with the web team to do so. -- Developers are limited to leading one set at a time, but may collaborate on as many sets as they wish. Upon completion of a set, they are to notify QA to look over their set and sign them off, which allows them to move on to their next pick, if applicable. +- Developers are limited to leading one set at a time, but may collaborate on one other set at a time as long as it's not their primary claim. Claims must be signed off by the rollout and writing team, with collaboration claims requiring all parts to be finished before it can be signed off. Another claim may be requested after sign-off. - Rollout claims are subject to [Special Claims](/guidelines/developers/claims-system#special-claims) rules. @@ -29,8 +29,21 @@ It's worth noting that these are general guidelines that apply to all rollouts. ## Rollout Process -- When a previously unsupported console becomes viable to work on achievements, developers are to be asked individually if they would like to participate in a console's rollout. If they are interested, they are to pick one game as their priority pick, but may provide a list of additional games as backup. -- The overall list is then sorted to see if there are any overlapping picks. If a priority pick is exclusive to one developer, they can be locked in for that pick. If multiple developers share the same priority pick, they will be encouraged to collaborate. +- **Step 1: Proposal for New Integrations** - The RAdmin team researches available cores or gets into contact with standalone emulator developers. Likewise, emulator developers can reach out to RAdmin via on-site messaging to propose support for their emulator or core. This proposal will be evaluated by the admin team, who will guide the developer(s) into building integration with RetroAchievements within their emulator if the proposal is accepted. +- **Step 2: Build Achievement Support** - Integration developers build achievement support into their emulator, including hashing support for any new systems. This process can be months or years long. +- **Step 3: Integration Testing** - The rollout team tests the new support for any issues and provides feedback to the integration developers. A public test may also be opened during this step to allow all developers to test. +- **Step 4: Rollout Selection** - Once the rollout and admin team are satisfied with the integration, developers are contacted privately by the rollout team about their interest in joining. The developer will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: + - 1: Developers who have participated in the previous rollout and release their set(s) on time, and (new) developers who have never participated in any rollout prior. + - 2: Developers who did not participate in the last rollout, but were involved with other rollouts. + - 3: Developers who participated in the last rollout but suffered a large amount of tickets or potential set demotion, and developers who released their rollout set long beyond the end date. + - 4: Developers who have at least one open ticket with no work done on it for over a month. +- **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Do note that developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. +- **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. +- **Step 7: Set Development** - Developers start working on the claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the rollout team. If a priority pick was not provided to the rollout team during step 4, developers may now reach out to the rollout team to request a set to work on. +- **Step 8: Sign Off** - Developers submit their finished claims for review by the writing team and rollout team. Sets are checked to ensure they adhere to the Content Guidelines standards. Do note that collabs can be signed off only once every collaborator has finished their part. +- **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join in on another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. +- **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and Events Team are contacted so that they can make their own preparations related to the rollout. +- **Step 11: Launch Day** - The new system is released and developers promote their sets, or admins will promote it for them if they are unavailable. Players may now play sets featuring the new system! Do note that for developers, the sign off period will persist for a month after launch day, meaning that sets will still need to be checked by both the writing- and rollout teams. ## Previous Rollouts From 05783102cda62917f500108d163d9864e80c2f44 Mon Sep 17 00:00:00 2001 From: Nepiki <76693803+Nepiki@users.noreply.github.com> Date: Mon, 9 Jun 2025 14:49:27 +0200 Subject: [PATCH 02/22] Small Rollout Process updates Add a few small updates: - Clarify for priority 3 in claim picking that it involves the last rollout they participated in, not just the last rollout. - Clarify that writers need to be pinged first for sign-off, and they will ping the rollout team. - Added a line to general guidelines that Rollout team may decide remediation measures based on problematic action. --- docs/developer-docs/rollouts.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 7ce12ef9..1b692e75 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -27,6 +27,8 @@ It's worth noting that these are general guidelines that apply to all rollouts. - Since the overall goal of a rollout is to provide sets to launch with a console's support, developers who go inactive or otherwise end up not working on the chosen sets will have their claim lapsed. In other words, claiming a set just to sit on it will not fly and will result in a lapse. +- If problematic action is witnessed during a rollout, such as refusing co-operation with the involved teams or causing issues for fellow developers, the rollout team has the right to decide if any remediation measures are necessary. Such examples include gaining lower priority for claim selection during the next rollout, or being removed from claims during the ongoing rollout. + ## Rollout Process - **Step 1: Proposal for New Integrations** - The RAdmin team researches available cores or gets into contact with standalone emulator developers. Likewise, emulator developers can reach out to RAdmin via on-site messaging to propose support for their emulator or core. This proposal will be evaluated by the admin team, who will guide the developer(s) into building integration with RetroAchievements within their emulator if the proposal is accepted. @@ -35,12 +37,12 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 4: Rollout Selection** - Once the rollout and admin team are satisfied with the integration, developers are contacted privately by the rollout team about their interest in joining. The developer will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: - 1: Developers who have participated in the previous rollout and release their set(s) on time, and (new) developers who have never participated in any rollout prior. - 2: Developers who did not participate in the last rollout, but were involved with other rollouts. - - 3: Developers who participated in the last rollout but suffered a large amount of tickets or potential set demotion, and developers who released their rollout set long beyond the end date. + - 3: Developers who, in the last rollout they participated in, suffered a large amount of tickets or potential set demotion, or released their rollout set long beyond the end date. - 4: Developers who have at least one open ticket with no work done on it for over a month. - **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Do note that developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. - **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. - **Step 7: Set Development** - Developers start working on the claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the rollout team. If a priority pick was not provided to the rollout team during step 4, developers may now reach out to the rollout team to request a set to work on. -- **Step 8: Sign Off** - Developers submit their finished claims for review by the writing team and rollout team. Sets are checked to ensure they adhere to the Content Guidelines standards. Do note that collabs can be signed off only once every collaborator has finished their part. +- **Step 8: Sign Off** - Developers submit their finished claims for review by pinging the writing team for initial check, who will then ping the rollout team. Sets are checked to ensure they adhere to the Content Guidelines standards. Do note that collabs can be signed off only once every collaborator has finished their part. - **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join in on another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. - **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and Events Team are contacted so that they can make their own preparations related to the rollout. - **Step 11: Launch Day** - The new system is released and developers promote their sets, or admins will promote it for them if they are unavailable. Players may now play sets featuring the new system! Do note that for developers, the sign off period will persist for a month after launch day, meaning that sets will still need to be checked by both the writing- and rollout teams. From c3f41839844b3c13f806599a2c00f78cde62b6d9 Mon Sep 17 00:00:00 2001 From: Nepiki <76693803+Nepiki@users.noreply.github.com> Date: Mon, 9 Jun 2025 15:51:08 +0200 Subject: [PATCH 03/22] Small addendum to priority level 3 --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 1b692e75..20e521d4 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -37,7 +37,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 4: Rollout Selection** - Once the rollout and admin team are satisfied with the integration, developers are contacted privately by the rollout team about their interest in joining. The developer will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: - 1: Developers who have participated in the previous rollout and release their set(s) on time, and (new) developers who have never participated in any rollout prior. - 2: Developers who did not participate in the last rollout, but were involved with other rollouts. - - 3: Developers who, in the last rollout they participated in, suffered a large amount of tickets or potential set demotion, or released their rollout set long beyond the end date. + - 3: Developers who, in the last rollout they participated in, suffered a large amount of tickets or potential set demotion, or released their rollout set long beyond the end date. This priority level will be judged on a case-by-case basis. - 4: Developers who have at least one open ticket with no work done on it for over a month. - **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Do note that developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. - **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. From 1ba9c826ae752305fd91cfcaee40f425abcfc200 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 18:57:28 -0400 Subject: [PATCH 04/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 20e521d4..eef97dc5 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -39,7 +39,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - 2: Developers who did not participate in the last rollout, but were involved with other rollouts. - 3: Developers who, in the last rollout they participated in, suffered a large amount of tickets or potential set demotion, or released their rollout set long beyond the end date. This priority level will be judged on a case-by-case basis. - 4: Developers who have at least one open ticket with no work done on it for over a month. -- **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Do note that developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. +- **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. - **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. - **Step 7: Set Development** - Developers start working on the claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the rollout team. If a priority pick was not provided to the rollout team during step 4, developers may now reach out to the rollout team to request a set to work on. - **Step 8: Sign Off** - Developers submit their finished claims for review by pinging the writing team for initial check, who will then ping the rollout team. Sets are checked to ensure they adhere to the Content Guidelines standards. Do note that collabs can be signed off only once every collaborator has finished their part. From e13b5251ee18bb6dd3c04d7a7b411e9e142aefe0 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 18:57:31 -0400 Subject: [PATCH 05/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index eef97dc5..666573ba 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -42,7 +42,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. - **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. - **Step 7: Set Development** - Developers start working on the claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the rollout team. If a priority pick was not provided to the rollout team during step 4, developers may now reach out to the rollout team to request a set to work on. -- **Step 8: Sign Off** - Developers submit their finished claims for review by pinging the writing team for initial check, who will then ping the rollout team. Sets are checked to ensure they adhere to the Content Guidelines standards. Do note that collabs can be signed off only once every collaborator has finished their part. +- **Step 8: Sign Off** - Developers submit their finished claims for review by pinging the writing team for initial check, who will then ping the rollout team. Sets are checked to ensure they adhere to the Content Guidelines standards. Note: collabs can be signed off only once every collaborator has finished their part. - **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join in on another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. - **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and Events Team are contacted so that they can make their own preparations related to the rollout. - **Step 11: Launch Day** - The new system is released and developers promote their sets, or admins will promote it for them if they are unavailable. Players may now play sets featuring the new system! Do note that for developers, the sign off period will persist for a month after launch day, meaning that sets will still need to be checked by both the writing- and rollout teams. From 5e39e03b57d2868bd5fb2d88ae4234311101af11 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 18:57:35 -0400 Subject: [PATCH 06/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 666573ba..b5b73776 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -45,7 +45,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 8: Sign Off** - Developers submit their finished claims for review by pinging the writing team for initial check, who will then ping the rollout team. Sets are checked to ensure they adhere to the Content Guidelines standards. Note: collabs can be signed off only once every collaborator has finished their part. - **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join in on another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. - **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and Events Team are contacted so that they can make their own preparations related to the rollout. -- **Step 11: Launch Day** - The new system is released and developers promote their sets, or admins will promote it for them if they are unavailable. Players may now play sets featuring the new system! Do note that for developers, the sign off period will persist for a month after launch day, meaning that sets will still need to be checked by both the writing- and rollout teams. +- **Step 11: Launch Day** - The new system is released and developers promote their sets, or admins will promote it for them if they are unavailable. Players may now play sets featuring the new system! Note: for developers, the sign off period will persist for a month after launch day, meaning that sets will still need to be checked by both the writing- and rollout teams. ## Previous Rollouts From 3e4088f9bd21fca56a65bfaef2f22b4c65c47851 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:14:40 -0400 Subject: [PATCH 07/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index b5b73776..e8cdeefc 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -19,7 +19,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - Maintaining a schedule so developers know when they are to officially claim their picks in the forum, when playtesters can start testing sets, and when the console's support will officially launch. - Ensuring the console ID is validated on the website when support launches, or at least be in contact with the web team to do so. -- Developers are limited to leading one set at a time, but may collaborate on one other set at a time as long as it's not their primary claim. Claims must be signed off by the rollout and writing team, with collaboration claims requiring all parts to be finished before it can be signed off. Another claim may be requested after sign-off. +- Developers are limited to leading one set at a time, but may collaborate on one other set at a time as long as it's not their primary claim. Claims must be signed off by the Rollout and Writing teams, with collaboration claims requiring all parts to be finished before they can be signed off. Another claim may be requested after sign-off. - Rollout claims are subject to [Special Claims](/guidelines/developers/claims-system#special-claims) rules. From 4b12fa0c717dfe64ffac8521394b96939628298b Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:14:45 -0400 Subject: [PATCH 08/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index e8cdeefc..677b50cf 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -27,7 +27,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - Since the overall goal of a rollout is to provide sets to launch with a console's support, developers who go inactive or otherwise end up not working on the chosen sets will have their claim lapsed. In other words, claiming a set just to sit on it will not fly and will result in a lapse. -- If problematic action is witnessed during a rollout, such as refusing co-operation with the involved teams or causing issues for fellow developers, the rollout team has the right to decide if any remediation measures are necessary. Such examples include gaining lower priority for claim selection during the next rollout, or being removed from claims during the ongoing rollout. +- If problematic behavior occurs during a rollout, such as refusing cooperation with the involved teams or causing issues for fellow developers, the Rollout Team may implement remediation measures. These may include lowering priority for claim selection in future rollouts, or removing claims during the current rollout. ## Rollout Process From 406c20cc0ba8e65c889d1666ea604325154f56f5 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:14:50 -0400 Subject: [PATCH 09/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 677b50cf..e30227c1 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -31,7 +31,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. ## Rollout Process -- **Step 1: Proposal for New Integrations** - The RAdmin team researches available cores or gets into contact with standalone emulator developers. Likewise, emulator developers can reach out to RAdmin via on-site messaging to propose support for their emulator or core. This proposal will be evaluated by the admin team, who will guide the developer(s) into building integration with RetroAchievements within their emulator if the proposal is accepted. +- **Step 1: Proposal for New Integrations** - The admin team researches available cores or gets into contact with standalone emulator developers. Likewise, emulator developers can reach out to RAdmin via on-site messaging to propose support for their emulator or core. This proposal will be evaluated by the admin team, who will guide the developer(s) into building integration with RetroAchievements within their emulator if the proposal is accepted. - **Step 2: Build Achievement Support** - Integration developers build achievement support into their emulator, including hashing support for any new systems. This process can be months or years long. - **Step 3: Integration Testing** - The rollout team tests the new support for any issues and provides feedback to the integration developers. A public test may also be opened during this step to allow all developers to test. - **Step 4: Rollout Selection** - Once the rollout and admin team are satisfied with the integration, developers are contacted privately by the rollout team about their interest in joining. The developer will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: From 895cc515425070ebb32916460cb08ad39ed9f8c7 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:14:54 -0400 Subject: [PATCH 10/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index e30227c1..b193f09e 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -32,7 +32,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. ## Rollout Process - **Step 1: Proposal for New Integrations** - The admin team researches available cores or gets into contact with standalone emulator developers. Likewise, emulator developers can reach out to RAdmin via on-site messaging to propose support for their emulator or core. This proposal will be evaluated by the admin team, who will guide the developer(s) into building integration with RetroAchievements within their emulator if the proposal is accepted. -- **Step 2: Build Achievement Support** - Integration developers build achievement support into their emulator, including hashing support for any new systems. This process can be months or years long. +- **Step 2: Build Achievement Support** - Integration developers build achievement support into their emulator, including hashing support for any new systems. This process can take months or even years. - **Step 3: Integration Testing** - The rollout team tests the new support for any issues and provides feedback to the integration developers. A public test may also be opened during this step to allow all developers to test. - **Step 4: Rollout Selection** - Once the rollout and admin team are satisfied with the integration, developers are contacted privately by the rollout team about their interest in joining. The developer will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: - 1: Developers who have participated in the previous rollout and release their set(s) on time, and (new) developers who have never participated in any rollout prior. From 8df91c52dadfae6810edbe8f4b3dc3577dcda421 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:00 -0400 Subject: [PATCH 11/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index b193f09e..ff30c0e2 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -33,7 +33,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 1: Proposal for New Integrations** - The admin team researches available cores or gets into contact with standalone emulator developers. Likewise, emulator developers can reach out to RAdmin via on-site messaging to propose support for their emulator or core. This proposal will be evaluated by the admin team, who will guide the developer(s) into building integration with RetroAchievements within their emulator if the proposal is accepted. - **Step 2: Build Achievement Support** - Integration developers build achievement support into their emulator, including hashing support for any new systems. This process can take months or even years. -- **Step 3: Integration Testing** - The rollout team tests the new support for any issues and provides feedback to the integration developers. A public test may also be opened during this step to allow all developers to test. +- **Step 3: Integration Testing** - The Rollout Team tests the new support for any issues and provides feedback to the integration developers. A public test may also occur during this step to solicit feedback from all achievement developers. - **Step 4: Rollout Selection** - Once the rollout and admin team are satisfied with the integration, developers are contacted privately by the rollout team about their interest in joining. The developer will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: - 1: Developers who have participated in the previous rollout and release their set(s) on time, and (new) developers who have never participated in any rollout prior. - 2: Developers who did not participate in the last rollout, but were involved with other rollouts. From a913206b171bb173074b7bbaf3f0456731981f01 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:08 -0400 Subject: [PATCH 12/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index ff30c0e2..d62e217a 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -34,7 +34,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 1: Proposal for New Integrations** - The admin team researches available cores or gets into contact with standalone emulator developers. Likewise, emulator developers can reach out to RAdmin via on-site messaging to propose support for their emulator or core. This proposal will be evaluated by the admin team, who will guide the developer(s) into building integration with RetroAchievements within their emulator if the proposal is accepted. - **Step 2: Build Achievement Support** - Integration developers build achievement support into their emulator, including hashing support for any new systems. This process can take months or even years. - **Step 3: Integration Testing** - The Rollout Team tests the new support for any issues and provides feedback to the integration developers. A public test may also occur during this step to solicit feedback from all achievement developers. -- **Step 4: Rollout Selection** - Once the rollout and admin team are satisfied with the integration, developers are contacted privately by the rollout team about their interest in joining. The developer will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: +- **Step 4: Rollout Selection** - Once the Rollout team and RAdmin are satisfied with the integration, developers are contacted privately by the Rollout Team about their interest in joining. Developers will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: - 1: Developers who have participated in the previous rollout and release their set(s) on time, and (new) developers who have never participated in any rollout prior. - 2: Developers who did not participate in the last rollout, but were involved with other rollouts. - 3: Developers who, in the last rollout they participated in, suffered a large amount of tickets or potential set demotion, or released their rollout set long beyond the end date. This priority level will be judged on a case-by-case basis. From 5a4661f2966869d683ee82d247589cb4f0a79e90 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:12 -0400 Subject: [PATCH 13/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index d62e217a..9a8f7a9d 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -41,7 +41,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - 4: Developers who have at least one open ticket with no work done on it for over a month. - **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. - **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. -- **Step 7: Set Development** - Developers start working on the claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the rollout team. If a priority pick was not provided to the rollout team during step 4, developers may now reach out to the rollout team to request a set to work on. +- **Step 7: Set Development** - Developers start working on their claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the Rollout Team. If a priority pick was not provided to the Rollout Team during Step 4, developers may now reach out to the Rollout Team to request a set to work on. - **Step 8: Sign Off** - Developers submit their finished claims for review by pinging the writing team for initial check, who will then ping the rollout team. Sets are checked to ensure they adhere to the Content Guidelines standards. Note: collabs can be signed off only once every collaborator has finished their part. - **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join in on another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. - **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and Events Team are contacted so that they can make their own preparations related to the rollout. From 824b9992a5148fd8c513a3ab6345d3039d90c9b7 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:17 -0400 Subject: [PATCH 14/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 9a8f7a9d..0419e7bd 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -42,7 +42,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. - **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. - **Step 7: Set Development** - Developers start working on their claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the Rollout Team. If a priority pick was not provided to the Rollout Team during Step 4, developers may now reach out to the Rollout Team to request a set to work on. -- **Step 8: Sign Off** - Developers submit their finished claims for review by pinging the writing team for initial check, who will then ping the rollout team. Sets are checked to ensure they adhere to the Content Guidelines standards. Note: collabs can be signed off only once every collaborator has finished their part. +- **Step 8: Sign-Off** - Developers submit their finished claims for review by pinging the Writing Team for an initial check, who will then ping the Rollout Team. Sets are checked to ensure they adhere to the [Content Guidelines standards](/guidelines/content/writing-policy). Note: collabs can be signed off only after every collaborator has finished their part. - **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join in on another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. - **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and Events Team are contacted so that they can make their own preparations related to the rollout. - **Step 11: Launch Day** - The new system is released and developers promote their sets, or admins will promote it for them if they are unavailable. Players may now play sets featuring the new system! Note: for developers, the sign off period will persist for a month after launch day, meaning that sets will still need to be checked by both the writing- and rollout teams. From 31a7aea0f1373f588861e649af4a48a4a37fdde7 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:21 -0400 Subject: [PATCH 15/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 0419e7bd..48f8ffb4 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -43,7 +43,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. - **Step 7: Set Development** - Developers start working on their claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the Rollout Team. If a priority pick was not provided to the Rollout Team during Step 4, developers may now reach out to the Rollout Team to request a set to work on. - **Step 8: Sign-Off** - Developers submit their finished claims for review by pinging the Writing Team for an initial check, who will then ping the Rollout Team. Sets are checked to ensure they adhere to the [Content Guidelines standards](/guidelines/content/writing-policy). Note: collabs can be signed off only after every collaborator has finished their part. -- **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join in on another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. +- **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. - **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and Events Team are contacted so that they can make their own preparations related to the rollout. - **Step 11: Launch Day** - The new system is released and developers promote their sets, or admins will promote it for them if they are unavailable. Players may now play sets featuring the new system! Note: for developers, the sign off period will persist for a month after launch day, meaning that sets will still need to be checked by both the writing- and rollout teams. From 81f63ff10a8421bedeb951a946761e882c4aecad Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:26 -0400 Subject: [PATCH 16/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 48f8ffb4..f781d523 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -44,7 +44,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 7: Set Development** - Developers start working on their claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the Rollout Team. If a priority pick was not provided to the Rollout Team during Step 4, developers may now reach out to the Rollout Team to request a set to work on. - **Step 8: Sign-Off** - Developers submit their finished claims for review by pinging the Writing Team for an initial check, who will then ping the Rollout Team. Sets are checked to ensure they adhere to the [Content Guidelines standards](/guidelines/content/writing-policy). Note: collabs can be signed off only after every collaborator has finished their part. - **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. -- **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and Events Team are contacted so that they can make their own preparations related to the rollout. +- **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and the Events Team are contacted so they can make their own preparations related to the rollout. - **Step 11: Launch Day** - The new system is released and developers promote their sets, or admins will promote it for them if they are unavailable. Players may now play sets featuring the new system! Note: for developers, the sign off period will persist for a month after launch day, meaning that sets will still need to be checked by both the writing- and rollout teams. ## Previous Rollouts From f83ea03746e433208dde12cd56eb8d4883ef7b28 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:30 -0400 Subject: [PATCH 17/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index f781d523..32a13ccb 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -45,7 +45,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 8: Sign-Off** - Developers submit their finished claims for review by pinging the Writing Team for an initial check, who will then ping the Rollout Team. Sets are checked to ensure they adhere to the [Content Guidelines standards](/guidelines/content/writing-policy). Note: collabs can be signed off only after every collaborator has finished their part. - **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time. - **Step 10: Launch Preparation** - Once the rollout is nearing completion, other teams such as RANews and the Events Team are contacted so they can make their own preparations related to the rollout. -- **Step 11: Launch Day** - The new system is released and developers promote their sets, or admins will promote it for them if they are unavailable. Players may now play sets featuring the new system! Note: for developers, the sign off period will persist for a month after launch day, meaning that sets will still need to be checked by both the writing- and rollout teams. +- **Step 11: Launch Day** - The new system is released and developers promote their sets, or RAdmin will promote the new sets if the developers are unavailable. Players may now play sets featuring the new system! Note: for developers, the sign-off period will persist for a month after launch day, meaning that sets will still need to be checked by both the Writing and Rollout teams. ## Previous Rollouts From 576cb227a10c6c15ca2136f0f474a257b95b960c Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:39 -0400 Subject: [PATCH 18/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 32a13ccb..2688cd67 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -35,7 +35,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 2: Build Achievement Support** - Integration developers build achievement support into their emulator, including hashing support for any new systems. This process can take months or even years. - **Step 3: Integration Testing** - The Rollout Team tests the new support for any issues and provides feedback to the integration developers. A public test may also occur during this step to solicit feedback from all achievement developers. - **Step 4: Rollout Selection** - Once the Rollout team and RAdmin are satisfied with the integration, developers are contacted privately by the Rollout Team about their interest in joining. Developers will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: - - 1: Developers who have participated in the previous rollout and release their set(s) on time, and (new) developers who have never participated in any rollout prior. + - 1: Developers who have participated in the previous rollout and released their set(s) on time, and (new) developers who have never participated in any rollout prior. - 2: Developers who did not participate in the last rollout, but were involved with other rollouts. - 3: Developers who, in the last rollout they participated in, suffered a large amount of tickets or potential set demotion, or released their rollout set long beyond the end date. This priority level will be judged on a case-by-case basis. - 4: Developers who have at least one open ticket with no work done on it for over a month. From a527bd63187df11d0eff309e6b0b49c374050702 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:45 -0400 Subject: [PATCH 19/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 2688cd67..8a96ea7f 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -36,7 +36,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 3: Integration Testing** - The Rollout Team tests the new support for any issues and provides feedback to the integration developers. A public test may also occur during this step to solicit feedback from all achievement developers. - **Step 4: Rollout Selection** - Once the Rollout team and RAdmin are satisfied with the integration, developers are contacted privately by the Rollout Team about their interest in joining. Developers will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: - 1: Developers who have participated in the previous rollout and released their set(s) on time, and (new) developers who have never participated in any rollout prior. - - 2: Developers who did not participate in the last rollout, but were involved with other rollouts. + - 2: Developers who did not participate in the previous rollout, but were involved with other rollouts. - 3: Developers who, in the last rollout they participated in, suffered a large amount of tickets or potential set demotion, or released their rollout set long beyond the end date. This priority level will be judged on a case-by-case basis. - 4: Developers who have at least one open ticket with no work done on it for over a month. - **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. From 2f87c593d8cd92c46466a8354470ee6e83ad4f2d Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:51 -0400 Subject: [PATCH 20/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 8a96ea7f..68158714 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -37,7 +37,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - **Step 4: Rollout Selection** - Once the Rollout team and RAdmin are satisfied with the integration, developers are contacted privately by the Rollout Team about their interest in joining. Developers will then provide their priority pick, optional back-up picks, or no picks at all. When all selections are gathered, all developer names are put in a lottery and selected by priority, which goes as follows: - 1: Developers who have participated in the previous rollout and released their set(s) on time, and (new) developers who have never participated in any rollout prior. - 2: Developers who did not participate in the previous rollout, but were involved with other rollouts. - - 3: Developers who, in the last rollout they participated in, suffered a large amount of tickets or potential set demotion, or released their rollout set long beyond the end date. This priority level will be judged on a case-by-case basis. + - 3: Developers who, in the previous rollout they participated in, received a large number of tickets or potential set demotion, or released their rollout set long beyond the rollout's end date. This priority level will be judged on a case-by-case basis. - 4: Developers who have at least one open ticket with no work done on it for over a month. - **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. - **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. From a48b9ac3589a8c9324b274872f5b6cc27c9f5f28 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:15:58 -0400 Subject: [PATCH 21/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index 68158714..e9b237b5 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -39,7 +39,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - 2: Developers who did not participate in the previous rollout, but were involved with other rollouts. - 3: Developers who, in the previous rollout they participated in, received a large number of tickets or potential set demotion, or released their rollout set long beyond the rollout's end date. This priority level will be judged on a case-by-case basis. - 4: Developers who have at least one open ticket with no work done on it for over a month. -- **Step 5: Selection Planning** - The rollout team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are only allowed to have one priority claim, be it a set they are working on solo or collaborating, but are allowed to join in on another developer's primary claim if they are looking for collaboration partners, one at a time. +- **Step 5: Selection Planning** - The Rollout Team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are limited to one priority claim (either solo or collaborative), but may join another developer's primary claim if they are looking for collaboration partners, one at a time. - **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. - **Step 7: Set Development** - Developers start working on their claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the Rollout Team. If a priority pick was not provided to the Rollout Team during Step 4, developers may now reach out to the Rollout Team to request a set to work on. - **Step 8: Sign-Off** - Developers submit their finished claims for review by pinging the Writing Team for an initial check, who will then ping the Rollout Team. Sets are checked to ensure they adhere to the [Content Guidelines standards](/guidelines/content/writing-policy). Note: collabs can be signed off only after every collaborator has finished their part. From d8a3c130446a4443ab84593c362af84bf2d34583 Mon Sep 17 00:00:00 2001 From: Wes Copeland Date: Mon, 9 Jun 2025 19:16:04 -0400 Subject: [PATCH 22/22] Update docs/developer-docs/rollouts.md --- docs/developer-docs/rollouts.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/developer-docs/rollouts.md b/docs/developer-docs/rollouts.md index e9b237b5..6d8e0e56 100644 --- a/docs/developer-docs/rollouts.md +++ b/docs/developer-docs/rollouts.md @@ -40,7 +40,7 @@ It's worth noting that these are general guidelines that apply to all rollouts. - 3: Developers who, in the previous rollout they participated in, received a large number of tickets or potential set demotion, or released their rollout set long beyond the rollout's end date. This priority level will be judged on a case-by-case basis. - 4: Developers who have at least one open ticket with no work done on it for over a month. - **Step 5: Selection Planning** - The Rollout Team will evaluate the selections. If a game has multiple priority picks, the team will work with the interested developers to encourage a collaboration. Note: developers are limited to one priority claim (either solo or collaborative), but may join another developer's primary claim if they are looking for collaboration partners, one at a time. -- **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. The RAdmin team will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The rollout team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be a true release date of the emulator support, but if unexpected issues arise, then it may possibly be extended. If this happens, the developers will be informed well in advance. +- **Step 6: Lock In** - Developers are informed if their priority picks are confirmed. RAdmin will add hashes for confirmed games and developers may initiate a claim. Claims will become a Free Rollout special claim for the duration of the rollout. The Rollout Team will communicate the end date of the rollout to the developers upfront for planning. This end date is intended to be the **actual release date** of the new system's/emulator's support, but if unexpected issues arise, this release date may be extended. If this happens, developers will be informed well in advance. - **Step 7: Set Development** - Developers start working on their claims. Developers are expected to actively work on their claims during this time, with check-in dates being communicated by the Rollout Team. If a priority pick was not provided to the Rollout Team during Step 4, developers may now reach out to the Rollout Team to request a set to work on. - **Step 8: Sign-Off** - Developers submit their finished claims for review by pinging the Writing Team for an initial check, who will then ping the Rollout Team. Sets are checked to ensure they adhere to the [Content Guidelines standards](/guidelines/content/writing-policy). Note: collabs can be signed off only after every collaborator has finished their part. - **Step 9: Additional Claims** - Developers may make a new claim once their initial claim is signed-off, or join another collab once the collaboration has been signed-off. Only one primary claim and one non-primary collaboration claim may be made at a time.