Is your feature request related to a problem?
Every exercise's policy is currently written from scratch, even though a large share of exercises fall into a handful of recurring shapes: no external access needed at all, access to a specific set of files, or thread-based concurrency. An instructor setting up any of these common cases has to reproduce the same policy structure by hand every time rather than referencing something reusable, and the policy format itself has no mechanism for composing, including, or referencing another policy. Each file stands alone (SecurityPolicyYAMLReader rejects a second document in the same file, and there's no merge/include step anywhere in the reader pipeline). The closest things that exist today are test-only fixture files (e.g. PolicyEverythingForbidden.yaml, PolicyOnePathAllowedRead.yaml), not an instructor-facing, documented preset.
Describe the solution you'd like
Design and implement a small set of named, reusable policy presets covering the common exercise scenarios described above (starting with no-external-access, specific-file-reads, and thread-based-concurrency) that an instructor can reference by name instead of writing a policy from scratch. Each preset should clearly state what it permits and when an instructor should choose it, so picking the right one doesn't require reading the underlying policy fields. Validate the initial preset catalog against real or representative exercises to confirm the presets actually cover what they claim to and produce a working exercise configuration, not just a plausible-looking policy file.
Describe alternatives you’ve considered
Leaving instructors to copy an existing policy file as an informal template. Rejected: nothing distinguishes an ad hoc copied file from an intentional, maintained preset, and there's no single place an instructor can look to see what presets exist or what each one is meant for.
Additional context
A usability evaluation comparing this revised, file-based configuration model against the previous annotation-based one is a separate, later piece of work involving instructor participants and mostly Artemis-side/instructor-facing material rather than Ares 2 code, and is intentionally not part of this issue.
Is your feature request related to a problem?
Every exercise's policy is currently written from scratch, even though a large share of exercises fall into a handful of recurring shapes: no external access needed at all, access to a specific set of files, or thread-based concurrency. An instructor setting up any of these common cases has to reproduce the same policy structure by hand every time rather than referencing something reusable, and the policy format itself has no mechanism for composing, including, or referencing another policy. Each file stands alone (
SecurityPolicyYAMLReaderrejects a second document in the same file, and there's no merge/include step anywhere in the reader pipeline). The closest things that exist today are test-only fixture files (e.g.PolicyEverythingForbidden.yaml,PolicyOnePathAllowedRead.yaml), not an instructor-facing, documented preset.Describe the solution you'd like
Design and implement a small set of named, reusable policy presets covering the common exercise scenarios described above (starting with no-external-access, specific-file-reads, and thread-based-concurrency) that an instructor can reference by name instead of writing a policy from scratch. Each preset should clearly state what it permits and when an instructor should choose it, so picking the right one doesn't require reading the underlying policy fields. Validate the initial preset catalog against real or representative exercises to confirm the presets actually cover what they claim to and produce a working exercise configuration, not just a plausible-looking policy file.
Describe alternatives you’ve considered
Leaving instructors to copy an existing policy file as an informal template. Rejected: nothing distinguishes an ad hoc copied file from an intentional, maintained preset, and there's no single place an instructor can look to see what presets exist or what each one is meant for.
Additional context
A usability evaluation comparing this revised, file-based configuration model against the previous annotation-based one is a separate, later piece of work involving instructor participants and mostly Artemis-side/instructor-facing material rather than Ares 2 code, and is intentionally not part of this issue.