Thanks for your interest in Artemis. Contributions of every size are welcome, from a typo in the documentation to a new feature. This page is the short version: what to do, in which order, and where the detailed guidelines live.
Please read the Code of Conduct before you start, and note the identity and transparency policy below, which applies to every contribution.
- Find or discuss an issue. New here? Start with good first issue or help wanted. Otherwise look through all open issues. If nothing matches, open a bug report or feature request. For questions rather than changes, use GitHub Discussions.
- Check whether a feature proposal is needed. Small fixes can go straight to a pull request. Larger changes need a written feature proposal first, so that requirements, architecture, and UI/UX are agreed on before implementation. See Larger changes.
- Set up the development environment. Follow the setup guide.
- Create a branch. Members of the organization branch directly in the repository; external
contributors fork it first. Branch names follow
<type>/<area>/<short-description>, where the type isfeature,chore, orbugfix. Branches that do not follow this structure are rejected automatically. - Implement and test. Follow the coding and design guidelines and add automated tests. See Code quality and testing.
- Open a pull request. Start as a draft while you work, so questions can be discussed early. The title follows the pull request naming conventions, because it becomes part of the release notes. Fill in the template, including the steps for testing, and mark the pull request as ready for review once everything applicable is checked.
- Participate in review. Respond to comments, push updates, and re-request review. See Pull request review.
The development process documents each of these steps in full.
Anything beyond a contained fix goes through a feature proposal: requirements, analysis, system
architecture, and, for user-facing changes, a UI/UX design. The
feature proposal template
defines the structure, and labeling an issue needs-feature-proposal adds it to the issue
automatically.
Writing the proposal before the code is not bureaucracy: Artemis runs examinations at several universities, and agreeing on scope and design up front is what keeps large changes reviewable.
- Coding and design guidelines is the entry point.
- Server and client guidelines cover the conventions that reviewers check against.
- Performance guidelines matter: Artemis runs courses with thousands of students.
- Add server tests and client tests. Coverage thresholds are enforced per module in CI, and the review checklist asks for line coverage above 90% on changed files.
- Translate every new user-facing string into English and German. A CI check verifies that both translation files define the same keys.
- Follow the guidelines for inclusive, diversity-sensitive, and appreciative language.
- Run the linters and formatters before pushing; the commands are listed in the setup guide.
Reviewing is a shared responsibility. If you would like your pull requests reviewed, review others' too.
What to expect:
- Reviewers deploy the change to a test server, execute the documented testing steps, and check related functionality for regressions. Reviewer guidelines describes what a good review covers.
- The maintainer responsible for the affected feature or module approves the change within their scope.
- An Artemis maintainer performs the final review and merges into
develop. - A pull request is ready to merge once it has approvals from at least four reviewers, every applicable checklist item is checked, and every review thread is resolved.
- Keep pull requests focused and short-lived. A pull request without activity for 7 days is marked
staleand is closed after 21 days of inactivity.
All interaction in this project is governed by the Code of Conduct. Be respectful and constructive, review the code rather than the person, and explain the reasoning behind a requested change.
Artemis is used to run courses and examinations, so it matters who wrote and who approved a change. Contributions are therefore only accepted from accounts with a verifiable identity.
This applies to everyone:
- Real name. Use your full real name in your GitHub profile.
- Authentic profile picture. Use a clear, professional photo. Avatars, comic-style images, memojis, and similar non-authentic pictures are not accepted.
Members of the organization additionally create branches and pull requests directly in the repository and follow the internal branching and review process linked above. Using a real name is a prerequisite for joining the organization.
External contributors fork the repository, work on a branch there, keep it up to date with
develop, and open a pull request. Contributions that do not follow this policy may not be accepted.
These requirements are aligned with the GitHub Acceptable Use Policies, which stress authenticity and transparency in user profiles. For general background on contributing to open-source projects, the Open Source Guides are a good starting point.
Project governance documents the maintainer roles, the path a change takes from feature request to release, and the automated quality gates that every change has to pass. Open-source development explains how the engineering process fits together.
Maintainer roles are not reserved for one institution. Anyone with a sustained record of contributions and reviews in an area can be nominated as its maintainer, and the criteria, the decision, and the record are all public. See Becoming a maintainer. If your university wants to take responsibility for part of Artemis, that is the path, and we would like to hear from you at artemis@xcit.tum.de.
Do not report suspected vulnerabilities as public issues. Follow the private reporting process in SECURITY.md.
Thank you for helping us maintain a high standard of quality and trust in this project.