-
Notifications
You must be signed in to change notification settings - Fork 10
Developers Code of Conduct
This document covers developers' rights, responsibilities, and rules for fair play.
If you are not a dev, check how to become a developer.
See Also: Users Code of Conduct.
- Golden Rules
- Developers must do the following to keep in good standing
- Revisions - Working on Sets with Existing Achievements
- Code Notes
- Handling Tickets
- Expiration of Developer Status
- Achievement Ownership
- Feedback about the Developer Code of Conduct
- Follow the Developer and Content Guidelines the best you can. When in doubt, ask.
- Respect your fellow developer and communicate through any issues you have civilly.
- Make room for other developers to get a chance to work on games they like, in their own way.
- Do not discourage anyone from working on any game, in public or in private.
- When planning to work on a new game, claim the game before starting work on it.
- Only claim games when you are free of unaddressed tickets.
- Keep your work free from unwelcome concepts.
- Use protective code, preventing potential cheating and exploits.
- Leave accurate code notes for each achievement condition you use.
- For set revisions, follow the revision policy.
- Resolve tickets and leave notes each time you do.
- Like a wiki, once you publish your work, you are giving it over to the community to be reviewed and reworked over time.
Revisions, as in working on a set that has existing achievements typically requires community approval by presenting your plan in the forum and in the #revision-voting channel in Discord. Not all changes need approval. See Achievement Set Revisions for details.
Leave accurate code notes for each address you use for achievement conditions. This helps you and others maintain the set, keeping it free of bugs.
You're free to add any code notes you discover to any set without declaring intentions to work on the game. Just be careful to not delete previous notes added by someone else.
After you've published achievements be prepared for bug reports.
You're expected to keep your work bug free by appropriately resolving tickets. Respond to all tickets as soon as possible. The sooner you respond the better, cause the problem is fresh in the player's mind and you can use them to help you to resolve the problem.
While resolving tickets, leave a brief summary of what you did. If you have an indication of false report leave a message showing what conclusions you've made, and then close the ticket. Closing/Resolving a ticket without leaving any comments is an unwelcome attitude.
Do not declare your plans to work on a game if you have unaddressed tickets. A ticket is considered as addressed when the developer acknowledged the ticket, commented on it explaining the situation but is unable to resolve the problem immediately due to reasons such as waiting for saves states or more information from the reporter.
If you want to resolve tickets or fix bugs on achievements made by another developer, it's always a good practice to try to contact them and check if they are still active before changing their work. An inactive developers is someone who have have 10 or more open tickets that are older than two months (you can see their open tickets from the Ticket Manager).
If the developer is active, you can assist them in the resolution.
If the developer is inactive you can freely resolve their tickets. If necessary, you may change the achievement description in order to clarify the objective or to match the logic that is present. However, do not deviate from an achievement's concept or objective in any way without an approved revision vote.
If a fellow developer has already started to handle a ticket thru action that can be proved with comment of intent, leave it to them. The user would be given a time of 7 days to handle the ticket after comment. Example: If USERA
was fixing a ticket (having left a comment of intent) and then USERX
came to undo the work or interrupt the work in progress this would be an issue.
The developer status will expire and account type will be set to [Registered]
if the following conditions are met:
- Developers: Inactivity as developer for 6 months or overall inactivity for 3 months.
- Jr. Developers: Inactivity as developer for 3 months or overall inactivity for 1 month.
It is important for developers to remember that this is NOT a punishment and is only done for security reasons!
Inactivity as a developer will be defined as:
- Has not made or renewed a set claim.
- Has not created new achievements.
- Has not performed maintenance on existing sets (revisions, rescores, badge changes, etc.)
- Has not resolved, closed, or otherwise addressed any open tickets, theirs or otherwise.
Alternatively, developer status will be removed if the developer has 10 or more tickets that are at least 2 months old. If the developer has any active claims during this period, they will be given an additional 30 days or until the earliest claim renewal (whichever comes first) to resolve all 10 tickets. Not doing so will result in the developer falling into inactive status and the claim(s) being released.
If a user's developer status was removed due to inactivity and they wish to have it reinstated, they must contact Dev-Compliance. However, before doing so, it is recommended to review any changes that were made to the Developer Code of Conduct, updates to the achievement creation tools, and have a plan to address open tickets for their achievements, if applicable.
The steps involved in reinstatement will vary from user to user depending on the following:
- The amount of time elapsed since developer status was removed.
- The amount of tickets that may have been opened on their achievements.
- Other QA issues that may have come up since developer status was removed.
- Moderation warnings or actions the user may have received.
A user may be required to submit work to code reviewers if more than a year has passed since their developer status was removed or if they initially obtained developer status before the junior developer program existed (July 2018) and did not retroactively obtain the Junior Developer badge.
Note: Achievements edited by other developers will not count against a user seeking reinstatement.
When you publish your work you are giving it over to the community to be reviewed and reworked over time - see Achievement Set Revisions.
While the original developer does not own published achievements, they are still the caretaker in terms of bug fixing and maintenance. If another developer revises the achievement, they are the new caretaker of that achievement.
If a user with either Developer or Jr. Developer status changes accounts, achievements and tickets under the old account will be re-authored and reassigned to the new account.
Although the Developer Code of Conduct is the result of an intense debate, it's not an immutable document. If you have suggestions for improvements, contact us on our Discord server or send a message to RAdmin.
- User Guidelines
- Developer Guidelines
- Content Guidelines
- FAQ
- Setup Guide
- Emulator Support and Issues
- Ways to Contribute
- RABot, the RA Discord Robot
- Events
- Overlay Themes
- Useful Links
- Contributing with the docs
- About Us
- Tutorials
- Developer Docs
- How to Become an Achievement Developer
- Getting Started as an Achievement Developer
- Game Identification
- Achievement Design
- Achievement Scoring
- Difficulty Scale and Balance
- Progression and Win Condition Typing
- Badge and Icon Creation
- Achievement Development Overview
- Flags
- BitCount Size
- Alt Groups
- Hit Counts
- Delta Values
- Prior Values
- Value Definition
- Condition Syntax
- Minimum Required Versions for Logic Features
- Memory Inspector
- Real Examples
- Set Development Roadmap
- Achievement Templates
- Tips and Tricks
- Leaderboards
- Rich Presence
- RATools
- Console Specific Tips
- Emulator Hotkeys for Developers
- libretro core support
- Docs To Do List
- WIP User Code of Conduct
- WIP CoC FAQ
- WIP Content Guidelines
- WIP-Jr
- WIP---Dev-Tips---Code-Notes-En-Masse
- WIP-‐-Reauthorship-Policy
- Manifesto RetroAchievements
- Código de Conduta do Usuário
- FAQ - Perguntas Frequentes
- Como contribuir se você não é um desenvolvedor
- Tutorial para Jogos Multi-Discos
- Introdução
- Primeiros Passos como um Desenvolvedor de Conquistas
- Recursos de Lógica para Achievements
- Exemplos Reais
- Dicas e Truques
- Dicas Específicas de Console
- Modelos de Achievement
- Escala de Dificuldade e Equilíbrio
- Roteiro de Desenvolvimento de um Set de Conquistas
- Criação de Ícones e Emblemas
- Leaderboards
- Rich Presence
- Design de Conquistas
- Manifesto RetroAchievements
- Código de Conducta del Usuario
- FAQ - Preguntas Frecuentes
- Tablas Globales y Reglas para la Casería de Logros
- Mi juego no esta cargando los logros
- Como contribuir si no eres un desarrollador
- Por que no deberías utilizar la función de cargar estado
- Contribuyendo con los documentos
- Como funciona la Documentación de RA
- Descargas
- Intro
- Código de Conducta del Desarrollador
- Como convertirme en un Desarrollador de Logros
- Primeros pasos como un Desarrollador de Logros
- Un vistazo al Inspector de Memoria
- Características en la Logica de un Logro
- Ejemplos Reales
- Intro
- Utilizando Hit Counts como un Temporizador
- Utilizando Valores Delta y Hit Counts para Detectar un Incremento
- Un Ejemplo Simple en como evitar el Abuso de Estados de Guardado
- Evitar el Problema de que un Contador se Incremente Dos Veces en el Mismo Frame
- Creando un Temporizador con un ResetIf Hits basándote en la Velocidad de un Juego
- Plantillas para Logros
- Tips y Trucos
- Escala de Dificultad y Balance
- Diseño de Logros
- Mapa de Desarrollo de Set
- Revisiones en Set de Logros
- Creación de Iconos y Badges
- Tablas de Clasificación
- Rich Presence
- Trabajando con el ROM apropiado
- Identificación del Juego
- Guía para Sets Bonus
- Logros para ROM hacks
- Tips Específicos por Consola