David Mudrak’s blog

1. Show your real face – Stephan Rinke and Michael  Tighe were right in their excellent workshop “In Moodle We Trust“. Your picture is important in an on-line environment. Recognizing the human face is one of the first things we learn as babies and it remains being important through all our life. Showing your real face express your honesty to the others and the fact you do not hide anything. It establishes the first contact with other people and it really helps if you know who is the guy giving the talk.
2. Tell where you are, what time it is and what the weather is – Helen Foster started her excellent keynote presentation with a very kind introduction of herself. If people come to your session at different time zones, from different countries and in different seasons, it is nice they can imagine you in a real-world context. Are you sitting in the office? Or giving a talk from the bed? Is there your family around? Is it snowing there or did you just come from surfing at a sunny beach?
3. Invest time into preparing the slides or demonstration – these kind people come to your session and they are going to spend an hour just listening to you – paying their attention to what you say. Give them clear sign that their presence is important to you and that you were preparing for it. Tim Hunt had a great idea using questions in the new Quiz module as a way to show his slides. It was clear he was carefully thinking about what to say and how to explain it in advance.
4. Bullet lists in presentation slides sucks – presentation is not a book. One picture, even a simple sketch drawn by your hand, may express more than dozens of the words.

But we had to celebrate and be glad, because this brother of yours was dead and is alive again; he was lost and is found.

– (Luke 15:31-32, NIV)

Yesterday, new workshop module has been committed into Moodle CVS HEAD and became a part of standard Moodle 2.0 distribution again. It’s been a long way to get into this stage but the real journey just starts. There are still some features to tune up and some known bugs to fix. The module seems to work pretty well, though. I had some real testing data from workshop 1.9 courses available (many thanks to those who could provide them) and from my point of view, the new UI gives clearer overview and more control over the activity.  However, my opinion does not matter – our good Moodle users will have to say what works for them and what does not.

Most of the legacy workshop features remained. There are two most significant differences. Firstly, new workshop puts two grade items into the course gradebook – a grade for submission (it est a grade that students get for their own work) and a grade for assessment (a grade that estimates the quality of the peer-assessment). Legacy versions of workshop automatically summed up these two grades. Nowadays, Moodle gradebook allows more way of aggregations. Teachers can set up their gradebooks to mimic the old behaviour, of course.

The second significant breakage of backward compatibility is in how the assessments of example submissions are evaluated. Example submissions are provided by teacher and students are expected to train the assessment process on them. Teacher can, for example, put an example of a really good work and a really poor one. In previous workshop version, grade for the assessment of example submissions was immediately calculated so the student got a feedback like “if you assessed this submission in this way, you would receive this grade for assessment”. In new workshop, evaluation of students’ assessment is more dynamic process. Teacher can use different methods of the grade calculation and change the input parameters of the calculation “on the fly”. Therefore, workshop module itself is not able to calculate the grade for assessment without teacher assistance. Instead, teachers just provide so called reference assessments of example submissions (where they express the quality of the submission) and such benchmark is then displayed to students. So students can compare their assessment with the teacher’s one but no grade can be calculated.

I hope the other improvements – namely the possibility to control the submission allocation for peer-assessment, manual switching of workshop phases, overall UI rework to make information intuitive and easy to understand – will compensate the lack of these dropped features. And who knows – maybe in some future version, we will find a way how to introduce them again in the new framework.

While the test site where you can play with the new workshop module is up and running, I am working on migration procedures to get current 1.9 workshop data into the new framework. I am following similar approach as Petr used for the migration of the Resource module. I personally call it Scavenger design pattern.

The basic idea of the migration is that all 1.9 tables are renamed using _old suffix and new ones are created as if we were starting from scratch. Then the upgrade script goes through all 1.9 records, transforms data into new formats and inserts them into new tables (marking old records as processed). Once finished, the new workshop core tables are fed up with the old data. Later during the installation, new workshop subplugins get created (allocators, grading strategies and grading evaluators). They find the old dead workshop tables and start picking data from them. At the end of the day, the new tables are populated with the old data.

Such a procedure requires that 1.9 workshop instances are at least in sort-of-well-defined-coma state. Therefore I started to fix the most critical functional and security bugs in workshop 1.9. So far the most important one may be that the workshop in Moodle 1.9.7 will push grades into gradebook as expected during the Synchronise legacy grades procedure. Big thanks to all patient users who help me with testing both new features and fixes.

It was one of that discussions when people prefer leaving the chat room before they say something they would regret later. The Pandora’s box was opened by an innocent question on the recommended procedure to customize a contributed Moodle plugin. The discussion turned into a hot topic on what the current source code management system (CVS) gives to us and what we and our contributors could gain (and lose) from switching the Moodle CONTRIB repository to git.

Imagine you have clients who pay you for implementing a solution based on a contributed Moodle plugin. The quality of the Moodle contributed code varies and some sort of the code review and clean-up is strongly recommended before using it at production server. The contributed code may contain critical security holes and such plugin may easily become an open gate to your server with a big bright sign “Welcome Attackers!” So you have reviewed the code, fixed several obvious bugs and improved the features a bit as requested by your client. And – now what?

Of course you want to deploy your changes to the client’s server – as soon as it is tested  (or at least it does not produce any PHP warnings ) And you, as a follower of the open source spirit, want to contribute your changes back to upstream. So you send your patches to the original component’s maintainer to be included in CVS. Sounds good. In a perfect world it would work with no problems. But the humans are not dead yet and things tend to get complicated. Also, some objections against the real benefits of this procedure were raised. Let me list some issues that may influence this contributing back to upstream.

1. The maintainer does not respond. Such things happen. You can ask the CVS administrator to give you write access and become a maintainer. Do not do this if you know/feel you would not have time to do it responsibly. Remember the lesson #5 from the Eric Raymond’s famous essay: “When you lose interest in a program, your last duty to it is to hand it off to a competent successor.” It’s better if it’s known there is no maintainer than if people think they can rely on you. On the other hand, do it if a silent voice inside your mind whispers that it’s the job you always wanted to do. It’s both nice and good thing to spend your life on.
2. The maintainer does not agree with your improvements. Then it’s time to discuss things. Summarize the issue and open the topic in Moodle forums. Listen to the maintainer’s arguments. Maybe he/she has some further plans with the module? Who else can profit from your changes? Try to not to fork the product unless there is a chance to reach a consensus.
3. The rubbish can get into the code after you reviewed it. Yes, it can. You must remember the state of the code when it was reviewed. Source code management software calls such signs as “tags”. You shall tag a certain point of the source code history and review exactly that point. Then you know what version is sort of safe to be deployed. Also, you can focus on the changes that came after this point later when you review the code again.
4. The maintainer does not understand your fixes. Some say that simply sending the patches to the maintainers is useless as they do not spend any effort on learning from it. I personally do not agree with this. However, I can see the importance of educating the contributors. If the contributed code contains a security bug which is exploited, who is blamed? The administrators? No,  they have always been against this community thingie. The original author? No, nobody knows him/her. Moodle itself? Sure – it’s all Moodle’s fault! And that’s not fair.

All these have nothing to do with the SCM software itself. It is about responsibility, communication, constructive peer-reviews and developer etiquette. However, I think that the features and the characteristics of the SCM may significantly help with sorting out the issues discussed above or with not running into them at all.

Switching Moodle CONTRIB area into a cluster of separate git repositories emerged as an idea during the discussion. The nature of git – a distributed versioning system – seems to perfectly fit into the nature of our contrib, the hive of really interesting features and ideas. Contributors may come with their own trees of source code and the comparison of such two trees is easy. If the maintainer stops responding to the community questions and proposals, his/her tree becomes quickly obsolete and the community may start to prefer some other tree (if such is available). The pull-based model of the the maintainer-contributor interaction requires the maintainer pays attention to the patches to be included and hopefully learns from them. On the other hand, the contributors have to keep their trees up-to-date with the recent versions of the upstream code if they wish it is included in the maintainer’s tree. The point is, with git, everybody can easily become a maintainer of his/her own clone of the product. They have to gain the respect of the community members by keeping the high quality of their version. And remember – respect is everything.

I do not think we should switch to git-only at the moment. Let us give git a chance and see what  Moodle contributors think. To help them with their first steps, I summarized my personal experiences with using git in Moodle development into a sort of tutorial at http://docs.moodle.org. You are welcome to review it and/or put comments with your own solutions.

commit eb123debc6279c0e7fe92d7cb8979f4db651a46c
Author: skodak <skodak>
Date:   Thu Oct 8 22:34:34 2009 +0000

MDL-19474 One year and a half ago we started designing
and implementing our new database abstraction layer
which included brand new moodle native drivers.
Today we are finally removing old legacy drivers
that were still using adodb internally. From now on
the adodb will be used only in some authentication
and enrolment plugins, we are probably going to
drop adodb there too later in 2.x.
Thanks everybody who helped test and improve our
new drivers, even bigger thanks to all the great
developers who created ADOdb!

One of the core Moodle developers put an almost innocent note into our Jabber chat recently and I can’t stop thinking about it. And no, it’s not about hating Google. The Quiz module is one of the most advanced activity module we have in Moodle. It seems to be popular and often requested by the newcomers. It even may be considered as a feature that helped Moodle to become first class LMS. I personally use it sometimes as a teacher, too. It’s just so quick and easy to prepare a question bank and let students to prepare themselves for the evaluation quiz. Yes, I trivialize the issue here. I know it’s not so easy to prepare valid and relevant questions, analyse the responses, modify the questions with low discrimination capability etc. But honestly – how many teachers do this?

Conditional activities subsystem has been committed into the repository and is one of the Moodle 2.0 highlights. It enables course designers to restrict the availability of any activity according to certain conditions such as dates, grade obtained, or activity completion. The world has been waiting for this feature since ages. And Sam really did a good job – kudos for him!

Now, the little worm in the back of my mind starts to whisper: Shh! Wait! This all starts to smell like a SCORM too much! Is not it a little bit strange that the automatically evaluated Quiz is so matured, while the Forum, the essential tool for constructivistic online courses, still lacks such essential features like to subscribe to individual threads, to mark (or tag) the thread as closed, to collapse the parts of the displayed threads etc.? When did we last improve our good old Forum in a really significant way? Why do we not support real cooperation of the students? We are still not able to group students into a team and grade the team work instead of individual students, for example.

I am all for these Moodle 2.0 changes, portfolios, repositories, database layers, webservices, output rendering frameworks, core architecture clean-ups and refactoring. Moodle becomes really nice cathedral in many areas. I only hope I can still start my Moodle presentations saying that the Moodle development has been always driven by a solid pedagogical theory and by its users’ needs. But also, Moodle has always helped teachers to get constructivism into the class simply because using Moodle forced teachers to think in terms of students activity. Not only the Moodle development is driven by teachers’ needs. Moodle learns teachers how to teach in a different (hopefully better) way. I consider this the most important face of Moodle and I wish it would not be put into the shadow in the light of all the bright and glittering cherries of the future release.

As Galadriel said – the world has changed. Just day after Microsoft submitted driver source code for inclusion in the Linux kernel under GNU/GPL license, they have released Microsoft Live Services Plug-in for Moodle – again under GNU/GPL. It seems to me that the Moodle worldwide popularity together with the strict conditions ruled by GNU/GPL forced the software gigant to the next step on their relationships with the open-source movement. NetworkWorld.com comes with a nice overview of Microsoft/open-source milestones (including their patch to ADOdb library for PHP).

As a teacher I know from my own experience that the best method to understand something is to try to explain it to somebody else. It really works. Often, I realize some new important details or concepts or relationships while giving a lesson to the class.

So, when I wanted to sort out all my ideas about the Workshop random allocation method, I decided to document it so the teachers (and students, too!) know how the assignment is done and what results they can expect. I have described the method of random assigning submissions for peer-review and published it in the Workshop forum at moodle.org. If you have a minute, please check the PDF attached to the post and leave a comment in the forum. Thanks in advance!

I am stuck on random allocation subsystem for the new Workshop module. What looks like a trivial algorithm at the beginning, turns into a complex computation once you take various aspects into account. I have spent literally hours and hours by sketching squares, circles and arrows between them trying to discover all possible situations the workshop activity can get into.

In the most trivial case, everything is clear and easy. Say you have ten students in your course and you want each of them to review and assess three submissions. So you just randomly select three submissions for each student and you are done. If you want, you may order the allocator to ensure the self assessment. So it simply adds yet another allocation for every student, setting reviewees to the students themselves. Easy, ha?

Now, groups and groupings would like to play the game. Still no big issue, though. From my point of view, “Separate groups” mode is for those situations where you want or need students being enrolled in the single course but you do not want the groups to interact in any way. Ideally, students from different separate groups should not even know about each other. On the other hand, teachers use “Visible groups” mode, when they want some sort of group work support.

So, if the workshop is in the “Separate groups” mode, the allocator just have to be careful to select a reviewer of a given submission from the same group as the author is from. What if the author is in several separated groups? If I follow the precedent of the Forum behaviour, I can require the author’s submission must belong to a single separate group (like a post in a forum). As every user is allowed to have one submission per workshop at most, this results in that (s)he can’t submit into other separate groups (s)he is member of. Can this be an issue? Probably not – typical students are not expected to be members of several separate groups. But the software design is not about typical cases only. It must work in very rare situations, too.

If the workshop is in the “Visible groups” mode, the allocator shall select reviewers from all available groups. It shall try its best to have the reviews allocation balanced. Ideally, if your paper is going to be reviewed by three peers and there are three visible groups in the workshop, the allocator should pick one reviewer from each group. Advanced teachers could use this feature to get more objective assessment.

So far, I have assumed that reviewers are the same people as authors – it est “students” (peers) in your course. This has always been a must for the Workshop module. In Workshop 2.0, this is to change. There are two capabilities to control which role or roles can submit and/or assess submissions. By default, the legacy role Student is allowed both to submit and to assess others’ submissions. But you can localy override the permissions and – voilà – workshop behaves as an universal peer-reviewing system to be used as a conference management system, for example. So, some of your course participants (let us say Students) can be allowed to submit their work and others (for example Non-editing teachers or Assistants) are responsible for the assessment. You can have a course with 1000+ students divided into small groups (randomly or according their preference) and a cohort of reviewers, each of them having a group of students in charge. In this scenario, the random allocator is responsible for allocating submissions for reviewers in as balanced way as possible.

Other settings like the activity “Default grouping” or “Available for group members only” make the situation even more complicated. So, what looked like a simple game with a die, now has a thick book full of complex rules, tables and strange diagrams…

I have a working prototype of new feature in Workshop 2.0 – manual allocator. As I have described in my recent blog post, manual allocator is a Workshop subplugin that allows teacher to allocate submissions to the selected peers for review. The user interface may be a bit unusual at the beginning. However, I think it presents all relevant information in an understandable way once you realize how it works.

To demonstrate the new UI, I installed wink (thanks for the tip, Helen!) and prepared a screencast of the user interface (my first screencast ever!). Now I am awaiting for some feedback from the community. If they like it, the similar layout could be used consistently in the whole module.

The screencast of the manual allocation user interface