From 6af5cd85d800b04a271ec98bdb3e072c5ced3e35 Mon Sep 17 00:00:00 2001 From: Teyras Date: Sun, 22 Jan 2017 16:22:13 +0100 Subject: [PATCH] analysis introduction wording - remove 'priority buckets' --- Rewritten-docs.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/Rewritten-docs.md b/Rewritten-docs.md index 2e38170..526007b 100644 --- a/Rewritten-docs.md +++ b/Rewritten-docs.md @@ -427,22 +427,23 @@ treading through unexplored fields. Also, no existing solution is extensible enough to be used as a base for the new system. After considering all these facts, it is clear that a new system has to be written from scratch. This implies that only a subset of all the features will be implemented in the first -version, the others coming in the following releases. +version, and more of them will come in the following releases. Gathered features are categorized based on priorities for the whole system. The -highest priority has main functionality similar to current CodEx. It is a base -line to be useful in production environment, but a new design allows to easily -develop further. On top of that, most of ideas from faculty staff belongs to -second priority bucket, which will be implemented as part of the project. The -most complicated tasks from this category are advanced low-level evaluation +highest priority is the functionality presente in current CodEx. It is a base +line for being useful in production environment. The design of the new solution +shall allow extending the system easily. Ideas from faculty staff have secondary +priority, but most of them will be implemented as part of the project. The most +complicated tasks from this category are advanced low-level evaluation configuration format, using modern tools, connecting to a university systems and -merging separate system instances into single one. Other tasks are scheduled for -next releases after successful project defense. Namely, these are high-level -exercise evaluation configuration with user-friendly interface for common -exercise types, SIS integration (when some API will be available from their -side) and command-line submit tool. Plagiarism detection is not likely to be -part of any release in near future unless someone other makes the engine. The -detection problem is too hard to be solved as part of this project. +merging separate system instances into a single one. Other tasks are scheduled +for next releases after the project is successfully defended. Namely, these are +high-level exercise evaluation configuration with a user-friendly interface for +common exercise types, SIS integration (when a public API becomes available for +the system) and a command-line submission tool. Plagiarism detection is not +likely to be part of any release in near future unless someone else implements a +sufficiently capable and extendable engine -- this problem is too complex to be +solved as a part of this project. We named the new project **ReCodEx -- ReCodEx Code Examiner**. The name should point to the old CodEx, but also reflect the new approach to solve