diff --git a/docs/developer-docs/am-i-ready-for-review.md b/docs/developer-docs/am-i-ready-for-review.md index 7ba60643..92e035db 100644 --- a/docs/developer-docs/am-i-ready-for-review.md +++ b/docs/developer-docs/am-i-ready-for-review.md @@ -4,21 +4,49 @@ description: Comprehensive guidelines for the Junior Developer Program, includin --- # Am I Ready for Code Review? +Now that your set is shaping up, you feel it's getting closer to publication. A couple things are left to do, namely testing, debugging and adjusting things to avoid bad practices and improve your set. -[[toc]] +Tips for testing: +- If you aren’t skilled enough to do the challenge, you can test individual pieces by creating dummy achievements for pieces of them, such as level completion, starting the challenge, taking damage. Often times you can freeze invincibility frames or other things to help test too. +- Always make sure that your achievement can pop, and always make sure your failure conditions (ResetIf, Pauselocks, etc) only happen when you expect. +- Try to approach your challenges and achievements from wrong directions and goofy actions. Players do all kinds of weird things. Maybe a player does something in a different order than usual. Maybe they shoot something you didn’t realize could be shot and the achievement fails unexpectedly. In short: **Try to break your achievements.** +- Test your Rich Presence in all game contexts (menus, title, in-game, in different game modes, early game, late game) to see if it ever displays something odd. + +# Requesting a Review -Now that you have submitted your set for review (or perhaps you are still trying to decide if you are ready to do so), you may be wondering what you can do while waiting or while deciding. +Before you request a review on your set, it must be clear of bad practices. In particular, you must use [AutoCR](https://authorblues.github.io/retroachievements/AutoCR/) and go through every issue it flags. As with any automatic feedback tool, it is not perfect, and flags can sometimes be ignored. It is still invaluable to identify issues with your set, especially while you are still learning. In your Ready for Review post on #jr-devs-request, you must: +- Have had the claim for at least 7 days +- Explain your testing process +- Link to the Unpublished achievement page for your game +- Link to the AutoCR page for the set (using the Load by Game ID feature) +- Explain why any issue flagged by AutoCR has been ignored + +Review requests deemed incomplete will simply be denied and you will have to make another one later. Take your time to get your set as close to publishable as you can before making that request; there's no rush! Don't hesitate to ask for help from your fellow juniors and code reviewers. Below is a list of absolute requirements before getting on the backlog: -Go through this list and check all your conditions to make sure you are doing these best practices and avoiding these common mistakes. Please do all of this while you are waiting for your review to be picked up (or before submitting), making any changes necessary. That way when your review is picked up, you’ll have far fewer issues to resolve and your review will be quicker. +[[toc]] -Does this seem like a lot? Well, most developers are going to be doing these things as they develop achievements, or before they promote their set to core. Tackle each part one at a time and go through it slowly. Feel free to ask us questions in `#jr-devs` about any of the topics if you have trouble with them. +## The set is clear from bad practices in logic +Everything below should be **avoided**. If you need to make an exception, explain why. +- Achievements without a Delta-Mem pair +- Achievements using only a single address (even if it uses it for multiple conditions) +- Having a hit count target of (1) or higher without a way to reset hits +- Using ResetIf or PauseIf for negation instead of managing hits +- Using text based addresses in general +- Using addresses without code notes +- Comparing an address with a value not described in the corresponding code note +- Redundant AndNext +- Redundant Alt groups +- Using a Pauselock without a way to reset it + +## Code notes are clear and concise -## Use the `#jr-devs-requests` +Read over the [Code Notes](/guidelines/content/code-notes) guidelines and ensure you are following all the advice. -- All interaction with your set creation, approval, and maintenance should be handled by yourself or through Code-Reviewers through the forum. -- Non-Code Reviewer developers may not demote/promote your work or resolve tickets for you. +- Check that you have a size tag on every note +- Check that every note has specific values noted, where appropriate +- Make sure *all* addresses used in achievements and leaderboards have a code note -## Check your titles and descriptions for good formatting and grammar. +## Assets have clear descriptions and unique titles with proper grammar Read over the [Writing Policy](/guidelines/content/writing-policy) and be sure your titles, descriptions, and other written features are in compliance. @@ -26,159 +54,31 @@ Read over the [Writing Policy](/guidelines/content/writing-policy) and be sure y Are grammar and capitalization not your strong suit? Having trouble coming up with a concise description? Hop by the `#writing-requests` on discord and have them look over your achievements while you await your review. They’ll be happy to help you out. ::: -## Do you have badges? - -- Your achievements will need badges before it is added to the queue.. -- They should not be temporary badges. - -## Do you have good code notes? - -Read over the [Code Notes](/guidelines/content/code-notes) guidelines and ensure you are following all the advice. - -- Check that you have sizes and specific values noted (where appropriate). -- Make sure all addresses used in achievements and leaderboards have a code note. - -## Have you set up the order of your achievements? - -- Under the Dev dropdown on the game page, select Unofficial Achievements, then from there select Manage Unofficial Achievements from the Dev dropdown. You can set up the order there. -- Having achievements in the desired order often helps reviewers look through your achievements more quickly, and also helps us better see the strengths of your set design. - -## What Hubs does your game belong in? - -There are a variety of Genre, Subgenre, Publisher, Developer, Series, Language, and other metadata hubs that can be linked to the set. Think about which ones belong. - -- A code reviewer can add them for you. Your Publisher, Developer, and Genre entries should match the hub names, so make any edits to match the hubs now. -- Be prepared to discuss any other possible hubs during your review. +## Achievements have unique badges -## Does your set have Rich Presence? +- Badges cannot be temporary before getting into the backlog +- [The use of image generators is prohibited](https://docs.retroachievements.org/guidelines/content/badge-and-icon-guidelines.html#ai-generated-art-policy) -**If it does not**, add some! We expect Junior Developers to get experience with Rich Presence from their first set. +## The set has an appropriate Rich Presence - Read the [Rich Presence ](/developer-docs/rich-presence) document to learn more. - [Condition Syntax](/developer-docs/condition-syntax.html) will also be of help. +- It's a good opportunity to learn to use macros and conditionals. -### Does it have both lookup macros and conditionals? - -- If not, you will want to use at least one of each to gain basic RP skills. -- Macros are used to turn address values into text based on the value of an address and are the basic building block of good dynamic RP. -- Conditionals are used to display different kinds of RP display strings based on game context. - - The most simple is for when a user is on the title screen; you can use a conditional to display this; usually in-game data is invalid when on the title screen and can make it look odd. - - If a game has multiple gameplay modes, you might want to display completely different data per mode. Conditionals let you do this. - -### Have you tested your Rich Presence? - -Make sure you test it under all game contexts (menus, title, in-game, in different game modes, early game, late game) to see if it ever displays something odd. - -## Do any of your conditions use one single address (or even one total condition)? - -Having a single address can make your achievement prone to false triggers, especially if an emulator initializes memory oddly, or if the memory has some flicker. As a result, we want to avoid overly simple logic. - -- **Always** have more than one condition. Find a valid game state to pair with logic, such as “In game” or “player has control” You want to make sure the player is actually at a point where the other conditions are valid. -- If you have more than one condition, but only one address is being used, be wary of _"on to off"_ transitions. `Delta < X` followed by `Mem >= X` is effectively going from "on to off" with X being treated as the threshold. - - Find some other conditions to add to it to make these kinds of things more robust and ensure the player is actually in a good game state when they happen. - -## Are you using Stored Hits (Sometimes called Target Hits)? Do you have a way to Reset those stored hits? - -### What Stored Hits Are and Are Not - -**Stored hits are**: when you specify a specific amount of hits on a condition (or chain) and the condition is not considered true until that target amount of hits has been reached. - -**Stored hits are not**: the rolling number of hits in the achievement editor that show up on conditions without a target. Those are for tracking how many frames a condition has ever been true and are purely informative. - -- Stored hits must always have a way to be reset, such as when a challenge is failed, when a player is no longer on the relevant level, or the player suffers a game over. Otherwise these hits may stick around and cause a false trigger in the wrong context. -- **Solution**: Add a condition or chain of conditions (such as with And Next) marked with the Reset If flag. When the condition(s) are true, the stored hits will be cleared. - -### Are you using the stored hits to help check when a value changes from one thing to another thing? - -This is a thing you see on old sets from when the toolkit was smaller. This is almost always the wrong way to do this. +## Achievements are ordered logically -- **Solution**: Use the Delta flag! - - Delta represents the value of an address on the previous frame. - - You can pair `Delta address = Value originalValue` in one condition, and `Mem address = Value newValue` in the next condition and that will catch the very moment the address changes from _originalValue_ to _newValue._ - - See also: [Do I Really Need to Use Delta?](/developer-docs/why-delta) +- Under the Manage tab, you can set up the order through drag and drop or manually writing values. +- This is an important part of set presentation. Grouping things up thematically or chronologically makes it much more readable for players. +- Having achievements in the desired order also helps reviewers look through your achievements more quickly, and also helps us better see the strengths of your set design. -### Are you using stored hits because you have several conditions you want to be true at the same time in order to trigger the achievement? +## Progression achievements and Win Conditions are properly idenfitied -- The extra stored hits can lead to false triggers if one of them were to become untrue, leading to tickets. -- All conditions being true at the same time is the default behavior of the achievement logic. -- **Solution**: Remove any target hits unless you absolutely need to remember that something happened previously (before the current or previous frame). +- Achievements for beating a game are marked as Win Condition. +- Achievements that must be earned before earning any Win Condition are marked as Progression -## Are You Using Reset If? Should You? +## Achievements are save protected or password protected -Reset If is used to clear all stored (target) hits. It is not needed and should not be used if you are not using hits. Reset If flags can affect emulator performance and so we don't want to have _"Unneeded Usage of Reset If."_ - -- Using Reset If when you do not have stored (target) makes it harder for the CR team to know if you understand how hits and resets are used. -- If you do not have target hits, you must not use Reset If flags. - - Reset If in this case is used as a "stop the achievement from happening if this condition is met" check, but what you want is the equivalent "allow the achievement to happen if the opposite condition is true." - - **Solution**: Change `Reset If Mem address = Value X` into `Mem address != X`. This is equivalent logic and will work the same way. - - Other comparisons can be inverted similarly. > becomes <=, etc. - - Do this always as a best practice. Avoid unneeded Reset If flags! -- If you do have target hits, check to make sure you **are** using Resets to clear them under appropriate conditions. - -## Are you using a Pause If condition where the Pause If condition has no target hits? - -Pause If is only used to stop target hits in other conditions from increasing. Pause If can affect emulator performance and so we don’t want to have _"Unneeded Usage of Pause If."_ - -### Do you have any other conditions with target hits? - -- Using Pause If when you do not have stored (target) hits in other conditions makes it harder for the CR team to know if you understand how hits and resets are used. -- If you do not have target hits, you must not use Pause If flags. - - Pause If in this case is used as a "stop the achievement from happening if this condition is met" check, but what you want is the equivalent "allow the achievement to happen if the opposite condition is true." - - **Solution**: Change `Pause If Mem address = Value X` into `Mem address != X`. This is equivalent logic and will work the same way. - - Other comparisons can be inverted similarly. > becomes <=, etc. - - Do this always as a best practice. Avoid unneeded Pause If flags. -- If you do have target hits, check to make sure that your Pause If conditions are being used to prevent stored hits from increasing. - -### Is the Pause If part of a block of protection logic used in all your achievements? - -You may be using Pause If in one of the following types of protection: save protection, cheat protection, demo protection, etc. - -- If some of the achievements do need the Pause If conditions to prevent hits from increasing, then it is okay to leave them in all achievements, for consistency ease of maintenance. - - If you do need to make a change, it can be applied consistently to all achievements. - - However, it is a good idea to consider removing the Pause If flags from achievements where they are not necessary, especially if the set suffers from performance issues in emulation. -- If no achievements use stored (target) hits, then you'll want to remove the Pause If flags. - - **Solution**: Change `Pause If Mem address = Value X` into `Mem address != X`. This is equivalent logic and will work the same way. - - Other comparisons can be inverted similarly. > becomes <=, etc. -- If it is not part of a protection block, refer to the earlier parts of this section. - -## Are you using a Pause Lock? - -### What is a Pause Lock? - -A Pause Lock is a condition (or chain of conditions) where the Pause If line has a target amount of hits. When this hit value is locked, the group (Core, Alt1, etc) will no longer increase any target hits and will never be true until the hits on the Pause If line are reset. - -### Do you have a way to Reset the Pause Lock? - -1. Yes, I am Resetting it using a Reset If in the same group (Core, Alt1, etc) - - Unfortunately this will not reset your pause lock. Pause If has a higher priority than Reset If, so the Reset If will never function while the group is locked. - - Solution A: Move your Reset If condition(s) to an Alt group. If you have no alt groups, you can create a single alt (delete the extra second alt) and put it in there. That alt will always be true while your reset condition is unmet, so the achievement can still trigger as normal. - - Solution B: Put a Reset Next If condition (or chain of conditions) immediately before your Pause Lock condition (or chain of conditions that ends in a Pause Lock). Reset Next If has a higher priority than the condition (or chain of conditions) and will reset that specific pause lock. - - Bonus Information: Reset Next If can also reset the hits in other kinds of chains, so you can reset only some hits, but not others. -2. Yes, I do have a way to Reset it, either with a Reset in another group (Core, Alt1, etc) or a Reset Next If before the Pause Lock. - - Great! Make sure you’ve tested that it resets at the appropriate time. -3. No, I do not have a way to Reset the Pause Lock. - - Uh oh! If you don’t reset the pause lock, the achievement will forever be unable to be earned unless the user resets the game using the console’s reset or unless they reload the game. That’s almost always bad, so we want to make sure we have a logical time to reset an achievement’s pause lock. This might simply be on game over, or dying and restarting a level, or on the title screen. - - Solution A: Put a Reset If condition (or chain of condition) in an Alt group. If you have no alt groups, you can create a single alt (delete the extra second alt) and put it in there. That alt will always be true while your reset condition is unmet, so the achievement can still trigger as normal. - - Solution B: Put a Reset Next If condition (or chain of conditions) immediately before your Pause Lock condition (or chain of conditions that ends in a Pause Lock). Reset Next If has a higher priority than the condition (or chain of conditions) and will reset that specific pause lock. - -## Have you looked for cheat codes and blocked them from being used? - -In most cases, cheat codes provide a benefit that makes achievements easier. And then are you really achieving anything? - -- Add code to your achievements to block the use of cheat codes if you are not already doing so. -- Sometimes a cheat code such as a level select makes sense to allow, especially for challenges. Examples: "Beat Level 3 without taking damage." Level select should generally be blocked for progression achievements where the game expects a normal playthrough to start at the beginning. - -## Do you have achievements for entering a cheat code? - -Strongly consider removing them by putting [VOID] at the start of their title. These almost always are poor designs for achievements and your code reviewer will suggest the same. - -- Exceptions: a cheat code that causes a cool effect. - - In these cases, you’ll want to have an achievement trigger off of the cool effect that happens during gameplay and not from entering the code itself. - - There’s a game boy batman game with a cheat code that causes Robin to appear in boss fights to heal you. A cool achievement was made for Robin doing this. - -## Does your game have save files or passwords? Make sure there's protection! - -- If so, have you tested that loading a save file (especially an end game save file) or loading from a password does not trigger any achievements? +Test that loading a save file (especially an end game save file) or loading from a password does not trigger any achievements. 1. Load up the game, then activate all achievements. 2. Load your save file or enter your password. 3. Does anything trigger? @@ -189,23 +89,19 @@ Strongly consider removing them by putting [VOID] at the start of their title. T - If not, do so now. - If it does not work with all save slots, you will need to revise your logic so that it does so. Usually there is at least an "active save slot" address, and often the active save data gets copied to a common location. Either case should be handled. - If the system uses a save on a memory card, have you tested that your logic works if the player has no memory card "inserted" in the emulator? +Note: This **does not** mean that achievements have to disallow passwords. It just means that achievements cannot be earned as a result of entering a password, which would happen if an achievement only checks that you are on a given stage, for example. -## Do any conditions in your achievements rely on text being a specific value? - -If yes, it is strongly recommended you find an alternative. Text can be fickle, and often varies between versions and hashes. It also almost always makes adding translation patch support impossible. +## Achievements are protected against cheats when appropriate -## Are there any achievement ideas that you didn't include due to not knowing how to implement them? +In most cases, cheat codes provide a benefit that makes achievements easier. And then are you really achieving anything? -- Take your improved skills with the toolkit and familiarity with the game and consider adding them to your set if it's appropriate. -- It’s alright if you do not publish them to Unofficial, but bring them up during your review if you are still having trouble and we will be happy to help you realize your ideas. +- Add logic to your achievements to block the use of cheat codes if you are not already doing so. +- Sometimes a cheat code such as a level select makes sense to allow, especially for challenges. Examples: "Beat Level 3 without taking damage." Level select should generally be blocked for progression achievements where the game expects a normal playthrough to start at the beginning. -## Have you tested all your achievements? +## Games have appropriate hubs and meta information -Always make sure your achievements can pop! +There are a variety of Genre, Subgenre, Publisher, Developer, Series, Language, and other metadata hubs that can be linked to the set. Think about which ones belong. -- If you aren’t skilled enough to do the challenge, you can test individual pieces by creating dummy achievements for pieces of them, such as level completion, starting the challenge, taking damage. - - Often times you can freeze invincibility frames or other things to help test too -- Always make sure your failure conditions (Reset If, Pause Locks, etc) only happen when you expect. -- Try to approach your challenges and achievements from wrong directions and goofy actions. Players do all kinds of weird things. Maybe a player does something in a different order than usual. Maybe they shoot something you didn’t realize could be shot and the achievement fails unexpectedly. - - Basically: **Try to break your achievements.** -- Until your set is released, it is good to pick a few achievements a day and test them again. The more you test, the less issues there will be when the set goes live. +- A code reviewer can add them for you. Your Publisher, Developer, and Genre entries should match the hub names, so make any edits to match the hubs now. +- Be prepared to discuss any other possible hubs during your review. +- Add every known Release in the Manage tab. diff --git a/docs/developer-docs/jr-dev-rules.md b/docs/developer-docs/jr-dev-rules.md index 9d158638..ba0cb212 100644 --- a/docs/developer-docs/jr-dev-rules.md +++ b/docs/developer-docs/jr-dev-rules.md @@ -9,7 +9,9 @@ description: Comprehensive guidelines for the Junior Developer Program, includin ## Overview -The purpose of the Junior Developer Program is to assist interested people with learning how to create and maintain high quality achievement sets for RetroAchievements. Junior Developers are required to understand and abide by the [Developer Code of Conduct](/guidelines/users/code-of-conduct) except where specifically addressed by this document. This program is for people who intend to pursue graduation and become full fledged developers. +The purpose of the Junior Developer Program is to assist interested people with learning how to create and maintain high quality achievement sets for RetroAchievements. It is for people who intend to pursue graduation and become full developers. As part of the program, junior developers create sets to show proficiency in set design, set presentation, toolkit usage and implementation. + +Junior Developers are required to understand and abide by the [Developer Code of Conduct](/guidelines/users/code-of-conduct) except where specifically addressed by this document. ### Entry Requirements @@ -18,52 +20,43 @@ To join the Junior Developer Program, the following requirements must be met: - Must be familiar with how RetroAchievements sets are structured: this means having an account that is at least 3 months old and have at least 3,000 points. As sets must be designed with hardcore in mind, hardcore points are preferred but not obligatory - Cannot be banned or suspended from achievement development or involuntarily untracked from competitive leaderboards - Have a Discord account verified on the [RetroAchievements Discord server](https://discord.gg/dq2E4hE) -- Request the Junior Developer role in #role-request channel in the General section of the RA Discord server - - Include your RA profile link - - State the game for which you intend to create a set and link its RA set page or request that it be made if it does not exist - - Read through all [RetroAchievements Developer Docs](/developer-docs/) and fill out and post a [Set Plan](https://docs.google.com/spreadsheets/d/1VC2phJ9AUcZK5Ll4bVuMpJXED8QdM_nw8OdSAuLc3bI/edit#gid=0) - - Ping the **@Code-Reviewer** role in your request to join thread -- Unless specifically authorized by [Developer Compliance](https://retroachievements.org/messages/create?to=DevCompliance), all requirements in this section must be met to gain entry to the Junior Developer Program regardless of previous RA experience - -### Claiming and Developing Sets - -Junior Developers must submit set plans for review immediately after making a claim using a [Set Plan template](https://docs.google.com/spreadsheets/d/1VC2phJ9AUcZK5Ll4bVuMpJXED8QdM_nw8OdSAuLc3bI/edit#gid=0) or similar custom sheet. A post with only a textual description is not sufficient for a set plan. Junior Developers shall post a Set Plan Review in the #⁠jr-dev-forum, outlining the scope of the planned achievement set. The set plan is not a final product, however it must show a general outline of the planned set including progression, challenge, and other types of achievements. Brief descriptions and point values must be included as well. If during development significant deviations are made from the set plan, a revised set plan must be submitted for approval prior to requesting entry into the backlog. - -The purpose of the Set Review is to ensure Junior Developers have a solid baseline plan from which to work and that it is free of [Unwelcome Concepts](/guidelines/content/unwelcome-concepts.html). This review will be quick, and should largely mirror a typical process for developing a good RA set, which should always start with coming up with a set plan. This will give Code Reviewers an opportunity to avoid having to later review progression-only sets that would need to be expanded, or bloated sets that would need to be trimmed, and will hopefully streamline the review process for everybody. - -Once a set plan is approved, Junior Developers may begin work on set development. - -Note: New Junior Developers who had a set plan approved when requesting to join the Junior Developer may immediately begin work on the set once they are onboarded and have made a claim on the set for which their initial plan was approved. - -If a Junior Developer needs to extend their claim beyond 3 months, they need to make a progress report on the official forum for the game in accordance with [Claims System rules for extending a claim](/guidelines/developers/claims-system.html#extending-a-claim). - -Prior to a second extension (at the six-month mark) as well as further extensions, a detailed progress report must be sent to the [Code Review Team](https://retroachievements.org/messages/create?to=CodeReviewTeam) for approval before the extension is made. The team may deny the extension in cases where progress is insufficient. - -When a junior set is marked as In Review, the claim will be renewed automatically when it would normally expire. While progress reports on forums are not necessary for such extensions, potential players usually appreciate the update. +- Read through all [RetroAchievements Developer Docs](/developer-docs/) + +### Developing and Publishing Sets as a Junior Developer + +The process to work on sets as a junior follows the roadmap below. In particular, there are 3 steps that require appproval by code reviewers before proceeding, namely the **Set Plan**, **Ready for Review** and **Code Review**: +- Prepare a thorough **Set Plan**. It's recommended to start with one of our [templates](https://docs.google.com/spreadsheets/d/1VC2phJ9AUcZK5Ll4bVuMpJXED8QdM_nw8OdSAuLc3bI/edit#gid=0), but you may adjust one to fit your needs over time. +- Submit your set plan for approval. While the set plan is not a final product, it must show a general outline of the planned set including progression, challenge, and other types of achievements. Brief descriptions and point values must be included as well. If during development significant deviations are made from the set plan, a revised set plan must be submitted for approval. + - If this is your first set as a junior, you have to submit this set plan in the #role-request forum on the [RetroAchievements Discord server](https://discord.gg/dq2E4hE), along with a link to your RA profile, a link to the page of the game you wish to work on, and a ping to @Code-Reviewer. + - If you already are in the junior program, you have to submit this set plan on #jr-devs-requests. As a junior developer with at least one set published, you may claim the game while you work on your set plan, but no work is allowed prior to having your plan approved. +- Once your plan is approved, develop your set. This includes RAM digging, making assets, creating achievement badges, writing clear descriptions and unique titles as well as thoroughly testing your assets. Code reviewers and fellow juniors are available to help in #jr-devs! +- [Request a review}(/developer-docs/am-i-ready-for-review) by making a **Ready for Review** post on #jr-devs-requests. Do this only when you think your set is as close to publishable as you can get it. + - To get approved at this step, your set must be clear of bad practices flagged by AutoCR. + - Once approved at this step, your set is added to the review backlog, and you wait for an in-depth code review. During that time, it is highly recommended to read the reviews of other juniors and improve your own set awaiting review whenever you read feedback that could equally apply to your work. +- Work through the **Code Review** with your code reviewer. Be ready to rework logic and learn the best practices. This is arguably your best opportunity to learn as well as to show your proficiency and understanding. +- Potentially graduate and become a developer. This cannot happen after a first set and depends on multiple factors including proficiency and trust as described below. +- Publish your set for all RA users to enjoy! ### Rules and Restrictions The following rules apply to all Junior Developers: - -- Must be part of the Discord server when requesting to become a Junior Developer, and will remain in the server for the entire educational period - - It is preferable for all contact with the (direct) Code Reviewer(s) to be through Discord +- Must stay on RA's Discord server for all communication with code reviewers - May only create achievements, leaderboards and Rich Presence for a set on which they have an active claim - - This means no working on any sets that are not claimed. Failure to adhere to this rule may result in dismissal from the Junior Developer Program + - **This includes local work**. This means no working on any sets that are not claimed. Failure to adhere to this rule may result in dismissal from the Junior Developer Program - Junior Developers may practice RAM digging games for which they do not have a claim, but shall not publish any code notes -- May not make a new claim while they have any unaddressed tickets -- Will prioritize resolving open tickets over development of a new set. For additional information on ticket handling, see [Ticket Handling](#ticket-handling), below. -- Not eligible to participate in collaborations -- May only [revise](/guidelines/content/achievement-set-revisions) sets where the Junior Developer is the sole author of the existing set. - - Must make a revision request in #jr-devs-requests detailing the revision plan. The Code Reviewer team will consider the request for approval -- May not make a claim on any GameCube set -- May not make a claim without Code Reviewer approval on sets for the below consoles. Junior Developers must make a development request in #jr-devs-requests after at least 1 set has been published, with approval at the discretion of the Code Reviewer team +- Will prioritize [resolving open tickets](#ticket-handling) over development of a new set. In particular, no new claim can be made while having any unaddressed tickets +- If a Junior Developer needs to extend their claim beyond 3 months, they need to make a progress report on the official forum for the game in accordance with [Claims System rules for extending a claim](/guidelines/developers/claims-system.html#extending-a-claim). Moreover, prior to a second extension (at the six-month mark) as well as any further extension, a detailed progress report must be sent to the [Code Review Team](https://retroachievements.org/messages/create?to=CodeReviewTeam) for approval before the extension is made. The team may deny the extension in cases where progress is insufficient. + +There are restrictions on the type of claims you can make before graduation. You cannot: +- Work on subsets, collaborations or revisions (excluding your own) +- Claim a hack if you already published a set for another hack +- Claim a hack or homebrew you developed yourself +- Claim any Gamecube game +- Claim a game on any of the following consoles without explicit approval by code reviewers. You can request this approval as part of your set plan approval, and only if you have published another set before: - PlayStation 2 - PlayStation Portable - Any future 6th+ generation consoles, unless specifically allowed - Dreamcast games using the [Windows CE firmware](https://retroachievements.org/game/24833) -- May not work on any subset -- May make a maximum of 1 set for a hack during the program -- Developers of hacks and homebrews may not work on their own games during the program ### Ticket Handling @@ -72,20 +65,7 @@ Junior Developers are expected to prioritize resolving open tickets over develop - If a ticket is in Request status while waiting for information from the reporter, they may continue work on a new set, but must immediately reprioritize the ticket(s) once the reporter responds - To put a ticket into Request status, ask the Code Reviewers, using the #jr-devs-requests, to transfer the ticket to the reporter after you have requested further information by asking the reporter using a comment on the ticket. - Once you have fully addressed the ticket, leave a comment on the ticket describing what the cause of the issue was and what you did to resolve the issue. -- Contact the Code Reviewers, using the #jr-devs-requests, to resolve ot close the ticket as appropriate after your comment has been made. - -### Code Review Requests - -Junior Developers are required to ensure sets they submit for Code Review are of the highest quality they can make. If a set has known issues, Junior Developers must resolve them prior to requesting a Code Review. Code Reviewers are available to answer questions and offer guidance to assist Junior Developers with resolving issues. The following rules apply to all Junior Developers intending to submit a Code Review request: - -- Must follow the ["Am I Ready for Review"](https://docs.google.com/document/d/e/2PACX-1vSYRcYpyN0W8oP9Ho0YMiUutZEs-np4JDL-Be5IfuR5oyG_92wVwgwA5BkTHywK_olmzRBjpZGehKM6/pub) guide prior to requesting a Code Review -- May not submit sets that fail to conform to the [Writing Policy](/guidelines/content/writing-policy) or [Code Note Standards](/guidelines/content/code-notes) -- May not submit sets that do not have original achievement badges -- May not submit sets that do not have Rich Presence -- May not request a code review until at least 7 days after claiming a set -- Will describe self testing method used in order to validate set stability in the Code Review request - -**Sets that fail to meet Code Review request requirements will be refused entry into the Code Review backlog until remediated** +- Contact the Code Reviewers, using the #jr-devs-requests forum channel on Discord, to resolve or close the ticket as appropriate after your comment has been made. ### Removal From Junior Developer Program