Talk:Outcomes Technical Specification
Comments from Tim Hunt
Overall, this is quite a hard specification to understand. Below I make some suggestions for things that would have helped me understand it more easily. Anyway, I am not surprised you have not had many other comments.
I think that what you are trying to do (e.g. the specification) is good, and I hope you can do it, but several aspects of the design worry me a lot. I don't think you are ready to start coding yet. Of course, the comments below focus on the things that I am worried about. The majority of the design is good, but there are still a lot of details that worry me.--Tim Hunt 20:35, 2 March 2013 (WST)
Backwards compatibility breaks
1. Outcomes will now only be created at the site level and then mapped to courses and content. Outcomes will no longer be created at the course level.
- that makes it an institutional tool, not a teacher's tool. Also at Dublin I I was discussing this with Phil, which caused him to add https://docs.moodle.org/dev/index.php?title=Outcomes_Instructor_Use_Cases&action=historysubmit&diff=37938&oldid=37310 - are you ignoring that requirement for now?
3. Outcomes will no longer appear in the grade book.
This really should say where they will appear instead.
4. Outcomes will no longer support scales. It is just a simple pass or fail.
Another way to say this is that Outcomes will be hard-coded to only use a Pass/Fail scale. I am not sure what that hard-coding gains us, but does that really let you satisfy everyone's use cases? Is it that hard to make it more general. It could just default to pass/fail to give the UI simplicity you are after.
In other words, outcome_mark.result could easily be a value on a scale, rather than a boolean.
UI issues
It is not entirely clear to me from either https://docs.moodle.org/dev/Outcomes_Technical_Specification#Course or https://docs.moodle.org/dev/Outcomes_Instructor_Specification where the new settings will go on the course, activity and question settings forms. It seems to say it will go near the top, which is very presumptuous of you, and probably wrong from a usability point of view.
I would put the new settings: 1. Course: after Student progress. 2. Activity: After completion / conditional access. 3. Questions: just before tags.
DB design issues
The whole database design would be a lot harder to understand if you had done a diagram showing the links between the tables, rather than just setting them out individually.
The summary of my detailed comments below is that there are many areas where I think you have made the wrong design decision. In particular, in many areas, you have taken a different design decision from what was done elsewhere in Moodle core, often only after we learned from previous mistakes. Therefore, where you have done something different from the design of other parts of Moodle, I think it behoves you to explain why your design is right, rather than me to explain in detail why your design is wrong.
idnumbers everywhere else in Moodle are unique to the site / course etc. If you really want GUIDs, then call that DB column something else. For quiz questions, it is called 'stamp', but I am not sure that is a good name. Note that you get problems, for example if someone does a backup and restore to another site, does the GUID change or not? What if they then edit the original or the copy? The edit might be a typo fix, or a fundamental change. (Basically, the correct design is really hard, and I have never really worked out the right design for questions. Anyway, I would like to know what you are proposing to implement.)
Meta-date is something that should be implemented generically throughout Moodle, but you can't wait for that, so in the short term you have to do your own thing. Should the metadata elements have both a machine-readable shortname, and a user-readable name? (You need to think about sites using the multilane filter.)
outcome_content really needs a contextid column, like all the other tables that now have component / area / itemid mapping - and for the same reason that it was added elsewhere. If you don't know why that is, then I could explain, but I am not going to type the full explanation unless it is necessary.
Note that, in the file API, there is not a table that is the equivalent of outcome_content. (In the files API, it would be a file_areas table.) Can you justify why your design should be different?
Note that almost all your database table names fail to follow the naming convention. (Point 4 here: https://docs.moodle.org/dev/Database)
I don't like the user of the outcome_set_course_map.filer column. Serialised data in the database almost always ends up being a mistake with hind-sight.
outcome_mod_content_map - putting a contextid in outcome_content renders this table unnecessary.
This duplicates a lot of very low-level data from elsewhere in Moodle. E.g. score on a question in a quiz. Is it really necessary? Are you just building a new mdl_log table - in performance terms? There also seems to be a lot of redundancy between outcome_attempt and outcome_mark.
Code design issues
I think all the code should be in the top-level outcome folder. API stuff should go in outcome/lib, rather than lib/outcome. That keeps all the code better contained. (To put it another way, I think they got that design wrong for grades, and it is right for questions. Most other core systems are simple enough that they don't need a whole folder of code, so there are not many other examples to follow.)
Again it is hard do understand exactly what you are proposing. Something like "API for plugins" would be much easier to understand if you gave some example function signatures, or calls. (E.g. https://docs.moodle.org/dev/Question_Engine_2:Design#API_for_modules_using_the_question_engine)
I think that the "Supported plugin type plugins" is right. We want outcomes support to be quite generic and uniform. For example it is right that all types should support outcomes in the same way.
You have not said whether the Reports will be done as Moodle report_… plugins or not. I think they should be done as plugins. - Ah, one can deduce that form the Capaibilities section of the spec, but you should make it explicit.
A capability name like moodle/outcome:contentmap seems perverse to me. Unless you are Yoda, before the object, the verb should come.
--End of comments from Tim Hunt 20:35, 2 March 2013 (WST) - at least for now.
