The technical documentation has been updated with some clarifications and refinements. The main highlights though are that the tables have been renamed for clarity and an ERD like diagram has been added to show the relations between the new outcome tables and core tables.

I went thru the wiki and this thread again, with the focus on the technical specification. I have couple of comments and questions in random order (as they came to my mind).

DM1

Firstly, please rename pages like "Capabilities and Roles", "Migration and Technical Issues", "Specifically Excluded Use Cases" and similar in a way that it is clear they are related to this project. Using "Outcomes Specification/" (including the tail slash) is what I would do. Without it, they just pollute the dev wiki and may confuse developers looking for a documentation (imagine a developer looking for dev docs on capabilities and roles system in Moodle, for example).

DM2

DM3

I don't like the userid column in outcome_sets table. If it should be foreign key to the user table, it can't have 'default 0' imho. If the value is to be optional (as I understood the description of the field), just keep it declared as the foreign key with the NULL value allowed. I can't see any reason for 'default 0' (especially for foreign keys). Same may apply for other columns.

DM4

I would like to hear more about your concept of the outcome_areas table. 'Areas' are used in several subsystems in Moodle core, such as files API or advanced grading methods. They represent sort of unified system of locating and addressing places in Moodle that other components can hook to (as in file is attached to a post, image is embedded to a text field, advanced grading form is used for assessing submissions in the Assignment module etc). It has been proved that what works is what I call "the holy four" (I wanted to call it the "fantastic four" but some puny film studios trademarked it ).

Shortly, it is good to use the combination of contextid + componentname + areaname + optional itemid to address hookable places in Moodle. So if there is a file attached to the student's submission in the Workshop module, we can easily associate the file with the context (contextid of the workshop module instance), componentname ("mod_workshop"), area ("submission_attachment") and itemid (the submissionid). Similarly, the rubric form used to assess submissions in the assignment module is hooked to an area identified by context (context of the assignment module instance), component ("mod_assign") and area ("submissions").

Looking at your ERD, your tables outcome_areas and outcome_used_areas do not fit my mind well. Not only I'm missing the contextid there. Could you please provide an example/illustration of these tables filled with some data and explain what these data mean? Eventually some pseudo-SQL queries?

DM5

WRT Phill's answer above, I have not found any detailed information of how you plan to integrate Outcomes with advanced grading methods. The spec just claims that there will be an API for that. But how will that API look like, at least roughly shaped?

What I would expect is that every advanced grading form is able to be associated with zero, one or many outcomes. When a form is reused in other activity or shared as a template, these mappings are preserved by default unless they are explicitly removed (note that advanced grading forms are copied for each individual activity, that is different from how Questions are implemented).

First, thank you so much for taking the time to read over the wiki docs. I know it takes some time to digest it all, so it is very much appreciated.

DM1 - OK, we can do that.

DM2 - Sounds good.

DM3 - That's fine, null will be used instead of zero. Please see change here. Let me know if I missed any.

DM4 - I was also trying to stick a contextid into the outcome_areas table, but it wasn't making sense for the associations that we are making. EG: what contextid would you use for a question (remember, questions exist on the site or course)? Same question for a grading form. If you think of a way to include it that would be beneficial, I'm very much interested.

Example for a grading form data would be component=gradingform_rubric, area=criteria, itemid=gradingform_rubric_criteria.id and this would represent an outcome(s) being associated to a rubric criteria. Once the grading form was associated to an activity, then a record in the outcome_used_areas would be added with the cmid of the activity in question and the id of our record from outcome_areas. The outcome_used_areas is important for coverage reports and because some content (like questions) can be used in multiple activities and we want to be able to distinguish between the two.

DM5 - I don't yet know how the API will look, but the idea is, it'll be designed to accomplish the goals I have laid out and more. I assure you it will be flexible and re-usable and it will be developed out in the open for all to review and critique.

What you are expecting is exactly what I was thinking. Since grading forms are loosely defined, meaning the plugin can do whatever it likes, then the integration of the outcomes would not be automatic. So, it is up to the grading form to determine how it would like to use outcomes. For example, what we would like to do for rubric is to be able to associate outcomes on a per criteria level. Another grading form may want to do it on another mechanism or just allow a single association to the grading form as a whole. Please see my response to DM4 for example data. If we are using a grading form template, then the outcome associations would be copied with the rest of the grading form.

So, there is an obvious value to add to outcome_areas.contextid for questions. That is useful metadata. In is not necessary for anything else in your spec, but I still think it should be added. (It may be useful for future reporting or maintenance things you you have not thought about yet, and won't be implemented in the first version.)