Developer meeting November 2006 meeting minutes

From Dokeos

Time and location

November 24th, 2006 2-5pm

Vrije Universiteit Brussel, Campus Etterbeek, Pleinlaan 2, B-1050 Brussel, building D, room 3.11

Details about campus location and how to get there

Participants

• Olivier Sourie (Hogeschool West-Vlaanderen)
• Liesbeth De Blaere (Hogeschool West-Vlaanderen)
• Bart Mollet (Hogeschool Gent)
• Jean-Marie Maes (Hogeschool Gent)
• Evie (Vrije Universiteit Brussel)
• Frederik Questier (Vrije Universiteit Brussel)
• Bruno Dooms (Vrije Universiteit Brussel)
• Frederik Martens (Arteveldehogeschool Gent)
• Daniel Du Seuil (Arteveldehogeschool Gent)
• Patrick Cool (Ghent University)

Agenda

General issues

The meeting starts with several remarks from developers about the current decision and release management.

In general we think we are not doing well at the moment with regards to developer organisation, release management, and decision making.

A lot of the new features (blog, survey, sessions) of Dokeos 1.8 have just been thrown in without any discussion. We could have prevented many problems that are occuring now, e.g.

• lack of design discussion beforehand, leading to duplication, substandard work, complexity issues
• the sessions design is too close to the classes design - they should be integrated
• why is the survey tool separate from the exercises tool - this should be one tool
• new developers don't use all of our coding conventions or building blocks (form validator, sortable table...)

The steering committee should be cleared up as soon as possible, with the fixed and the elected members, elected by all the members of the consortium. Who will be in the steering committee, the developers themselves or their managers? We need separate development meetings regardless, and a clear link between dev meetings and steering committee. Decisions in the dev meeting should be taken seriously, perhaps decisions taken there can be ratified by the steering committee.

Communication is pretty chaotic now. We want to continue using the forum for discussion and communication. A bugtracker / project tracker should not be abused as a place for discussions. We can put a bug tracker to good use, but we will not force users to report bugs in there, using the forum to report bugs has worked fine in the past and no one has time to put bugs from the forum into the bugtracker so the forum will also remain used for that.

Dokeos 1.8 - Switch to PHP 5

There is agreement on making the switch to PHP 5, this will from now on be listed as required for Dokeos 1.8. However, this decision should have been made a lot earlier.

Sessions development

The design is not ready. [1], [2]

Classes should remain in Dokeos, and the "sessions" concept can be implemented using classes, adding e.g. time parameters, possible time-based coaches, etc.

Dokeos object repository

Proposal: we will switch to using a learning object repository as storage underneath Dokeos, after Dokeos 1.8. Basically, the goal is to have a centralized way of storing and handling learning objects. We already have partially complete Dokeos LCMS code, we can copy the new Dokeos 1.8 developments to there and change them to use the object repository as storage. This will be a serious effort for the whole team, we should take our time for this important and necessary change. There will be roughly two years between Dokeos 1.6 release and Dokeos 1.8, another two years can certainly bring us Dokeos-with-a-decent-storage-structure. This includes the use of a database abstraction layer, Pear MDB2 is suggested (which replaces the deprecated Pear DB) -- Evie

We need an action plan. If we work on this as a group, we can get it ready quite quickly, in one and a half year at the earliest. We can already have a complete prototype / alpha version in fall 2007.

Hogeschool Gent - where the initial code was created - is prepared to host a programming / teaching / discussion day so Dokeos programmers can get familiar with the system.

Remarks

• Data should be easy to export from the storage system (no lock-in)
• One of our goals is the ability to connect Dokeos to multiple storage repositories.

Portfolio

This is the first developer meeting discussing portfolio development. The Vrije Universiteit Brussel is eager to start development and wants to discuss this with as many Dokeos members and developers as possible. There is a page describing a portfolio already, but we plan to release an updated project plan. The current design and future improvements are based on experience with existing systems.

The portfolio will be an application that uses the object storage interface.

Users, roles, rights

In an informal meeting some time ago, we decided to create a new design that combined the two existing designs to bring the community together again. The technical work still needs to be done. For this meeting a first proposal has been made. Several issues are discussed and we will improve the proposal to take these into account. The designs are based on experience with existing systems, e.g. we've looked at roles-rights systems in Plone/Zope, Drupal, Moodle. It is suggested we should check out the roles-rights system of phpbb3.

Necessary improvements, to be worked out in the User Roles and Rights compromise design page.

• The distinction (and wether this is necessary) between global - local roles needs to be worked out.
• We need templates / default course.
• Creating a course group should be an option with a (local) role.
• The locations are currently stored very inefficiently, to improve this we will use the tree structure mentioned in the first proposal to store them.
• We will have to think about a time aspect
• The user interface can allow individual user permissions, these can be stored separately or as an "individual role" into the main roles system (this has not been decided yet).

Reservations

Proposal: I recieve many demands for a Reservation tool : book a room, manage a teachers schedule in a school, book training devices etc. As far as I hear it, this looks generic : in schools, universities and public administrations. I have seen the HoGent Reservation tool and I propose to add this in Dokeos 1.8 instead of only as an extension. -- thomas

Extensions

Proposal: Some institutions use a few extensions on every installation or in every course (eg. Assignments tool). It might be interesting for these to be integrated into the main Dokeos code.

There has also been discussions in the past about having the extensions in CVS/SVN, but there was never a conclusion to this. Versioning, debugging and administration of these extensions would be much easier if they were in a (separate) SVN.

-- frmartens

About the assignments extension: we cannot add it right now, since we already have partially overlapping tools: Dropbox and Student publications. Someone should propose a clear design that reduces feature duplication. -- Evie

A discussion thread has been created on the Forum about this. -- frmartens

Extensions in general: apart from SVN maybe we also need to provide space on the wiki for the extensions... -- Evie

Varia

We need to put more effort into the manual. Dokeos using organisations should try to fit this into their agenda.

See also

• General discussion on Dokeos forum about items of this meeting
• Discussion specifically about Student publications, Dropbox, Assignments
• Discussion specifically about My e-portfolio
• Discussion specifically about Content Management System (CMS) + Portfolio