Developer meeting August 2005

From Dokeos

Jump to: navigation, search

The meeting was originally planned for July 6 and 7, but was delayed to the end of August.

There is a large amount of topics people want to discuss. Some people would like to discuss things through, others just want to make directly practical decisions. So we will have two meetings: one day with discussions that can take a while, the other day more short and practical. Non-programmers that are interested in discussing user-related topics are welcome on the first day.

Because we want to be as open as possible about all this, we have opened forum discussion on some of these topics too, they are in the development section of the forum. Feel free to participate or start discussions on new threads.

Contents

Participants

First day - August 24 - discussions

Second day - August 25 - practical

First day - discussions

Proposal: we'll try to limit discussions to no longer than 1 - 1.5 hours, that way we can get to discuss all the topics. Some topics will be discussed in the discussion day, and perhaps a final decision taken on the practical day.

  • Introduction speech by Thomas Depraetere
  • Long term: what direction are we going? how do we build and maintain the community, how do we promote ourselves ? What decision process do we want, how to get more users to help make decisions...

Release schedule

  • which vision on release schedules
  • how do we keep developers on track in certain stages - e.g. no new features during late beta / release candidate stage ?
  • to what users does this appeal, does this help community growth and code quality, alternatives
  • release frequency of minor updates (1.6.1, 1.6.2...)
  • release frequency of new releases (1.7, 1.8...)
  • Forum: Dokeos release discussion
  • A compromise, or a two-way path, that fits the commercial needs of Dokeos company and the non-commercial needs of some other parts of the Dokeos community. ("Community releases?")

There are a number of views on this. If you have written a proposal out somewhere, link to it here.

Community involvement

How do we get users more involved in the decision process? Some decisions on the user interface or features are taken by developers alone with users only commenting on them after they become visible. Ideally user feedback comes as early as possible in the development process.

A suggestion: think of using tools that young people tend to use anyway. There are some interesting ideas on edublogs e.g. populaire webapps als bouwstenen voor een ELO --jmm 18:01, 24 Jun 2005 (CEST)

How do we handle the different languages, e.g. for the forum, DLTT, and manual and FAQ. Every used language should at least have a FAQ, readme and installation guide in its translation.

We can also discuss the users day briefly, and set a real organising meeting.

Tools, plugins, branches and forks

  • how to deal with inevitable branches (open community, good API, good plugin system) (see also Dealing with a diverse community)
  • do we need a separate cvs + sourceforge project for plugin development
  • Looking back: what did we learn from the Dokeos development process and community growth
  • Dokeos architecture: do we want a content management system underneath? Do we want a database abstraction layer so we could use other databases than MySQL?
  • Proposal: decrease visibility of code ownership: remove all author tags, keep only the copyright notices, credit everyone there. This helps improving-without-criticizing (an extreme programming ideal).

Dreammap

We can quickly go through the dreammap so we can draw up the roadmap for Dokeos 1.7. We can decide for each of the topics if we include it or not. This first day, we will at least discuss the two topics below - the choices we make about them are very important for the future of Dokeos.

Content Management Systems - integration with Dokeos

CMS development itself is discussed in separate meetings (next one is on September 1st). The discussion on this topic is: how to connect it with Dokeos?

Possible ways

  • Make Dokeos itself an LCMS
  • Have a completely separate Dokeos CMS development
  • Integrate a storage abstraction layer into Dokeos, so Dokeos can easily use the default storage or connect to external CMS repositories.

See also

CMS Proposal 1

(This is just one proposal, feel free to add others.)

Dokeos CMS development starts in a separate branch on the Dokeos cvs. This means the normal Dokeos development is not influenced by possible instabilities, but it will be easy in the future to merge some development of that branch into standard Dokeos, e.g. to have a storage abstraction layer. As soon as workable code for this is ready, it is demonstrated and discussed and the abstraction layer can be merged into Dokeos development. This can happen in several steps, some steps that are stable enough but already move the code towards this abstraction can be integrated quickly into main Dokeos development, the rest will have to wait until the code stabilizes. Dokeos 1.7 will not have an abstraction layer, integration of one is aimed at for Dokeos 1.8.

User roles and rights

  • Introduction about the possible use of these roles by Isabel Deprez.
  • What do we need, how can we built it in, how can we hide complexity when it is not needed, can systems be optional?
    • Do we need the ability to set individual users' rights?
    • Do we need the ability to define roles (as platform admin, as course admin...)
    • Do we need the possibility of multiple roles inside the same scope (e.g. a course)?

See also:

Second day - more practical

Branching

  • documentation to help developers effectively use branches
  • decide on a new branch date for 1.7 - 1.8 development (proposals: either in beta stage or in release candidate stage, a soon as somebody wants to start with 1.8)

Dokeos 1.6.x

The 1.6.1 release is mostly agreed upon now: release August 31 or a few days later, have a release candidate one week before that. Optional upgrade script to fix some issues. Development for the stable branch is going well so it may not need much finetuning or discussion. Still a problem: where to commit fixes first, in stable branch or in trunk.

Dokeos 1.7 proposal

Release date: proposals vary from "six months after stable 1.6.0 release" to "one year after stable 1.6.0 release". The date is connected to a general release schedule discussion.

Security

  • Proposal: private (how private?) mailinglist just for security
  • Openness about security
  • Patches

Translations

  • DLTT: improvements of 1.6.x translations, improvements of unstable-1.7 translations? proposal: two copies of the translation tool, each with a different database.
  • Manuals, installation guides: proposal: create email address translation@dokeos.com so people have a good address to send their documents to.

What goes into 1.7, 1.8, extensions

  • Go to the dream map
    • what we certainly will try to implement for 1.7 / 1.8 / ... (guaranteed developer time)
    • what we certainly won't implement as default yet (problems to solve, duplication of existing tools, better as a plugin...)
    • in between: things we're considering, but who has the time | ...

Content Management Systems

practical decisions

User roles and rights

practical decisions

See also

Retrieved from "http://www.dokeos.com/wiki/index.php/Developer_meeting_August_2005"
Personal tools