Open-Source Development
Artemis is free and open-source software, published under the MIT license. Being open source here means more than a public repository: the requirements, the design, the reviews, the tests, and the release history are public too, and the same process applies to everyone who contributes.
The core ideas of free software always have been "use", "study", "share", and "improve". With Artemis, we embrace all of those aspects:
- Artemis is used by universities and schools to run real courses and examinations. See Adoption.
- Artemis is part of active research and is constantly improved by students as part of university courses or bachelor's and master's theses. Studying the Artemis source code helps our students improve their software engineering skills while working on a real, actively used product.
- The foundation of learning and teaching is sharing knowledge. Artemis is used to conduct courses at universities and, at the same time, used as an education research platform. See Publications.
- With more than 140 contributors and a regular release cycle, we are constantly improving Artemis.
How a change is developed
Artemis is a professionally maintained engineering project, not a code drop. Every change goes through the same steps, which are described in full in the development process.
| Step | What happens | Where it is documented |
|---|---|---|
| Feature request | Anyone opens a GitHub issue describing the desired functionality, its rationale, and its risks | Development process, step 1 |
| Evaluation | Maintainers and the development team assess feasibility and impact | Development process, step 2 |
| Feature proposal | Larger changes get a written proposal appended to the issue from a template | Feature proposal template |
| Requirements engineering | Functional and non-functional requirements are stated explicitly | Development process, step 3.2 |
| Analysis | Analysis object model plus activity, state chart, and communication diagrams where they help | Development process, step 3.3 |
| System architecture | Subsystem decomposition, interfaces, persistent data management, and access control | Development process, step 3.4, System design |
| UI/UX design | Mockups against the Artemis design system and a described user flow | Development process, step 3.5, AET UI/UX guidelines |
| Implementation | Code on a conventionally named branch, following the coding and design guidelines | Guidelines |
| Automated tests | Server tests (JUnit), client tests (Vitest), and end-to-end tests (Playwright), with per-module coverage thresholds | Server tests, Client tests, E2E tests |
| Manual verification | The change is deployed to a test server and tested with every affected user role, including exam mode where relevant | Test servers |
| Peer review | Reviewers test the change, check code quality, correctness, performance, and security, and record what they reviewed | Reviewer guidelines |
| Feature-maintainer review | The maintainer responsible for the area approves it within their scope | Project governance |
| Artemis-maintainer approval | Final review and merge into develop | Project governance |
A pull request is only ready to merge once it has approvals from at least four reviewers, every checklist item in the pull request description is checked, and every review thread is resolved.
Quality gates
Automated checks run on every pull request and are aggregated behind a single required status check: build, server and client tests with per-module coverage thresholds, code style and architecture rules, end-to-end tests, a documentation build that fails on broken links, translation key consistency between English and German, version consistency across the build files, and Spring startup behavior. CodeQL static analysis runs alongside as an advisory check.
Project governance lists the gates in detail.
Contributing
Contributions from outside the organization are welcome and follow the same process. Start with CONTRIBUTING.md and the setup guide, and read the Code of Conduct.
Contributors use their real name and an authentic profile picture. In a project used to run examinations, knowing who wrote and who approved a change is part of what makes the review process meaningful.