Several times in recent weeks there has been some threads in the General Problems forum revolving around the metacourse, or had evolved to metacourses. I have tried to read the documentation and I would suggest that it is actually quite unclear - I suspect it causes more problems than it solves. Once you have an understanding of the topic you can see how things fit, but if you do not, it seems a mish-mash of badly displayed ideas.
Obviously, to me anyway, the initial problem is the language used in the documentation, but that stems from the fundamental descriptive terminology of what a "child" course is - as compared to a metacourse. The metacourse draws its enrolments from the "child" course and that confuses ordinary people like me.
Consider this, in a Client/Server network, the client draws data from the server, and the roles are reversible. The client is the "child" of the "parent" server. This is common and familiar across all languages, all cultures I have ever been in contact with. The parent is providing data to the child. However, in the child/metacourse arrangement, this description is reversed. The metacourse is drawing data from the child course. It is this, I suggest, that causes most headaches for newbies, myself included. It is hard to get your head around a reversal of a cultural expectation.
I am suggesting that the documentation is easier to change than the program, therefore there is a need to develop a plainer speaking document. I am sure this discussion has happened before, but it has not really gone anywhere - but I suggest it should now. As more Moodles appear, more organizations would benefit from the use of metacourses and groups - but the documentation as it is, is not encouraging.
It's a familiar problem from many areas, and worth revisiting.
>Consider this, in a Client/Server network, the client draws data from the server...
Even then, it's not so clear cut. If you use X for remote access to a Linux machine, the server is on your own machine, the client is remote. The server effectively initiates the exchanges, so in that sense draws data from the client.
Being considered to old and too gray to actually learn anything about networks, I would have to bow to your superior knowledge. I would suggest, though, that the client/server relationship is based on reversible positions. The requesting computer is the client, the machine that is providing, serving, the files requested, is the server ergo: it does not matter what the actual name is, it is the action that is important. In short, names - schmames, the role is what counts, and that role changes depending on the action.
Martin Langhoff wrote the earliest post I have seen on it, January 17th 2007. Penny Leach did the coding, and a clever bit of coding it is indeed. Moodle Tracker suggests there were issues though dating back to February 2005.
However, the thing that concerns me is was there any discussion about the names of these things? What was the logic behind calling it a "metacourse" and having a "child course" supplying data to it?
It is interesting to note that one Darren Smith made mention of the possibility that the names would create confusion among the non-technical. I would suggest also that until this is cleared, the metacourse, which could be a seriously useful tool, is just going to be ignored by non-techie users.
I'll agree with you. The two most difficult concepts in Moodle are Metacourse and Groups/Groupings. A bunch of us here read the documentation on metacourse for more than a year before somebody finally experimented with it and figured out how it works.
Metacourse is, as you said, a very clever thing. Way to go, Penny!
I'll be glad to contribute more confusion to the documentation if you want help
- "child course" = "normal course" = "standard course" = "other course" Using 4 synonyms causes confusion.
- the idea of "inheritance" from a "child course" really won't work in anybody's culture
In case the version above is too difficult to follow (I wanted whoever the authors are to see what I've done), here's a clean version.
Elsewhere in the documentation, the dreaded Scenario 3, I have finally realized, does not contain crucial information. The reason that S 3 works is that the student is enrolled in both courses! In two "normal courses," a link to materials from one to the other will not work for a student who is not enrolled in both courses. So, as an extra added economy-sized bonus, here's a starter revision of Scenario 3.
As for the S3, have not got that far yet, still trying to get around S2... From the outset this also seems OK but the last sentence is an assertion that will need an example or two I think.