Change Details

Getting started with Codex development already requires learning skills that aren't required for MediaWiki development, or at least haven't been required in the past (TypeScript, Vue 3/composition API, etc.). We should consider how we can lower the burden for new contributors. #### Removing demo requirements One requirement we could drop is the requirement of building component demos in VitePress. VitePress is not widely used and our setup is mostly custom, so it requires some explanation and will be new to all new contributors. Instead, we could allow demos to be created in separate tasks, and suggest that developers use the sandbox that comes with Vite in the Codex package. This would require: - Updating the contributing code docs to remove the requirement of VitePress demos and, instead, state that they can either be created during component development or separately by another developer. - Clean up the sandbox, which is getting to be disorganized and unwieldy since it is a single file containing all components (see T311243) #### Removing or changing unit test requirements Writing tests is another major burden during development. Removing the requirement for including unit tests is questionable because it prevents us from doing any form of TDD, and significant issues are often uncovered during the testing process. One way we could get around this is by allowing the author of patch to forego tests, but then pair them with a developer who will write the tests in a related patch at the same time. This way, tests are getting written during new component development, but the burden doesn't all fall on one person. This would require: - Ensuring that a coverage calculation lower than our threshold shows up in CI as a warning, not a blocking error - Developing a process for this and documenting it #### Add section for experimental components Another pathway we've considered in the past ([[ https://gerrit.wikimedia.org/r/c/design/codex/+/801816/2 | see patch ]]) is creating a separate entry for "experimental" components that aren't ready for wider use. We could set different requirements for components in this category and even forego testing them in CI. --- ### Acceptance criteria - [x] Discuss with the team what we want to do - [x] Create subtasks

Getting started with Codex development already requires learning skills that aren't required for MediaWiki development, or at least haven't been required in the past (TypeScript, Vue 3/composition API, etc.). We should consider how we can lower the burden for new contributors. #### Removing demo requirements One requirement we could drop is the requirement of building component demos in VitePress. VitePress is not widely used and our setup is mostly custom, so it requires some explanation and will be new to all new contributors. Instead, we could allow demos to be created in separate tasks, and suggest that developers use the sandbox that comes with Vite in the Codex package. This would require: - Updating the contributing code docs to remove the requirement of VitePress demos and, instead, state that they can either be created during component development or separately by another developer. - Clean up the sandbox, which is getting to be disorganized and unwieldy since it is a single file containing all components (see T311243) #### Removing or changing unit test requirements Writing tests is another major burden during development. Removing the requirement for including unit tests is questionable because it prevents us from doing any form of TDD, and significant issues are often uncovered during the testing process. One way we could get around this is by allowing the author of patch to forego tests, but then pair them with a developer who will write the tests in a related patch at the same time. This way, tests are getting written during new component development, but the burden doesn't all fall on one person. This would require: - Ensuring that a coverage calculation lower than our threshold shows up in CI as a warning, not a blocking error - Developing a process for this and documenting it #### Add section for experimental components Another pathway we've considered in the past ([[ https://gerrit.wikimedia.org/r/c/design/codex/+/801816/2 | see patch ]]) is creating a separate entry for "experimental" components that aren't ready for wider use. We could set different requirements for components in this category and even forego testing them in CI. --- ### Acceptance criteria - [x] Discuss with the team what we want to do - [x] Create subtasks - [] Complete subtasks

Getting started with Codex development already requires learning skills that aren't required for MediaWiki development, or at least haven't been required in the past (TypeScript, Vue 3/composition API, etc.). We should consider how we can lower the burden for new contributors. #### Removing demo requirements One requirement we could drop is the requirement of building component demos in VitePress. VitePress is not widely used and our setup is mostly custom, so it requires some explanation and will be new to all new contributors. Instead, we could allow demos to be created in separate tasks, and suggest that developers use the sandbox that comes with Vite in the Codex package. This would require: - Updating the contributing code docs to remove the requirement of VitePress demos and, instead, state that they can either be created during component development or separately by another developer. - Clean up the sandbox, which is getting to be disorganized and unwieldy since it is a single file containing all components (see T311243) #### Removing or changing unit test requirements Writing tests is another major burden during development. Removing the requirement for including unit tests is questionable because it prevents us from doing any form of TDD, and significant issues are often uncovered during the testing process. One way we could get around this is by allowing the author of patch to forego tests, but then pair them with a developer who will write the tests in a related patch at the same time. This way, tests are getting written during new component development, but the burden doesn't all fall on one person. This would require: - Ensuring that a coverage calculation lower than our threshold shows up in CI as a warning, not a blocking error - Developing a process for this and documenting it #### Add section for experimental components Another pathway we've considered in the past ([[ https://gerrit.wikimedia.org/r/c/design/codex/+/801816/2 | see patch ]]) is creating a separate entry for "experimental" components that aren't ready for wider use. We could set different requirements for components in this category and even forego testing them in CI. --- ### Acceptance criteria - [x] Discuss with the team what we want to do - [x] Create subtasks - [] Complete subtasks