Diseñar desafíos de codificación interactivos es difícil. Sería mucho más fácil escribir una explicación larga o crear un tutorial en vídeo. Pero para nuestro plan de estudios, estamos aferrándonos a lo que mejor funciona para la mayoría de la gente - una experiencia totalmente interactiva y de videojuegos.
Queremos que los campistas entren en un estado de flujo. Queremos que generen impulso y exploten a través de nuestro plan de estudios con el menor número de trabas posible. Queremos que ingresen en los proyectos con confianza y se expongan ampliamente a los conceptos de programación.
Ten en cuenta que para la versión 7.0 del plan de estudios gratuito, estamos avanzando hacia [un modelo totalmente orientado al proyecto con mucha más repetición](https://www.freecodecamp.org/news/python-curriculum-is-live/).
La creación de estos desafíos requiere una inmensa creatividad y atención al detalle. Hay mucha ayuda disponible. Tendrás el apoyo de todo un equipo de colaboradores a los que podrás comentar tus ideas y demostrar tus desafíos.
Y como siempre, siéntete libre de hacer preguntas en la categoría ['Colaboradores' en nuestro foro](https://forum.freecodecamp.org/c/contributors) o [nuestro servidor de Discord](https://discord.gg/pFspAhS).
Con tu ayuda podemos diseñar un plan de estudios interactivo de codificación que ayudará a millones de personas a aprender a programar durante los años por venir.
El contenido de cada desafío se almacena en su propio archivo markdown. Este archivo markdown se convierte más tarde en HTML utilizando nuestras herramientas para crear páginas web interactivas.
Puedes encontrar todo el contenido curricular de freeCodeCamp.org en el directorio [`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges).
Antes de trabajar en el plan de estudios, necesitarás configurar algunas herramientas para ayudarte a probar tus cambios. Puedes utilizar cualquier opción de las siguientes:
- Puedes [configurar freeCodeCamp localmente](how-to-setup-freecodecamp-locally.md) en tu máquina. Esto es **altamente recomendable** para contribuciones regulares/repetidas. Esta configuración te permite trabajar y probar tus cambios.
- Utilice Gitpod, un entorno de desarrollo gratuito en línea. Al hacer clic en el botón de abajo se iniciará un entorno de desarrollo listo para freeCodeCamp en su navegador. Sólo toma unos minutos.
- Editar los archivos de la interfaz de GitHub haciendo clic en el icono del lápiz del archivo correspondiente. Aunque esta es la manera más rápida, **no se recomienda**, ya que no puedes probar tus cambios en GitHub. Si nuestros mantenedores concluyen que los cambios hechos necesitan ser probados localmente, necesitaras seguir uno de los métodos anteriores en su lugar.
A continuación se muestra una plantilla de cómo se ven los archivos markdown de los desafíos. Para ver la plantilla streamlined vamos a adoptar ver [abajo](#upcoming-challenge-template).
> 2. Para la sección 'Tests' de arriba, 'text' y 'testString' deben ser cadenas YAML válidas. `testString` puede ser una función o expresión stringificada usando los asertos de Chai.
Cada desafío necesita un `id`. Si no especifica uno, entonces MongoDB creará una nueva al azar cuando guarde los datos; sin embargo, no queremos que haga eso, ya que queremos que los ids del desafío sean consistentes en diferentes entornos (escenario, de producción, muchos desarrolladores diferentes, etc.).
El texto del desafío debe usar la segunda persona ("tú") para ayudar a darle un tono de conversación. De esta manera el texto y las instrucciones parecen hablar directamente con el acampador trabajando a través del desafío. Trate de evitar usar la primera persona ("yo", "nosotros", "let's", y "nosotros").
No utilice enlaces salientes. Estos interrumpen el flujo. Los campistas no deben tener que googlear nada durante estos desafíos. Si hay recursos de los que piensas que los campistas se beneficiarían, añádelos al artículo relacionado con la guía del desafío.
No utilices emojis o emoticonos en desafíos. freeCodeCamp tiene una comunidad global, y el significado cultural de un emoji o emoticono puede ser diferente en distintas partes del mundo. Además, los emojis pueden renderizarse de manera diferente en sistemas diferentes.
Los sustantivos adecuados deben usar una capitalización correcta cuando sea posible. A continuación se muestra una lista de palabras como deberían aparecer en los desafíos.
- El desarrollo de front-end (forma adjetiva con guiones) es cuando estás trabajando en la parte frontal (sin guiones). Lo mismo ocurre con el "back end", "full stack", y muchos otros términos compuestos.
Cada desafío debe ser resuelto en un plazo de 120 segundos por un hablante nativo de español que haya completado los desafíos que lo preceden. Esto incluye la cantidad de tiempo que se tarda en leer las direcciones/instrucciones para entender el código seed, escribir su propio código y conseguir que pasen todas las pruebas.
Seguimos el tiempo que tardan los campistas en resolver los cambios y utilizar esta información para identificar los desafíos que necesitan ser simplificados o divididos.
Podemos reforzar los conceptos anteriormente cubiertos mediante la repetición y las variaciones - por ejemplo, introduciendo elementos h1 en un desafío, luego h3 elementos unos pocos retos más adelante.
- Las palabras clave del lenguaje van en etiquetas `<code>`. Por ejemplo, nombres de etiquetas HTML o nombres de propiedades CSS
- La primera instancia de una palabra clave cuando está siendo definida, o palabras clave generales (por ejemplo, "object" o "inmutable") ir en etiquetas `<dfn>`
- Las referencias a las partes del código (es decir, funciones, métodos o nombres de variables) deben estar envueltas en etiquetas `<code>`. Ver el ejemplo a continuación:
- Las referencias a los nombres de archivos y directorios de rutas (por ejemplo, `package.json`, `src/components`) deben estar envueltas en etiquetas `<code>`.
- Los bloques de código de múltiples líneas **deben estar precedidos por una línea vacía**. La siguiente línea debe comenzar con tres backticks seguidos inmediatamente por uno de los [idiomas soportados](https://prismjs.com/#supported-languages). Para completar el bloque de código, debe iniciar una nueva línea que solo tiene tres backticks y **otra línea vacía**. Ver el ejemplo a continuación:
- La información adicional en forma de una nota debe ser formateada `<strong>Nota:</strong> El texto restante de la nota...
- Si se necesitan varias notas. then list all of the notes in separate sentences using the format `<strong>Note:</strong> First note text. Segunda nota texto.`.
Las pruebas de desafío pueden hacer uso de las librerías de aserción de Node.js y Chai.js. Además, si es necesario, se puede acceder al código generado por el usuario en la variable `code`.
Tenemos un [diccionario de comentarios](/curriculum/dictionaries/english/comentarios. ) que contiene los únicos comentarios que pueden ser usados dentro del código de semilla. El caso exacto y el espaciado del comentario del diccionario deben ser utilizados. El diccionario de comentarios no debe ser expandido sin una discusión previa con el equipo de desarrollo.
Los comentarios usados deben tener un espacio entre los caracteres del comentario y los propios comentarios. En general, los comentarios deben ser utilizados con esparcimiento. Siempre considere reescribir la descripción o las instrucciones de un desafío si pudiera evitar usar un comentario de código de semilla.
Si un desafío sólo tiene un solo lugar donde se necesitan cambios de código. utilice los comentarios en el siguiente ejemplo para indicar al usuario dónde deben realizarse los cambios.
Hay diccionarios de comentarios separados para cada idioma. La [diversión inglesa del diccionario de comentarios](/curriculum/dictionaries/english/comments.js) es la base para las traducciones que se encuentran en las versiones no inglesas correspondientes de los archivos. La versión no inglesa del diccionario de comentarios en chino se encontraría en `/curriculum/dictionaries/chinese/comments.js`. Cada diccionario consiste en un array de objetos con una propiedad `id` única y una propiedad `texto`. Solo el texto `` debe ser modificado para incluir la traducción del comentario correspondiente en inglés.
Algunos comentarios pueden contener una palabra/frase que no debe traducirse. Por ejemplo, nombres de variables o nombres de librerías apropiados como "React" no deben ser traducidos. Ver el comentario a continuación como ejemplo. La palabra `myGlobal` no debe traducirse.
Cada desafío tiene un botón `Obtener un pista` para que un usuario pueda acceder a cualquier pista/solución que haya sido creada para el desafío. Temas de sugerencias/soluciones de currículo se encuentran en [nuestro foro](https://forum.freecodecamp.org/c/guide) bajo la categoría `Guía`.
Si encuentras un problema con el tema de sugerencias/soluciones de un desafío, puedes hacer sugerencias en la categoría de [colaboradores](https://forum.freecodecamp.org/c/contributors) en el foro. Los moderadores y usuarios con nivel de confianza 3 revisarán los comentarios y decidirán si incluir o no los cambios en el tema correspondiente.
1. Comience siguiendo los mismos pasos para crear un nuevo tema pero revise el siguiente para crear el título.
2. El título del tema debe comenzar con `Guía de Desafío gratuita:` concatenada con el título real del desafío curricular. Por ejemplo, si el desafío se llama "`Chunky Monkey`", el título del tema sería "`Guía gratuita del Desafío CodeCamp: Chunky Monkey`".
3.`camperbot` debe ser el dueño de estos temas/posts, así que necesitarás solicitar a un administrador que cambie la propiedad de la publicación principal a `camperbot`.
4. Una vez creado el nuevo tema, se crea un identificador del tema del foro. Se encuentra al final de la URL del tema del foro. Este id debe añadirse a la parte frontal del archivo de desafío curriculum a través del proceso normal de pull request para el botón `Obtener una pista` para vincular al tema.
Cuando se proponga una solución para un tema de guía relacionado con el desafío curricular, se debe añadir el código completo. Esto incluye todo el código original de semilla más cualquier cambio necesario para pasar todas las pruebas de desafío. La siguiente plantilla debe utilizarse al crear nuevos temas de sugerencias/soluciones:
Antes de ti [crea una solicitud de pull request](how-to-open-a-pull-request. d) para tus cambios, necesitas validar que los cambios que has realizado no causan inadvertidamente problemas con el desafío.
Una vez que hayas verificado que cada desafío que has trabajado pasa las pruebas, [por favor crea una pull request](https://github.com/freeCodeCamp/freeCodeCamp/blob/master/docs/how-to-open-a-pull-request.md).
La plantilla de desafío en proceso de ser actualizada a una estructura más limpia y menos anidada. Esto no ha sido finalizado completamente, pero lo siguiente debería estar cerca de la estructura final:
<ahref="https://github.com/freeCodeCamp/freeCodeCamp/blob/master/client/utils/challengeTypes.js#L1-L13">Tipos de desafío</a> - lo que significan los valores numéricos del tipo de desafío (enum).
<ahref="https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s">Contribuyendo a FreeCodeCamp - Escribiendo Pruebas de Desafío de ES6</a> - un vídeo que sigue a <ahref="https://twitter.com/ArrowoodTech">Ethan Arrowood</a> mientras contribuye a la versión antigua del currículo.