1. Yes, I get the point that DB schema comes later. But ...
I still think there is an argument for starting to develop the high-level logical data model now. What are the major entities, and how do they link to each other? For example, we know we have standards and individual outcomes, with a one-to-many relationship. Also, how to they link to existing moodle concepts like activity modules? That is many-to-many.
Another way to put it is that some people might say that UI mockups should come later in the design process, but you have included them in the spec already, and that is really helpful for understanding what is going on. I think that some high-level entity-relationship diagrams would similarly illuminate the spec, and more importantly help validate early on that what you are specifying will be possible to implement in the back-end.
2. First, creating new plugin types is not a big deal. pluginlib.php etc. do a lot of the work. Of course it should still only be done when really necessary, and for this spec most of the functionality fits into existing plugin types:
- Any reporting uses either report_ or gradereport_.
- 'Manage outcomes sets' could be a tool_.
- I think we have greed that algorithms for computing whether an outcome has been met from other data should be a new plugin type. (Good luck naming that )
- In theory, different import/export formats for outcomes could be a new plugin type, but in the first instance, we probably don't need to formalise that. If we ever find it necessary, we could move the code from inside tool_manageoutcomes to separate plugins.
- For bits of the UI, particuarly student-related display, the UI might naturally work as blocks.
The core of the system will, of course, have to be added to Moodle core, as will the API that activities use to communicate with core.
5. Yes, looks like we are talking ourselves into a 'both' solution.
9. I am not suggesting that we mix grades and outcomes in the same UI. I am asking about the back-end. There are lots of similarities:
- There is a central store of information about what students achieved on different activities.
- For each activity, there can be multiple 'grade_items'. Those might be one or more different numerical grades, or they might be the evidence that a student has met one or more differnet outcomes from an outcome set.
- There is an API for acitvities to push the information about which 'grade_items' correspond to it, and the value for each student for each grade item, once the student has completed the activity.
- There is a plugable system of gradereport_s so the the data in the back-end can be displayed in different ways. There are also import and export plugins for getting the data in and out.
- There is already code in the back-end to calculate new grade_items, and overal course summaries from other grade_items.
- The gradebook and advanced grading plugins already play nicely together.
I think there is enough there to justify doing some serious thought about how much of the existing back-end can be re-used.
That does makes things harder initially. Certainly for you doing the design. It is much easier to design with a blank sheet of paper that to start from someone else's design where the only accurate and up-to-date documentation is the existing code. Simiarly it is harder to build on someone else's code that to write your own. Also, there are known issues with the gradebook API, but why can't we take this opportunity to fix them?
Even with all that, there may be good reasons why it is better to not build inside the gradebook back-end, but if so, I think you should be able to articulate why.
You were the one wh raised "overhead of maintaining and configuring them" (quite rightly!).