Project Governance
This page documents how the Artemis project is governed today. It describes the roles that exist, the path a change takes from idea to release, and the quality gates that every change has to pass.
Roles
Artemis distinguishes three contributor roles in its development process.
| Role | Who | Responsibility |
|---|---|---|
| Contributor | Anyone, inside or outside the organization | Proposes features and bug fixes, implements changes, reviews and tests pull requests |
| Feature maintainer | Named per feature, module, or goal area (see below) | Owns the direction of an area, reviews changes in that area, and approves them before final review |
| Artemis maintainer | Contributors with merge rights on develop | Performs the final review, merges changes, and decides on cross-cutting and release-relevant questions |
Contributors are expected to follow the contribution guidelines, including the identity and transparency policy, and the Code of Conduct.
Maintainer responsibility is assigned on two levels: cross-cutting goals that span the whole platform, and individual features and modules.
Responsible maintainers per goal
Artemis development is organized around four long-running goals that cut across every module. Each one has a maintainer who keeps the platform moving in that direction.
- User experience: an intuitive and accessible interface for students and instructors across diverse learning scenarios.
- Scalable infrastructure: supporting large courses with thousands of concurrent participants at high availability and performance.
- Constructive alignment: keeping learning goals, learning activities, and assessment deliberately connected, for example through exam mode and competencies.
- Learning analytics: turning data into actionable insight for learners and instructors while preserving data privacy.
| Goal | Responsible maintainer |
|---|---|
| User experience | Ramona Beinstingel (@rabeatwork) |
| Scalable infrastructure | Matthias Linhuber (@mtze) |
| Constructive alignment | Stephan Krusche (@krusche) |
| Learning analytics | Maximilian Anzinger (@maximiliananzinger) |
Responsible maintainers per feature and module
Every feature and module of Artemis has a named maintainer. Contact them if you have questions about that area or want to develop a new feature in it.
| Feature / Module | Responsible maintainer |
|---|---|
| Account | Stephan Krusche (@krusche) |
| Exercises | Stephan Krusche (@krusche) |
| Programming exercises | Stephan Krusche (@krusche) |
| Build agents | Stephan Krusche (@krusche) |
| LocalVC | Stephan Krusche (@krusche) |
| LocalCI | Stephan Krusche (@krusche) |
| Jenkins | Stephan Krusche (@krusche) |
| Quiz exercises | Maximilian Anzinger (@maximiliananzinger) |
| Modeling exercises | Felix Dietrich (@FelixTJDietrich) |
| Text exercises | Felix Dietrich (@FelixTJDietrich) |
| File upload exercises | Stephan Krusche (@krusche) |
| Exam mode | Stephan Krusche (@krusche) |
| Assessment | Maximilian Sölch (@maximiliansoelch) |
| Communication | Stephan Krusche (@krusche) |
| Lectures | Patrick Bassner (@bassner) |
| Atlas | Maximilian Anzinger (@maximiliananzinger) |
| Iris | Patrick Bassner (@bassner) |
| Athena | Maximilian Sölch (@maximiliansoelch) |
| Hyperion | Felix Dietrich (@FelixTJDietrich) |
| Tutorial groups | Ramona Beinstingel (@rabeatwork) |
| Plagiarism checks | Markus Paulsen (@MarkusPaulsen) |
| LTI | Maximilian Anzinger (@maximiliananzinger) |
| Calendar | Stephan Krusche (@krusche) |
| Global search | Patrick Bassner (@bassner) |
| Video source | Patrick Bassner (@bassner) |
| Course | Stephan Krusche (@krusche) |
| Admin | Stephan Krusche (@krusche) |
| Notification | Stephan Krusche (@krusche) |
The machine-readable counterpart of this table is
.github/CODEOWNERS. It maps
source directories to individuals or to GitHub maintainer teams, and GitHub requests those owners as
reviewers automatically when a pull request touches their area.
Becoming a maintainer
Maintainer roles are earned through sustained work in an area, and they are granted and recorded in a way that is reviewable by everyone.
Feature maintainer
- Nomination. An existing maintainer nominates a contributor, or a contributor nominates themselves, by opening an issue that names the area and links the work it is based on.
- The bar. A sustained record of merged pull requests and of substantive reviews in that area over at least the last six months, visible in the repository history and in Hephaestus, plus demonstrated command of the guidelines that apply to the area. Reviewing counts as much as writing code: a maintainer's main job is judging other people's changes.
- Decision. Taken at the weekly maintainer meeting. If nobody objects within one week of the nomination, it passes by lazy consensus. The maintainer of the goal area that contains the feature can veto.
- Record. A pull request updates
.github/CODEOWNERSand the tables above. That merged pull request is the appointment: there is no separate list to keep in sync, and the published table can therefore not drift away from the one GitHub enforces.
Artemis maintainer
Artemis maintainers are nominated from among the feature maintainers, following the same steps. The
decision is taken by the existing Artemis maintainers at the weekly meeting, and it is recorded the same
way. The role carries merge rights on develop and the final review before a change lands, so it
presupposes a track record across module boundaries rather than in a single area.
Stepping down and becoming emeritus
A clear exit path is part of the role, not an afterthought. It is what makes the maintainer tables trustworthy and what makes the role safe to accept.
- Voluntarily. A maintainer can step down at any time, for any reason. They move to the emeritus list, keep the credit for their work, and give up the rights.
- Through inactivity. After six months without reviews or merges in their area, the weekly meeting asks the maintainer whether they want to continue. After twelve months of inactivity, the move to emeritus happens automatically. A maintainer who is listed but unreachable is worse for contributors than no maintainer at all, because pull requests wait on a review that will not come.
- For cause. Violations of the Code of Conduct are handled through the process defined there. A sustained failure to act on the responsibilities of the role is decided at the weekly meeting, and the decision is written down.
Returning is welcome and does not start from zero: an emeritus maintainer who becomes active in their area again can be reinstated by the weekly meeting without a new six-month qualifying period.
How a change reaches Artemis
The development process is the authoritative description. In short:
- Feature request. Anyone opens a GitHub issue describing the desired functionality, its rationale, expected benefits, and risks.
- Evaluation. Maintainers evaluate the request together with the development team for feasibility and impact.
- Feature proposal. Larger changes get a written proposal appended to the issue from the
feature proposal template,
covering functional and non-functional requirements, analysis models, system architecture, and
UI/UX design where the change is user-facing. Labeling an issue
needs-feature-proposaltriggers a GitHub Action that adds the template automatically. - Implementation. Work happens on a branch that follows the
<type>/<area>/<short-description>convention, against the coding and design guidelines. - Pull request. Titles follow the naming conventions, because they become the release notes. The pull request template requires the author to confirm testing, performance, data economy, security annotations, translations, and test coverage.
- Review. See below.
- Merge. An Artemis maintainer merges into
develop.
Review and approval
Reviewing is a shared responsibility of all developers, and the reviewer guidelines describe what a review has to cover: deploying the change to a test server, executing the documented testing steps, checking related functionality for regressions, and assessing code quality, correctness, performance, and security.
Approval is layered:
- Reviewers approve the code, the manual test, the exam mode behavior where relevant, and the performance review, and record which of these they actually did.
- The feature maintainer for the affected area verifies the change within their scope and approves it.
- An Artemis maintainer performs the final review and merges.
Weekly maintainer meeting
The maintainers meet weekly. The meeting is where the project resolves what asynchronous review cannot:
- Disagreements between reviewers and authors that a pull request thread has not settled, including disputes about scope, architecture, or whether a change should be made at all.
- Cross-cutting decisions that affect more than one feature or module and therefore have no single responsible maintainer.
- Prioritization of feature requests and larger proposals, including a standing review of the roadmap board.
If a discussion on a pull request or an issue stalls, ask for it to be put on the agenda of the next meeting; a maintainer can do that for you. Outcomes are recorded back on the issue or pull request they concern, so the decision and its rationale stay where the next reader will look for them.
Technical quality gates
Every pull request runs the same automated gates before it can be merged. They are defined in
.github/workflows and
aggregated behind a single required check.
| Gate | What it enforces |
|---|---|
| Build | Server and client build, including the production build |
| Test | Server tests (JUnit, against PostgreSQL via Testcontainers) and client tests (Vitest), with per-module coverage thresholds |
| Quality | Java formatting (Spotless) and Javadoc checks (Checkstyle), architecture rules (ArchUnit), dependency family consistency, TypeScript formatting (Prettier), linting (ESLint), style linting (Stylelint), and a type-checked client compilation |
| E2E | End-to-end tests (Playwright) against a deployed stack |
| Documentation | The documentation site builds, and broken links or anchors fail the build |
| Translation keys | German and English translation files define the same keys |
| Version consistency | The Artemis version agrees across build.gradle, the OpenAPI specification, and the README |
| Bean instantiations | Spring startup behavior does not regress into eager instantiation |
| Gradle wrapper and workflows | The Gradle wrapper is validated and workflow definitions are linted |
Coverage for changed files is reported back into the pull request, and the review checklist asks for line coverage above 90% on changed files together with meaningful assertions.
CodeQL static security analysis runs in parallel as an advisory check rather than a merge blocker, and
a scheduled scan covers develop and main independently of pull requests.
Beyond automation, changes are expected to be tested manually on a test server. Test server deployments are managed through Helios; see the test server documentation.
Inactivity and closing
A pull request without activity for 7 days is marked stale, and it is closed after 21 days of
inactivity. Any comment or commit resets the timer, and the no-stale label exempts pull requests
that are blocked on something else.