Dev meeting of September 3rd, 2004
From Dokeos
Meeting starts at 10 AM
Contents |
Participants
Ghent University: Berit De Meester, Bert Vanderkimpen, Olivier Cauberghe, Patrick Cool, Thomas Berton, Dr. Toon Vanhoecke, Prof. Dr. Willem Wieme
Hogent: Jean-Marie, Michel, Bart, Stefaan
Vrije Universiteit Brussel: Frederik, Koen, Roan
Dokeos SA: Thomas Depraetere
Ren� Haentjens, Wolfgang Schneider, and Denes Nagy could not come but they did sent their ideas and opinions via mail so we could take these into account.
Demo course with content
Thomas first gives a demo of a course (1234bcc0 at Dokeos.com campus) created by Ali Pakdel (Dokeos SA). This course about �Solid waste management� demonstrates the possibilities of the learning path.
We can use a new idea - course creation by copying existing databases to provide course templates: empty course, some content, Ali�s full course. (The same trick can also be used to duplicate or clone courses, can be very useful).
Important decisions
We first discuss a few important decisions we have to make.
Decision 1 we have to make: API structure
Just functions in files, static functions in classes, or real OOP.
Proposal
For the most part, write procedural code and organise these functions into classes, calling them as static functions. We can try a few objects, e.g. a user object. The Xml library already uses objects, this leads to very clear code for the users of this API.
Decisions
It is decided to store functions of a tool � if there are many � by default inside a separate file inside the tool folder. Example: link.php contains the main code, link.lib.php the functions, both files are inside the link folder. However, when the code can be used by other tools / pieces of Dokeos the library file will be stored inside the inc/lib folder. An example is the document.lib.php file (does not exist yet) that will be used by the document tool, group tool, and scorm player. A library like this belongs in the inc/lib/ folder. We will continue organising (static) functions inside classes. For examples of this approach see database.lib.php and display.lib.php.
To discuss and research further
It's too early to decide on using objects and classes everywhere yet. Annoyingly, certain class functionality has changed between PHP 4 and 5. We have to research whether it is possible to create classes that work with PHP 4 and 5. Until this is researched converting the main code of Dokeos to OOP cannot be discussed. It would require having two copies of every class and this would lead to too much problems. We will simply write procedural code, and try to organise this into functions. Two new unfinished libraries (database.lib.php and display.lib.php) store the functions inside a class, so users of these library can call them as static functions. This does not change the functions and does not require objects, constructors... so this should be compatible with PHP 5 (but this needs to be tested to be sure). We will continue organising (static) functions inside classes. During the meeting, it is proposed to try make more use of PEAR packages, as they solve many things already and we shouldn't be reinventing the wheel. The question is raised wether these PEAR packages work on PHP 4 or 5 or both. This will be tested by Bart (Hogent).
Decision 2 we have to make: language strings
We cannot have mixed language strings, camelCase and under_score.
Proposal
Standardize on camelCase, this is what 99% of the language variables already uses. Standardize on get_lang to keep code maintainable for the future language implementations.
Decisions
Proposals accepted after long discussion. We will standardize on camelCase for language variables (other variables remain under_score as per the older agreement). For several reasons we will never use the language variables directly in the code but use a function get_lang. Example: a language string is $langConfirmYourChoice. This string will be accessed by the function call get_lang(�ConfirmYourChoice�); To discuss and research further Use of Unicode in the future and put languages in their real name. We will research this first. Patrick will finish his database-driven translation tool quite soon. We will all think about the teacher trainer course coach exceptions.
Decision 3 we have to make: courses directory
Proposal
If we are going to a separate directory for new courses, let's do it now.
Decisions
Proposal accepted, we will create a directory called courses. Next month(s) we will all help refactor the code to take this into account. Roan will write a function that takes a parameter and returns the wanted directory. api_get_path(CONSTANT) Examples (not implemented yet) api_get_path(WEB_ROOT) returns http://www.server.be/dokeos/ api_get_path(SYS_ROOT) returns /var/www/html/dokeos/ api_get_path(WEB_COURSE_DIR) returns http://www.server.be/dokeos/course/ api_get_path(SYS_COURSE_DIR) returns /var/www/html/dokeos/courses/ There are many functions dealing with this already in the Dokeos main_api (e.g. api_get_root_sys(), api_get_root_web(), api_get_code_sys_path(), api_get_code_web_path() ). We can replace them all by one api_get_path(CONSTANT) function. The older ones will be kept for now (one thing at a time). Style and consistency Bert does the css for the new default Dokeos button. There should always be feedback when changing something. When you change something in a list, go back to that item on the screen. To Do (roan): publish a short style handbook listing the ideas of the previous and current developer meetings. Urgent stuff is done, now 12 AM and proceed with rest of meeting.
Documentation
As we can see from statistics on the Dokeos website, the documentation page is very frequently visited. The manuals of several languages were too outdated and have been removed. There are new student and teacher manuals in English, Dutch and French; there is also a new Admin manual.
What is our project?
Not everyone in the Dokeos community has the same goal. Of course we want to build a good learning management system (LMS), but there are other things as well. There is the LMS, but there is also the user community and content and...
Like in all Open Source development there is a political / philosophical idea behind Dokeos. This means that is useful to talk about this too.
Our project can also involve Third World development, because open source software can help third world countries break free from several problems. E.g. The digital divide, third world countries lack the resources to provide e.g. Computer equipment for education, but a lot of the software cost can go away when using open source tools (Linux, Dokeos, ...)
Methodology and organisation
As the community (developers, testers, users, ...) grows larger, we need to organise ourselves better to prevent too much chaos.
Features organisation : someone should say �I�m in charge of the dropbox�.
Development organization: Refactoring / analysis / documentation manager / code quality manager
Responsibilities and personal skills.
E.g. Olivier for debugging, � Roadmap More people will receive a login with permission to change the roadmap. It cannot stay up to date otherwise. Skills and vices ;-)
Thomas Depraetere (Dokeos company) Good at Being in contact with users, see what they want. Philosophical background. Link between interface and values that are behind it. Not good at Methodology, programming
Frederik Questier (VUB) A bit too early to make commitments because of other work. Good at opensource & open content principles. Jabber. Responsible for legal matters.
Koen Vanmeerbeek (VUB) Good at Responsible for the language translations, keeping contact with translators. Also interface, virtual classroom. Tips: contact Petrossi (Italy) Not good at Programming
Roan Embrechts (VUB) Good at Software development process (SDP), refactoring. Architecture. First Blackboard to Dokeos import tool. Not good at UI building.
Stefaan Vanbillemont (Hogent) Good at Likes to organise / manage things. User interfaces. Software design / analysis. Pre-view.
Jan Bols (UGent) Responsible for the drop box. Good at Programming, but lacks drive sometimes, because: code should be as clean as possible. Frustrated if code looks ugly. Likes to criticize (post-fact).
Bert Vanderkimpen(UGent) Good at Future: Will work on documents tool. Developing with web standards: valid xhtml, stylesheets. WAI.
Jean-Marie (Hogent) Good at User side, pedagogical aspects, good at Blackboard knowledge, big lines (logical thinking). Concerned with knowledge management. History: computational Not good at Not a programmer anymore
Bart Mollet (Hogent) Newbie at Dokeos. Good at Code organization, underlying structures, API.
Michel Panckoucke (Hogent) Analysing and Interface. Refactoring. Updating Blackboard migration tool for BB6.
Berit De Meester (UGent) Poll tool. Dokeos � Curios tool connection.
Olivier Cauberghe (UGent) Curios developer (New test tool that follows IMS QTI standard, like Question Mark). Beta in January 2005. Will probably be GNU GPL.
Thomas Berton (UGent) Cleaning up the forum code, also dedicated to Curios. Linux Guru
Willem Wieme (UGent) Not a programmer. Making the best of Dokeos for the UGent. Listening to users, good at testing and feedback. Supervises the UGent programmers.
Patrick Cool (UGent) Generalist: not good at anything in particular, does many things. New features (tools). Last minute. Responsible for: Resource Linker, Agenda, Announcements, Links,
Toon Van Hoecke (UGent) Tracking, what�s new responsible. Try to help build database structure. Also partly Curios: check Scorm & IMS standards. Team management.
Olivier Brouckaert (Dokeos company) Admin, install, upgrade, debug.
Rene Haentjens (UGent) Metadata, Xml, SCORM, searching.
Denes Nagy (Dokeos company) Tools: Live Meeting, Learning Path, Hotpotatoes.
We also need someone to manage manuals. Perhaps Isabel Deprez (VUB) ? This is necessary for future users.
Tools � who's responsible ?
This meeting we used our time to assign responsible persons for tools. Next meeting we will do the same for the other things: organisation, code architecture, analysis, database design, ... The fact that a person is responsible for a tool does not mean that person is the only one developing that tool. Open source development is only better because it's collaborative. But the responsible person listed is the one to go to for questions or for collaboration.
Documents -> Bert Vanderkimpen
Forum -> Thomas Berton
Agenda -> Patrick Cool
Links -> Patrick Cool
Admin -> Yannick Warnier & Olivier Brouckaert
Announcements -> Patrick Cool
Learning Path -> Denes Nagy + Patrick Cool
Plugin ->
Poll -> Berit De Meester
Dropbox -> Jan Bols
Install -> Olivier Brouckaert
Live meeting -> Denes Nagy
Backup & Restore -> Olivier Cauberghe
Course properties -> Stefaan
Course description ->Stefaan
Chat -> Olivier B (but see Jabber)
Tracking -> Toon Vanhoecke
Reporting -> Toon Vanhoecke
User profile -> (Patrick)
Portfolio -> Frederik
Groups -> Bart
Assignments (Student Publications) ->
Tests -> Olivier B
Migration -> Michel
Resourcelinker -> Patrick Cool
User Management -> Olivier B + some analysis person (Bart)
Authentication -> Roan
Plugin -> Hugues ;-)
Poll -> Berit De Meester
Survey -> (Aarhus: Jens)
Portfolio
see also knowledge docs and documents
Css -> Wolfgang
How to make decisions
Some things are difficult to decide. Through discussion, research and analysis, we first try to reach an intelligent concensus.
Bug tracker
Last developer meeting (online chat), there was no agreement reached about using a specific bug organisation tool or not. Roan would investigate the bug tracking system of sourceforge. This works well for programmers, but is not very user-friendly. It is decided that Dokeos will use Bugzilla, a more user-friendly system. http://www.bugzilla.org/
Knowledge management
We need to rethink philosophy on knowledge management. Next meeting Discuss the organization stuff (the tools we did this meeting, next are the structural things).
Decisions
A summary of all the things that were decided.
- Store functions of a tool by default inside a separate file inside the tool folder. However, when the code can be used by other tools / pieces of Dokeos the library file will be stored inside the inc/lib folder.
- Standardize on camelCase for language variables (other variables remain under_score as per the older agreement).
- Use get_lang to get access to the language variables.
- We will create a directory called courses. Next month(s) we will all help refactor the code to take this into account. Roan will write a function (proposal) that takes a parameter and returns the wanted directory.
To Do
A summary of a few urgent things to do.
- Roan: New courses directory: write a function that takes a parameter and returns the wanted directory. After this everyone will help refactor the tools for the courses directory.
- Update: The function has been implemented, and a lot of code has been refactored to use it. See the forum topic about this.
- Patrick: finish translation tool
- Bert: create the css for the new default Dokeos button (forum topic).
- Roan: publish a short style handbook listing the ideas of the previous and current developer meetings.
- Update: We have started to build a style book on this wiki.
- Bart: Test wether PEAR packages work on PHP 4 or 5 or both.
- Update:
- From: Alan Knowles
- All existing packages that work with PHP4, will continue to work with PHP4,
- - some may add PHP5 features (but should remain API compatible with PHP4)
- - some may have new versions, with a different name = eg. Auth2, which will be PHP5 only.
- - It's depends on each maintainer, but in general, security fixes will be applied to older PHP4 only package, if a maintaner has decided to do a PHP5 version.
- - some _new_ packages may only be released as a PHP5 version, (it's up to the contributor, but we are open to people offering PHP4 versions of these, however the rules for this havent really been worked out..)
- We have outlined the rules for backwards compatibility (BC) (see package naming guidelines)
- Regards
- Alan
- Update:
meeting summary by Roan Embrechts, OSC, Vrije Universiteit Brussel
