A few months ago, I was intrigued by a presentation by Dan Pink, an American public speaker. Here is a version of that presentation (and there are a few similar presentations around, including a TED talk).

In the presentation, Pink claims that extrinsic motivators, specifically financial incentives (bonuses, raises, promotions, stocks,…), can be counter-productive to the goal of encouraging workers in certain circumstances. In the presentation, Pink refers to studies at MIT, so I went searching for publications for these studies and found Ariely (2005) and Awasthi & Pratt (1990).

While people can be motivated by financial incentives, the studies found that financial incentives can reduce performance for tasks involving a cognitive component. Software development certainly involves cognitive tasks, in fact programming is about as cerebral as you can get.

So if money doesn’t work, what does? Pink’s thesis is that employees will be more productive when they have a sense of:

• autonomy,
• mastery and
• purpose.

Pink refers to cases at Atlassian and Google, where employees are reported (in the media) to receive many perks. I’ve been to Google, and while I did enjoy the free food, the work environment was certainly not anarchistic, in fact it seemed quite ordinary on the inside. What Pink emphasises is that these companies offer a degree of autonomy to their workers, that employees have the potential to develop professional masteries for their current job and for future jobs, and that employees are able to see a sense of purpose in what they do day-to-day.

Developer Incentives at Moodle?

Some aspects suggested by Dan Pink were already in place at Moodle, but some have been added or enhanced in recent months. I will describe how we offer a sense of autonomy, master and purpose to members of the STABLE team at Moodle (the devs who work on the existing releases of Moodle).

Autonomy

Apart from being a relatively relaxed working environment, there are some specific differences that may set Moodle apart from other development offices.

• Devs choose, set-up and maintain their own development environments. Code meets at the repository, but how it gets there is up to the developer.
• Using the Scrum framework, devs choose issues they will resolve from a prioritised backlog of issues. This ensures that the highest priority work gets done, but devs have a sense of ownership over, and responsibility for, the issues they choose.
• After every two sprints (sprints are typically three weeks long), devs have a week to work on a project of their own choosing. The projects have to benefit the Moodle community, but is open to interpretation by the developer. This means that one week out of every seven, the developer is completely autonomous.

Mastery

Mastery is an area we could be working more on, but there are a few initiatives in place at Moodle.

• Devs can nominate external training courses and are supported to attend.
• Devs nominate areas of interest in Moodle and are allowed to specialise in those areas.
• Devs receive in-house productivity training . There are also irregular presentations on development related topics related to the current focus of work (for example, in-code documentation writing, Web services, etc.)

Purpose

Purpose is something that Moodle has a lot of. Moodle allows many people to access education, some of whom would not be able to do so otherwise.

In saying that, it is easy to lose sight of that purpose when devs are focussed on lines of code while reading the grumbles of users on bug reports.

It is important t0 regularly remind developers that there is a community out there and they really appreciate the work devs are doing. We have, in the past, dragged devs to a Moodle Moot, where there is a lot of back-patting. We are hoping to do that again this year.

If you are a member of the community and wish to express your gratitude, please do so. Send me an email or post a message on the Moodle forums. It will really help.

Do these incentives work?

From my perspective, I would have to say “yes” – encouraging a sense of autonomy, mastery and purpose does help developers, their progress, as well as the general working environment. It’s hard to quantify the effect of making these aspects more obvious to developers, but I have noted some improvements since we have.

• Our turn-over of staff is low. The devs seem are content and passionate about their work, particularly when they have a chance to work on what they are interested in. This really helps avoid slacking off when it comes to doing “more of the same”; with sufficient variety, developers are quite happy to switch to unstructured work and then back to structured sprints again.
• General productivity is higher and being maintained. The number of issues being led through our process has increased and that is a good sign.
• The STABLE team is producing some significant contributions to Moodle, and not always in the same way. We had a very colourful show-and-tell session last Friday with some very excited developers (including devs from outside the STABLE team). Here are some examples of what was put on show…

An optimised view for the Gradebook (Rajesh Taneja)

There are a number of issues relating to the usability of the Moodle Gradebook, which can become unwieldy. With some simple modifications, the Gradebook becomes a much more usable space.

• See MDL-25544 for details.

Previews for Database activity uploads (Adrian Greeve)

Currently, uploading data into a Database Activity provides little feedback or control. Adding in a preview, with field matching, allows easier uploading.

• See MDL-37503 for details.

A Moodle development kit (MDK) (Frédéric Massart)

The MDK automates many regular dev tasks including Git operations, adding information to issues on the Moodle Tracker and automation of site instantiation and population with dummy data.

This project has been quite a collaborative effort and is still growing.

• Documentation is available on the Moodle Dev docs.
• The MDK can be accessed from Github.

Technical debt is accumulated future work that has amassed as the result of decisions made during the development of software (or more generally during the development of information systems). The term was coined in 1992 by Ward Cunningham, who realised that as soon as software is created there is an element of deferred work, which can be equated to “going into debt” (Cunningham, 1992).

Analogously, technical debt is often equated to financial debt, such as a loan. The value of a technical debt is not dollars, but the cost of the time needed to rectify problems. As software is created, compromises are made between delivering a flawed but acceptable system now or delaying and delivering a superior system later. These compromises result in a backlog of work that needs to considered before a future release.

Technical debt comes about when developers create less than ideal code. Fowler (2009) suggests that developers can do this deliberately or inadvertently. A developer can deliberately decide to use a quick-and-dirty solution now with the intention of replacing this solution with a better one later. “I’m not sure if that database query will scale, but I’ll write a TODO to fix that later.” Developers can choose to sacrifice non-essential software elements by failing to write documentation, avoiding creating reusable abstractions or failing to follow coding standards. Alternately a developer can inadvertently introduce problems into the code. This can happen through forgetfulness as deadline pressure builds or simply when the skill required to solve a particular problem exceeds a developer’s technical experience. “I’m not exactly sure how this code works, but I’m going to reuse it now as it seems to solve the problem.” This approach is sometimes referred to as Cargo Cult programming (McConnell, 2004).

Fowler also suggests that technical debt can be introduced through behaviour that is either reckless (“I don’t know how significant this is but I don’t have time for it now.”) or prudent (“The cost of introducing this now will be greater than the cost we will incur by delaying our release.”).

By crossing these deliberate-inadvertent and reckless-prudent dimensions as axes, four quadrants appear; these quadrants can be used to categorise the sources of technical debt.

Fowler’s technical debt quadrants

As no system is perfect, technical debt is something that cannot be avoided. It is something that needs to be managed rather than ignored.

Is technical debt bad?

Technical debt, like financial debt, is not all bad. Any debt is doomed if there are no means to repay it. “Few of us can afford to pay cash for a house and going into debt to buy one is not financially irresponsible, provided that we know how to pay it back” (Allman, 2012). Projects need to consider the level technical debt they are capable of supporting and be aware of their technical debt at all times, ensuring that it does not exceed this level.

If a software project accumulates more technical debt than can be “repaid”, the quality of the software becomes poorer. If lacking quality reaches a level that is obvious to users, this can affect their decision to use that software in future.

What is “open technical debt”?

Open technical debt is the technical debt accumulated by an open source project. To understand it you have to know that open source projects differ from commercial developments in terms of code ownership, project management and in the philosophy that motivates the project.

Open source software is freely given to a community of users and that community is invited to provide feedback to the project to guide its future. Compared to a software system created by a commercial vendor, where the code ownership is simple, in open source projects the community owns the software and benefits from the effort they invest.

Open source projects vary in scale from small projects, involving a small number of loosely organised volunteer developers, through to large-scale projects, that are bigger than many commercial software undertakings. The project I am involved in is Moodle, which involves hundreds of developers and has many thousands of registered sites with over 60 million users worldwide. The project employs 25 full-time employees and works with a large network of commercial Partner organisations who deliver services to the community and help support the project financially. Managing such a project is often difficult as there is no single product owner who you call on to make decisions and set priorities.

When technical debt accumulates in an open source project and impacts on the quality of the software, it is obvious to the community. But this is balanced by the community’s sense of responsibility to fix these problems, improve the quality of the software and pay off that technical debt.

In open source projects, strengths can also be weaknesses. The potential of a large community and large number of developers can lead to powerful software, but left unchecked it can also lead to technical debt. If that debt is not recorded and “paid off” it could lead to the downfall of the project.

Where does open technical debt come from?

It is important to be aware of where technical debt is coming from in a project. Using Fowler’s technical debt quadrants it is possible to categorise the sources of problems in open source code.

You might think that most technical debt in an open source project is the result of reckless developers contributing code with inadvertent consequences to the project as a whole. In fact this is quite the opposite of the behaviour that an open source project elicits from developers. When someone contributes code, their code becomes part of the open source and is open to scrutiny by all. Metaphorically, their dirty washing is being aired for the entire world to see. If a problem is later found it is easy to track it back to a change made by a specific developer. This tends to lead to well-conceived code with a sense that reputations are on the line.

As the person responsible for triaging issues as they are reported for the Moodle project I know every freckle and bump in its complexion. On a regular basis I track the sorts of issues that are left in our bug tracker and a large chunk of these are unfulfilled improvement requests. When releases are finalised, decisions are made to “draw a line”, even though improvements could be made. So the technical debt of the Moodle project, as an example of an open source project, is predominantly in the prudent-deliberate quadrant with lots of ideas for making the software better being known but not acted upon.

Technical debt quadrants in open source

Does this differ from a commercial project? Well I can’t say for sure, but I suspect it does. I would say that closed source software lacks the pressure that openness creates. Also, when the priority setting falls to a single decision maker with commercial deadlines to meet, I think that technical debt would shift more to the reckless side of this field. But then, I’m biased.

Avoiding and embracing open technical debt

While accepting that some technical debt is unavoidable, there are ways that it can be minimised.

Openness of flaws

Having an open bug tracking system allows anyone to see what bugs have been reported and what improvements have been suggested. This means that the extent of the technical debt of a project is on display to all. Being open in this way creates incentives for developers to avoid creating technical debt in the first place, and to reduce technical debt in the long-term. It also shows the community that work is being done in a way that follows defined priorities.

Agility

Following agile software development practices allows developers of an open source project work together to fulfil the priorities of the project. As priorities shift (and they do when you are responding to a community), being agile means that developers can respond quickly. In fact I can’t conceive of an open source project being managed any other way.

Review

Contributed code in an open source project is not automatically accepted. Before it is integrated with the codebase it usually has to satisfy experienced developers involved in the project. This is certainly the case at Moodle where all code goes through at least three levels of review before it is integrated into rolling releases and even more before major releases. When this is done politely, as well as ensuring software quality, this also helps to assure contributing developers and instil a sense of confidence.

Modularity

Once any software project grows to more than a trivial size, it needs to be modularised. In open source this is especially beneficial for two reasons.

• Modularity provides focus points for developers who want to contribute to a project without needing to understand the entire codebase.
• Modularity allows a project to designate code as official and unofficial. Official code is what is distributed to users as the core project code. Unofficial code can be plugins that individuals have written. Technical debt can then be measured against the official core code while keeping the potential “high-risk” debt of unofficial code “at arm’s length”. That’s not to say that developers sharing plugins should not be supported and recognised.

Willingness to deprecate

As a project develops, changes will occur over time. Often modules become neglected, particularly if no one from the developer community has an interest in maintaining that module. When this happens, the community has to recognise the state of the module and deprecate it. Deprecation is like writing off technical debt; while it comes with a loss of functionality it also notionally frees up resources to focus on other parts of the project.

References

Allman, E. (2012). Managing Technical Debt. Communications of the ACM, 5(5), 50 – 55.

Cunningham, W. (1992). The WyCash portfolio management system. In OOPSLA 1992. http://c2.com/doc/oopsla92.html

Fowler, M. (2009). Technical debt quadrant. Retrieved from http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

McConnell, S. (2004). Professional Software Development. Boston, USA: Addison-Wesley.

What are analytics?

Analytics is a relatively new term; so new, in fact, that my spell-checker doesn’t recognise the word. It’s a real word, though; it must be as there is a Wikipedia entry. The term has been popularised in the online world by Google who offer analytics about your website so you can see details about your site visitors.

But what does the term analytics mean for education in the context of an LMS? At a panel session during the aforementioned moot, the topic was raised and this was the first question asked – what are analytics? One of the panel members, Alan Arnold from the University of Canberra bravely offered a definition: “Analytics are any piece of information that can help an LMS user do their job.”

Thinking more deeply about the subject, I propose that LMS analytics are useful calculable quantitative gathered collections of information, based on the activities of users within or around the LMS, presented in forms that allow decisions leading to improved learning outcomes. (Quite a mouthful.) There’s lots of information about a user that can be collected in the LMS. The trick is to tease out and combine the useful bits and present them simply.

So the question is not so much “what are analytics?” but is instead “what analyics do you need?” and perhaps “how can you get them?”.

What analytics do you need?

Not all analytics are relevant to all users. If you are a teacher, you’re probably thinking about getting information that can allow you to teach better. If you’re a policy maker at an institution, you’re probably wanting to know how successful your teachers are with their students. Bet let’s not forget the students as well; there is information in the LMS that can help them also.

On the plane back from the Moot I decided it would be worth starting a catalogue of all the different analytics that could be captured in Moodle. At lunch I threw these at Martin and we cranked out a few more.

Analytics useful to Students

Progress

With an LMS, it is possible to achieve regular assessment within a course based on a rich set of finely chunked multi-modal activities, and while this can lead to deep learning, it can also be overwhelming for students. It is, therefore, useful for a student to know where they are up to in a course and what they have to do next. Students who use short-term planning tend to be more successful; they just need a quick snapshot of their progress.

Relative success

Deep learners are more successful and deep learners are characterised by meta-cognition about their learning. Providing analytics about their relative success can allow students to know whether they are on track of if they need further exposure to a topic. Relative success can also be used to introduce a competitive element into a cohort, which some educationalists recommend.

Opportunities to interact

If students are studying in isolation, it may not always be apparent when there are chances for them to interact with peers or teachers. Determining the level at which a student is interacting could be seen as an analytic that can be used to direct them to opportunities for communication and collaboration.

Analytics useful to Teachers

Student participation

In an online world, it is more difficult for a teacher to know which students are participating and those needing a push. Students can fail to participate for numerous reasons, usually valid ones. Sometimes a student may need to be encouraged to withdraw from a course and re-enrol later. Where analytics can help is in the determination of the timing of when such decisions need to be made. That’s not to say that such information needs to be complex; it could be as simple as “traffic light” coloured icons next to a list of names of students, ordered by risk.

Student success

Assuming a student is involved, a teacher also wants to know how successful they are. This could be the product of assessment and views of resources. If students are progressing through the course with unsuccessful results, then they may need to be encouraged to re-expose themselves to a topic within the course before progressing further.

Student exposures

Moving away from a course modality where “one size fits all”, it is useful to know how many times a student was exposed to a topic before they were successful. This is a differentiating factor among students in a cohort. If students are progressing with few exposures, perhaps they are finding the course too easy, perhaps even boring, and may need to be challenged further. If students are requiring numerous exposures before they are successful, then perhaps alternate presentations of a topic need to be created to suit the learning preference of particular learners. Such an analytical tool can assist a teacher to deliver learning at an individual level.

Student difficulty in understanding

Through an analysis of exposures and assessment results, it may be possible to determine which topics, or areas within a topic, students are finding difficult. This may indicate areas that need to be revisited in the current delivery or enhanced in a future delivery of the course.

Student difficulty in technical tasks

When students are undertaking learning, the last thing they want is to be stifled by an inability to express their understanding because of by the way a course is set up within the LMS. Students patterns of use within the LMS may indicate they are having such difficulties, and a teacher can be alerted to take action.

Feedback attention

Teachers take time and spend effort creating feedback for students as a reflection of their understanding. It is useful to know which students have paid attention to such feedback, and which students may need to be encouraged to do so. Going beyond this it may be possible to deliver information to a teacher about the effectiveness of their feedback on students’ understandings as reflected in subsequent assessment.

Course quality

In several institutions that I know of, part of the measurement of a teacher’s effectiveness is judged by the quality of the courses they are producing within the LMS, based on a set of metrics. Such measurements can be used for promotions and to drive the development of PD activities. If such metrics can be automated, then analytics can be produced for teachers that encourage them to improve their course by increasing the richness of their resources, improving the quality of their activities, including more activities of different kinds, providing more opportunities for students to interact or collaborate.

Analytics useful to Institutions

Student retention

Analytics can provide more information about students than simple pass/fail rates. Analytics can help determine when students may be at risk of failing and in which courses this is more likely to happen. Such analytics can help an institution to send resources to where they are needed most and to plan resources for the future.

Teacher involvement

There may be ethical implications in monitoring teacher involvement in a course as it is akin to workplace survelance. However there is information in an LMS that can be presented in a useful way in relation to training and promotions. It might also be useful to anonymously tie in a teacher involvement analytic with other analytics to find correlations.

Teacher success

As well as looking at success in terms of pass and fail, it may also be possible to determine where teacher interventions have encouraged students to achieve beyond their expected outcomes.

Relative course quality

Clearly not all courses are equal, but how do you determine which is better. There have been a number of attempts to manually measure aspects of a course such as accessibility, organisation, goals and objectives, content, opportunities for practice and transfer, and evaluation mechanisms (Criteria for Evaluating the Quality of Online Courses, Clayton R. Wright). If such metrics can be automated, then analytics can be created with can reflect the quality of courses. Such metrics could also be fed back to teachers as an incentive to improve their courses.

How can you get them?

So, you want these analytics, but how can you get them? Some of them may already be accessible via various mechanisms, however I think we still need to work out how best to draw this information together in a simple way for specific users.

Moodle currently logs most actions that take place within the LMS. It is possible to view log reports, but they are limited to interaction in terms of activities within a course.

There are a number of existing plugins and extensions to Moodle that attempt to provide analytics to users. Among these there are a batch of report generators, many of which are quite configurable.

• The Configurable reports block plugin is a configurable system that allows reports to be created and used by various roles. It may be a good model to use to start a set of standard analytics reports within an institution.
• The Custom SQL queries report plugin allows an administrator to run any query against the database used by Moodle. It’s clearly flexible, but not something you can put into the hands of all users.
• The Totara LMS is a rebranded, extended version of Moodle. One of the aspects built onto the standard Moodle install is a reporting facility that provides customisable reports to users of different roles.

There are also a number of blocks available and in-the-works that attempt display analytical information to users.

• My own Progress Bar block shows a simple view of course progress to students and an overview of student progress to a teacher.
• The Engagement analytics block is currently in development, but I have seen a demo of this and it looks good. now available. The block allows a teacher to specify expected targets for students then presents to teachers simple traffic-light icons next the names of students at risk.
• The Course Dedication block estimates the time each student has spent online in a course.
• The Graph Stats block shows overall student activity in a course over time.

Simple queries

A lot of these analytics can already be queried or calculated from the data already stored in the Moodle databse. The Report plugin type is available for presenting pages if information to users and is applicable for analytics. The Block plugin type is available for simple, compact presentation of information. Both of these APIs can present different displays to users with differing roles.

New logging

Currently, most of the logging that takes place in Moodle ends up in a single table. For simple lookups, this is not a problem, but for complex conjunctive queries, working with a large log table can hog the resources of a server. The current system of logging is likely to be a target of future work at Moodle HQ so that both the recording and retrieval of information can be achieved efficiently.

Measurement of a number of the interactions required for the analytics above is not possible using the current log and module tables. Viewing the recording of user interactions from an analytical perspective may lead to new information being captured for later analysis and presentation.

AI or user optimised queries

When you have a wealth of user interaction information available, why stop at the limits of human developers.

• Genetic algorithms, neural networks and other heuristic approaches may reveal newly refined analytics or even new analytics altogether.
• Crowd sourced optimisation of analytics reports may allow a collective intelligence to refine analytics so that they are even more valuable and reliable.

Analysing analytics

Providing analytics allows us to study the impact that analytics can have on the users who view them. This allows general research questions such as “what analytics promoted better learning, teaching or retention?” Also, specific questions can be asked about individual analytics, such as “does feedback attention have an impact on learning outcomes?” Queue the savvy educationalists…

A few years ago, while attending a Moodle Moot, I realised that the Moodle community had a serious underdog complex. The mere mention of Blackboard raised emotions reminiscent of an Orwellian hate rally. But even then, I had the impression that Moodle was taking hold and becoming more commonplace, and I was forced to consider: what happens when Moodle is no longer the underdog?

When I first started working at Moodle, I had to explain to my friends and family what Moodle was. Some of my former university-related colleagues knew about Moodle, but weren’t sure how I could be working for Moodle.

Of late, I’ve been frequently encountering random people who know what Moodle is (and have opinions about it), which gives me cause to believe that Moodle is no longer just a small competitor in the LMS game.

• While at the recent Australian Moot, while in a hotel elevator I was wearing my Moodle shirt; I was asked by another guest if I was here for the “Moodle Conference”. I said I was and asked if she was also. Apparently she was not, but had heard that the conference was happening in town and went on to tell me that her school was using Moodle and she thought it was great. All this in a few floors.
• At a barbecue with my son’s swimming club, I was asked where I worked. When I mentioned Moodle, several people spontaneously started sharing their Moodle experiences – submitting work online, discussing ideas in forums and monitoring children’s homework. The scientist in me made me sit back and gather evidence, which turned out to be positive.
• I’ve had similar fleeting experiences on trains, at church gatherings and with old school friends.

It’s even more surprising to hear random people mention Moodle when schools and universities usually re-brand their instance of Moodle, calling it “Study Desk” or “iLearn” or “Wattle” or something else. People are starting to recognise that the underlying system is Moodle, which is the same system their colleagues are using elsewhere.

In truth, Moodle has been mainstream for some time. In some parts of the world, Moodle has reached saturation at the university and vocational training levels. Even Moodle’s competitors are recognising this and attempting to buy into Moodle.

Why has Moodle become mainstream?

There are a number of reasons I can think of that have caused this shift in status.

• Teachers want the LMS to do what they want it to do. Moodle, with it’s treasure-trove of plugins, allows them to do more of what they want, and there’s always the potential to create another plugin. Moodle gains much of its strength from the Developer community.
• People are becoming more accepting of open-source software. With the successes of Firefox, OpenOffice and others, people are starting to see the value in such software and the quality a community effort can produce. Talking to people involved in other open-source projects, I know that Moodle is one of the most organised projects around. The structure and funding model set up for Moodle is very sustainable and ensures Moodle will not disappear for many years yet.
• Being open source and free, Moodle is making inroads into smaller educational institutions, and this is something commercial LMSs have not been able to do. Not being pigeon-holed in higher education means Moodle is becoming more of a household name.
• Moodle is open about its flaws. In my position I can claim to know all the blemishes on the face of Moodle, but you can see them too at tracker.moodle.org. Users now realise that no software is bug free and when a commercial product is presented to them as flawless, it is greeted with scepticism.

Perhaps the biggest reason Moodle is shifting into the mainstream mindset is because of the community sentiment that surrounds it…

Satisfaction

This is a bit tongue-in-cheek, but it is clear that public sentiment about Moodle is high.

This is not infallible evidence, but I dare you to try this test with other LMSs.

Hopefully it will be of some use for the upcoming Ireland and UK MoodleMoot 2012.

By the way, our address for postcards is 1/224 Lord St, Perth 6000, Australia.

New SERIOUS staff

Since I have arrived at Moodle HQ there has been a push to increase the number of developers. As Moodle popularity grows, so does the need for maintenance and new feature development. When I arrived in April there were nine employed developers, six more have been added and two more are arriving in coming months. My hope for the near future is to have two teams working on stable development and a third on new features development.

But Moodle is not just about development and in recognition of this, two new roles have been added to the HQ complement.

As a sign of the determination to get things right, we now have a Test Manager. Tim will oversee testing during development and release processes. He brings a great deal of experience as a tester and developer, and will improve testing processes so that the result is serious testing and a more solid Moodle codebase.

Tim the Test Manager

Barbara brings experience working as a graphic designer in universities, including work with Moodle. She also has teaching experience (in design), so she is highly qualified. But beyond that, she brings a level of style that Moodle has been lacking for some time. A quick look at moodle.org will demonstrate that developers are not very artistic. Undoubtedly the benefit of Barbara joining us will be Moodle – with more serious style.

Barbara the Designer

New SERIOUS release schedule

It took a long time for Moodle 2.0 to come to fruition. This was a significant step forward (one that many Moodle users are still taking). Afterwards it was decided that it is not necessary to wait for the a complete release roadmap to be fulfilled for each version. Instead, a timed release schedule is now used to create a greater sense of certainty. Part of my role is to “bulldog” developers, to ensure that major releases (such as 2.1 and 2.2) happen on time. We now have major releases every six months in June and December, and since 2.0 releases have happened on time.

Moodle also has minor releases (AKA point releases), such as 2.2.1, that occur between major releases. The main reason for minor releases is to send fixes to security issues out as soon as possible. This might sound like a bit of a ‘number’s game’, but for Moodle Partners and the Moodle community, keeping their Moodle sites up-to-date is a ‘big deal’, and we want to do what we can to help them.

Up to now, minor releases have been completed irregularly when a number of security fixes have come about. But now, we’re getting even more serious. In order to assist in planning upgrades now and into the future, minor upgrades are scheduled to take place every two months, offset by one month to major releases (January, March, May, July, September and November).

For more details, see the General release calendar.

New SERIOUS documentation

Moodle documentation has, in the past, been fragmented and inconsistent. For new developers, the task of discovering how to work in Moodle as a coding framework has been a daunting one. So to remedy this, HQ developers have put down their development tools to focus on documentation. Starting with core APIs, descriptions are being added and updated to create consistent codebase documentation. This is being linked to Dev Docs wiki pages, again in a consistent manner, to provide developers outside Moodle HQ with the information they need. A planned future addition is consistent ‘getting started’ documentation for each plugin type (currently there are 32 to choose from).

Staying SERIOUS

One of the main focus areas leading up to the release of Moodle 2.3 will be accessibility. With the help of staff from North Carolina State University in the United States, including Greg Kraus and Glenn Ansley, a solid list of accessibility issues has been compiled. Together we will work through these issues to create a release of Moodle that will be accessible to more people. If you would like to be involved in this effort, please help where you can.

As well as this, you can anticipate improvements in usability, specifically file handling, coming soon. (I bet you’re holding your breath.)

I gave a presentation at the Australian Moodle Moot (MootAu11) and I’ve had a few requests to share that presentation since, so I thought I would flesh out my presentation into a more digestible form.

Book information: ISBN : 1849512167 Publishers Book Page Moodle Books page Moodle receives a 5% royalty on all Moodle books published by Packt. To receive 20% off when you buy this book or eBook direct from the publisher, enter the discount code MoodleTopEx20.

I’ll start at my number ten and work my way to number one.

10: Course Contents block

Click to enlarge

The Course Content block creates an automatic table of contents for a Moodle course. I’ve often seen instructors doing this manually.This is a handy tool when course pages grow long.There is only a version for 1.9 available. In Moodle 2.x there is the Sections block, but it does not show section titles like the Course Contents block.

Author	David Mudrák
Type	Block
Compatibility	1.9
Links	M&P Entry Documentation Download

9: Translation block

Click to enlarge

The Translation block allows you to translate strings into multiple languages, right in Moodle.Application ideas: Language classes Common words in multiple languages (Sudoku, café) Crazy re-translations Translating Moodle strings There are numerous similar alternatives, but this block works nicely.

Author	Paul Holden
Type	Block
Compatibility	1.7 to 1.9
Links	M&P Entry Documentation Download

8: Hidden Text filter

The Hidden Text filter allows you to reveal hidden snippets of content, as students read it.

Application ideas:

• Micro-formative assessment
• Annotations
• Avoiding over-complicating content
• Hiding “Easter eggs”

Author	Dmitry Pupinin
Type	Filter
Compatibility	1.8, 1.9, ?2.0
Links	M&P Entry Documentation Download

7: Map module

Click to enlarge

The Map module allows you to embed dynamic maps into your course. It allows you and your students to add markers on the map.Application ideas: Allowing students to show holiday destinations Geographically, historically or politically significant locations War zones … The potential of this module is really huge.

Author	Ted Bowman
Type	Activity Module
Compatibility	1.8, 1.9
Links	M&P Entry Documentation Download

6: Twitter Search block

Click to enlarge

The Twitter search block allows you to micro-blog with your students.Searches are based on a configurable hashtag and could be used to search for: Institutional notices Teacher tweets Student tweets Topical news Info popular for students This is an easy way to bring social media into the classroom.

Author	Kevin Hughes
Type	Block
Compatibility	1.9, 2.x
Links	M&P Entry Download 1.9 Download 2.x

5: Progress Bar block

Click to enlarge Click to enlarge

The Progress Bar block shows students their progress in a course. It’s an easy way to help students monitor their progress and to motivate them to complete set tasks in the course.In the Moodle 2.x version there is an overview page that shows teachers the progress bar of each student. This allows teachers to see which students are keeping up and which are falling behind.

Author	Michael de Raadt (yours’ truly)
Type	Block
Compatibility	1.9, 2.x
Links	Plugins Entry Documentation Download

4: Group Selection module

Click to enlarge

The Group Selection module allows allow students to sort themselves into groups. Once student choose their groups, the groups work as normal Moodle groups.Application ideas: Project groups Interest clubs Research collaborations This is something I have heard lots of instructors calling out for.

Author	David Mudrák, Petr Škoda, Helen Foster, Anna Vanova
Type	Activity module
Compatibility	1.9, 2.x
Links	M&P Entry Documentation Download

3: Feedback module

Click to enlarge Click to enlarge

The Feedback module allows you to create custom surveys and analyse the feedback.Application ideas: Attitudinal feedback Student input into future content of a course Express opinions on topical issue Collecting data for statistics lessons The feedback modules is included as a standard module in Moodle 2.x, but is hidden by default

Author	Andreas Grab
Type	Activity module
Compatibility	1.5 onwards
Links	M&P Entry Documentation Download 1.9

2: Collapsed formats

Click to enlarge

The Collapsed formats allow you to avoid the dreaded “Scroll of death”.Sections can be toggled open and close. The format sets the current week or topic open automatically and each user’s state is remembered when they return to the course page.There is a topics format and a weekly format.

Author	Gareth Barnard
Type	Course formats
Compatibility	1.9, 2.x
Links	M&P Entry Weeks M&P Entry Topics

1: UploadPDF

Click to enlarge

The UploadPDF assignment type allows you to mark and annotate assignments without leaving your browser.The only downside is that students have to upload a PDF document, but that’s not such a big deal any more.

Author	Davo Smith
Type	Assignment type
Compatibility	1.9, 2.x
Links	Plugins entry Download

I struggled to narrow my favourite plugins to a top 10. The following plugins were also great.

• Lightbox
• Book
• Wikipedia filter
• Peer Review AT
• Online Users map
• Mindmap
• Shoutbox

If you’d like to see my original presentation. Here it is…

http://www.slideshare.net/deraadt/best-extensions-updated-after-moot

What is a Flavour?

A Flavour is a packaged collection of settings, languages and contributed plugins that can be shared between instances of Moodle.

You can package up a Flavour on one site, email it to a friend, and they can deploy the Flavour on their site.

Deploying a package

Who’s it useful for?

Flavours will be useful to:

• administrators starting a new site with help from another administrator;
• developers wanting to set up multiple working sites; and
• Moodle Partners and hosting providers want to set up commonly configured sites quickly.

Where do I get it?

The Flavours plugin is a Moodle local module for Moodle 2.x.

David has created an entry for it in the Moodle Modules and Plugins DB. Get it here…

Keep an eye out for it on the new Moodle Plugins repository soon. (For more info about the new Plugins repository, see my last post.)

Credits

Thanks to David for his efforts. It was easy having such a good student.

Thanks to Google for putting up the cash. Both the Moodle Community and David will undoubtedly benefit from this experience.

I should also acknowledge that Google is paying my way to the GSoC Mentor Summit in October, but I’d still say good things about this program, even if they weren’t.

—

The hardy developers at Moodle HQ have been working on a new Plugins repository system that is just about ready for public release on moodle.org.

Up to now, contributed modules have been served up on the Modules and Plugins DB, which is a customised Moodle Database activity module that we have lovingly referred to as M&P for many years.

What’s new?

The new Plugins repository system (or just Plugins for short) adds the following functionality over the previous system.

	Authoritative ratings, reviews and awards Some institutions run with thousands of students, but even the smallest installation is valuable. How do you know that the plugin that you are about to install is trustworthy? The new Plugins system will allow authorised users to provide reviews and rate plugins. There will also be the potential for plugins to earn awards. Reviews and ratings will be locked to specific versions so you will know you are getting the code that was reviewed. Talking about versioning…
	Versioning The new system will allow you to keep up with the latest version of your favourite plugins. It also gives developers more freedom on how they maintain their code, from simply uploading a zip to the potential to support the version control system of their choice. This will hopefully encourage new Moodle developers as well as pleasing the veterans. These changes pave the way for future developments that will hopefully allow you to see if the plugins installed on your system are out of date and if there is a new version.
	Screenshots, logos and other eye-candy The new system will allow you to quickly see what a plugin will look like. Developers can create logos for their contribution so they can be identified quickly.
	Developer information Developers work hard creating plugins and sharing them with the world – they deserve credit for their contribution. You will now see information about developers, maintainers and other contributors with each plugin. Unlike M&P, a team of contributors can now be shown. You will also be able see what other contributions your favourite developers have created; you can even keep track of their contributions by RSS.

Invigoration

With this new system in place and ready to go public, it is hoped that developers will be inspired to update their contributions. At first, it is likely that only modules with a Moodle 2.x version (plus earlier versions if applicable) will be accepted into the Plugins repository. This will also mean that CONTRIB-lovers will no longer have to wade through hundreds of unmaintained contributions.

Credits

Special credit is due to Sam Hemelryk and Marina Glancy for their continuing work on the system.

Also worth recognising is the contribution of CONTRIB Coordinator Anthony Borrow.

Here’s how you can make a small contribution that is likely to help out in a big way.

Step 1. Sign up for an account on Tracker

think of it like a dating site for bugs and devs

The tool used by Moodle to keep track of work is a decked out version of Jira. We just refer to it as Tracker. Head to tracker.moodle.org and create an account.

Step 2. Pick a bug

it’s like speed-dating in binary

You can see a list of bugs by clicking the button labelled Issues and find a bug that’s looking for love.

If you’re just playing the field, pick a minor bug with simple replication steps. If you’re keen to go all the way, check out these searches…

• popular bugs
• high priority bugs

Step 3. Solve the bug

don’t forget to backup first

I’m not going to tell you how to do that. Figuring it out is half the fun.

If you’re looking for some advice, check the Developers forum and and Dev docs.

Step 4. Post a solution

bragging rights

Go back to the bug report and share your solution. You can share a Git branch, a diff patch, or just summarise your solution in a comment. Any form of solution is a good solution.

So your solution can be noticed and integrated, add a label “patch”.

Enjoy!

Our beloved tracker