Content of this document
The first term is a main feature of Artemis and is using code highlighting, e.g. “
Programming exercises
:”.- Possible feature tags are:
Programming exercises
,Modeling exercises
,Text exercises
,Quiz exercises
,File upload exercises
,Lectures
,Exam mode
,Assessments
,Discussion
,Notifications
. More tags are possible if they make sense. - If no feature makes sense, and it is a pure development or test improvement, we use the term “
Development
:”. More tags are also possible if they make sense. - Everything else belongs to the
General
category.
- Possible feature tags are:
- The colon is not highlighted.
After the colon, there should be a verbal form that is understandable by end users and non-technical persons, because this will automatically become part of the release notes.
- The text should be short, non-capitalized (except the first word) and should include the most important keywords. Do not repeat the feature if it is possible.
- We generally distinguish between bugfixes (the verb “Fix”) and improvements (all kinds of verbs) in the release notes. This should be immediately clear from the title.
Good examples:
- “Allow instructors to delete submissions in the participation detail view”
- “Fix an issue when clicking on the start exercise button”
- “Add the possibility for instructors to define submission policies”
- Limit yourself to one functionality per pull request.
- Split up your task in multiple branches & pull requests if necessary.
- Commit Early, Commit Often, Perfect Later, Publish Once.
- Open a draft pull request. This allows for code related questions and discussions.
- Make sure all steps in the Checklist are completed.
- Add or update the "Steps for Testing" in the description of your pull request.
- Make sure that the changes in the pull request are only the ones necessary.
- Mark the pull request as ready for review.
- Organize or join a testing session. Especially for large pull requests this makes testing a lot easier.
- Actively look for reviews. Do not just open the pull request and wait.
- Perform the "Steps for Testing" and verify that the new functionality is working as expected.
- Verify that related functionality is still working as expected.
- Check the changes to
- conform with the code style.
- make sure you can easily understand the code.
- make sure that (extensive) comments are present where deemed necessary.
- performance is reasonable (e.g. number of database queries or HTTP calls).
- Submit your comments and status ((thumbs up) Approve or (thumbs down) Request Changes) using GitHub.
- Explain what you did (test, review code) and on which test server in the review comment.
- Use the pull request to discuss comments or ask questions.
- Update your code where necessary.
- Revert to draft if the changes will take a while during which review is not needed/possible.
- Set back to ready for review afterwards.
- Notify the reviewer(s) once your revised version is ready for the next review.
- Comment on "inline comments" (e.g. "Done").
- Respond to questions raised by the reviewer.
- Mark conversations as resolved if the change is sufficient.
A project maintainer merges your changes into the develop
branch.