Working Groups

Jump to: navigation, search

What is a working group?

Working groups bring together experienced users, researchers and developers who are interested in working together to make Moodle better. They happen at MoodleMoots.

Working groups have the following characteristics.

  • Topics are suggested from surveys, the Moodle Roadmap and from forum discussions. In future, topics may be put forward from the Moodle Association.
  • Generally there is a leader (or leaders) who establishes the working group; the leaders may maintain some leadership during the project, such as mediating discussions and documenting ideas, but work is done by all participants.
  • Most participants will be experienced end-users (teachers, admins, researchers, IDs) or developers, but advanced technical skills are not required.
  • Participants may be asked to be involved in preparation prior to the working group in focussed discussions about the target Moodle function.
  • On the first day of the MoodleMoot, working group members will meet together. A developer will be available to provide technical advice to the group, if necessary. The day is likely to progress as follows.
    • Introductions and group formation
    • Sharing of pre-existing solutions
    • Discussion about target areas and generalisation focussing on the "what" rather than the "how"
    • Iteration over work areas, elaborating and prioritising ideas in a collaborative document
    • Preparing a report to share with the MoodleMoot
    • Preparing questions for developers at the Hackfest
  • In the next two days of the MoodleMoot, working groups will be given the opportunity to put their ideas to the community at the MoodleMoot and to gather feedback. Short plenary sessions are planned for this purpose.
  • The day after the conference there will be a Hackfest that will bring together Moodle developers. Developers will have a chance to consider how the ideas of the working group can become a reality. Working groups will be represented by the working group leaders at the Hackfest.
  • After the MoodleMoot, working group members are encouraged to remain involved as changes are implemented in later Moodle versions.
  • Working group members may wish to experimentally test the value of their work as a research project, collaborating towards publishable results. While this is encouraged, it is not a mandatory part of working groups and will depend on the nature of the project.

Moodle Gradebook Working Group 2014

Leaders: Mark McKay, Bob Puffer

The Moodle Gradebook Working Group (MGWG) was originally planned to be part of the Moodle Research Conference that was to be held in California, USA. When the MRC was cancelled, the MGWG was expanded to a two day development conference.

MoodleMoot IEUK 2015

Two working groups were held at MootIEUK15.

Dashboard

Leader: Mark Glynn

The working group looked at what teachers and students need from their Dashboard / My Home page, what other organisations have done and what should be changed and built for core Moodle.

Form Simplification

Leader: Artis Ivanovs

The purpose of this working group was to review and simplify forms that users (including new users) use every day and to provide more control to administrators over such forms.

The working group reviewed a number of commonly used forms and made recommendations for usability improvements. Some reflected pre-existing issues and others were created as new issues.


MoodleMoot Australia 2015

Two working groups were held at MootAu15.

Course archiving and roll-over

Leader: Jason Maddern

The group looked at workflow issues relating to course administration at the beginning and end of course use.

The working group suggested a number of new features and improvements

  • Better bulk handling of courses within Moodle
  • New course welcome wizard
  • A freeze “flag” on all contexts
  • Grade archiving
  • Consistency in all backup-based tools
  • Ability to set ‘relative’ dates
  • Easier/nicer alternative to import
  • A new ‘Default visibility’ flag for all course modules

Assessment Analytics

Leader: (no leader after last minute change)

The group looked at utilising information relating to assignment feedback and how that can be made more useful and available to students and teachers.

The group prioritised and developed three main improvements (epic MDL-51753).

  • Allowing students to indicate whether feedback they received was useful (MDL-51754).
  • Adding elements to the Dashboard and Gradebook to entice students to view feedback in the assignment (MDL-51768)
  • Recording whether a student has viewed feedback (MDL-51761) and making this information together with the feedback available when marking subsequent assignments (MDL-51762).

MoodleMoot US 2015

There were three working groups held at MootUS15.

Moodle Instructional Assistant

Leader: Michelle Moore

The group brainstormed the potential and functionality of an instructional assistant and a preliminary block was created..

Moodle Gradebook Working Group

Leader: Mark McKay, Ryan Hazen, Jason Hadin

This was a continuation of the Moodle Gradebook Working Group started in 2014 (see above).

The group reviewed a number of issues and suggested possible improvements.

  • Standardising gradebook entries so that all entries have a start date, due date and cut off date.
  • Change behaviour so that, on an activity level or category level, by the due date or cutoff date, values switch from dash (as not counted) to a dash being a 0.
  • Make grade items (Categories and Items) view configurable

Learning analytics

Leader: Elizabeth Dalton, Bob Puffer, Steve Miley

The group proposed a system with a number of interfaces.

  • List of students & status viewable by teachers and other support staff
  • Detail view per student showing how their status was determined viewable by teachers and possibly the students themselves
  • Configuration Interface that would allow status calculations to be tweaked on-the-fly (may be incorporated into List of students)
  • Push notifications based on status-based triggers

The group discussed the information that would be needed by this system.

  • Status (e.g., “At risk”, “Normal”, “Ahead”...) calculated for a user with a role based on multiple pre-gathered...
    • Metrics being based on observed events or queries
  • ...and having...
    • Validation calculations based on final results to measure the accuracy of earlier status calculations and future refinements.

Other