[schooltool-dev] Merging of srichter's hierarchical term branch into trunk

[Tom Hoffman]

On 9/19/07, Stephan Richter <srichter at cosmos.phy.tufts.edu> wrote:
> On Tuesday 18 September 2007 18:32, Tom Hoffman wrote:
> > I think it is necessary, and now is better than later.
>
> In that case, I would like to be paid for this work!

Stephan

If you complete the work in the attached proposal, I'll pay you for
it, but it is a little late now.

--Tom
-------------- next part --------------
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
SchoolTool Terms and Time Flow
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Framework Development
---------------------

Development of the data model and Python API for terms. This includes the
development of term types, term templates, and a redesign of
terms. Additionally, the gradebook API changes in light of the term
refactorings. Courses keep track of the term template(s) they are taught in
and courses can now define mandatory course activities and course
assessments. In the latter, the sub-term-templates are chosen in which they
should appear. The gradebook becomes persistent and now manages grade items
instead of assignments. On the section level, simple grade items can be add=
ed,
but a valid requirements tree is still maintained internally.

Terms control the SchoolTool application through an event mechanism. The
administrator can fire pre-defined events and subscribers will take actions.

To support all the features above, several event subscribers have to be
implemented to ensure data integrity.

Time Estimate: 15 days
Invoiced: 5 days


Select Term Template
--------------------

When the SchoolTool application is first initiated, the SchoolTool
administrator must select a term template that will be used for their
school. The administrator goes to a simple page and selects the term templa=
te
from a choice of several templates.

Pre-conditions: Term Template API, Term Template Vocabulary

Time Estimate: 1 day


Create Academic Year
--------------------

Based on the selected term template, it should now be easy to generate the
academic year. It can be one form that asks for all the terms' titles and
dates. UI mockup (A) demonstrates that form.

Pre-conditions: Redesigned Term API, Term generation from Term Templates

Time Estimate: 3 days


Assign Term Template to Course
------------------------------

Currently the course objects do not fit into the entire timeflow at all. Th=
at
will change. An important piece of information the course object is missing
right now is to how long the course lasts. Allowing the course to be
associated with one or more term templates will provide this information and
allows it to be better integrated into the system.

Time Estimate: 2 days


Manage Course Activities
------------------------

The administrator can globally require an activity to be required for a
course. Those activities are managed on the course directly. Further, the
adminsitrator can select in which sub-term (template) the activity must be
executed.

Time Estimate: 2 days


Manage Course Assessments
-------------------------

Besides activities, courses also specify the type of score that should be u=
sed
for reports. While some schools only require simple final grades, a lot of
standard-based schools now provide multiple assessment areas for each
course. Those have to be supported by the UI.

Time Estimate: 2 days


Manage Section Grade Items
--------------------------

It must be also possible to manage section-specific grade items via the
gradebook. Note that the course will also provide grade items. It must thus=
 be
possible to sort all grade items as desired.

Time Estimate: 2 days


Grading
-------

Ensure that grading of grade items works properly. Each type of grade items
will have to provide its own views. This is necessary to allow different gr=
ade
items to display different information.

Time Estimate: 3 days


Create Term Reports
-------------------

Managers/Teachers should be able to see grade reports for a student. This
report is commonly known as the student's academic record.

Time Estimate: 2 days


Term Data Migration
-------------------

Write generation for migrating terms.

Time Estimate: 3 days


Gradebook - Sample Data
-----------------------

Develop a sample data plugin for the gradebook. This plugin should create a
set of grades for an entire semester.

Time Estimate: 2 days


Improve Section API
-------------------

Reimplement the section API, so that all students can be accessed with one =
API
call.

Currently you cannot directly set the term of a section. This is an essenti=
al
piece of data now and should be directly associated with the section.

Time Estimate: 2 days


Timetabling Adjustments
-----------------------

Timetables heavily relied on the previous way of doing terms. I have to
investigate what changed and how we can address this. It seems to me, howev=
er,
that timetabling should be defined on top of terms and sections simply rece=
ive
a slot they are taught in.

Time Estimate: 3 days


APIDOC - Document Term Events
-----------------------------

Developers should be able to get a list of all possible events.

Time Estimate: 2 days


Multiple Evaluations
--------------------

Allow multiple evaluations for a requirement.

Time Estimate: 0.5 days
Invoiced: 0.5 days


Comment Scoresystem
-------------------

Develop a score system that contains only comments.

Time Estimate: 0.5 days
Invoiced: 0.5 days


Meetings with Tom
-----------------

We meet regularly at Tom's or my house to program, design and discuss.

Count: 2
Time Estimate: x * 6 hours
Invoiced: 2 meetings


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++

Setting Up the Year at FHS
--------------------------

* We need an efficient API for multiple evaluations. * -- done, not efficie=
nt
  though.


* We need custom evaluation objects that keep track of the term and section
  being assessed. *

Each course has a set of special requirements -- these are requirements that
will appear on the report cards & must be evaluated each semester or marking
period.  These special requirements should know the appropriate score system
needed to evaluate them.

There are also specific sets of requirements that are applied at the end of
the first and third marking periods that apply to every section ('completes
homework,' etc).

So, I would create a year, which wouldn't have any direct evaluations.  Cre=
ate
a fall semester and a spring semester, and indicate that for those terms
teachers must evaluate the course's "special requirements" for each of those
semesters.

Then I would create two marking periods, covering the first half of each
semester, and indicate that for each of these terms each section should be
evaluated for the specific set of requirements described above.

When I trigger the term's 'start' event, each section's subscriber picks up
the event, and causes the section to ask the term what 'report requirements'
it has, if any for that term.  Those events are added in a special category=
 to
the gradebook for the section.

Requirements may need to be wrapped to prevent name duplication. =


When I set up a term, I indicate what info, if any is reported each term