Project

General

Profile

Actions

Planning

Release Schedule

This proposal has been inspired by the schedule of Ubuntu.

Main steps

- Planning & discussion about next main big works
- Feature Definition : What has to be done for the main big features to be considered "done"
- Feature Implementation : Coding / Testing / Refactoring. Small features which do not break anything can be added without needing approval. Extra breaking features can be discussed to be added as well but needs approval of the community.
- Feature Freeze : packages that will be part of the simultaneous release must freeze their API / behaviour. The official list of those package is communicated and everyone can checkout those package as a dependency and know that it won't change until next simultaneous release.
- Stabilization : The API / behaviour cannot change but it is time to hunt the bugs. The Translation team and the Documentation can do their work.
- Simultaneous release : different "distributions" are made by cherrypicking subsets of packages from the list of stable packages.

On a yearly basis

Since most of our clients are education institute, this proposal is based to synchronize our schedule with the academic year beginning in September, finishing in June, having July and Augustus as a period with almost no user but very few devs also.

June : Simultaneous Release
July-Augustus-September : Planning
October - November - December : First Half for Implementation. Planning might be redone.
January-February-March : Seconf Half for Implementation. Big features should be done.
April : Feature freeze
April-May-June : Documentation & Translation
April-May-June : Bug Hunt / Manual Testing

Workflow

Continuous

Topics refer to (small) improvements or maintenance of exceptionally changeable components.

General

  • Bugfixing
  • Automated tests

Core

  • Improve multi DBMS support (initially PostgreSQL)
  • Import: QTI
  • Export: QTI

Applications

  • Assessment

Content Objects

  • Assessment question types

External Repository Managers

  • Maintenance of existing connections: e.g. Fedora Core
  • Monitor new external services (and schedule according to possibilities)

Short term

General

  • Cleanup Ajax calls platform-wide (using the AjaxManager)
  • Allow HtmlEditor configurations per package (if and when necessary)

Core

  • Metadata
  • Context linking (based on metadata)
  • Notification system (Mail, IM, Twitter, Facebook, ...)
  • Migration (1.8.5 - 2.0)

Applications

  • Courses: Assignment tool
  • Courses Timeline view
  • Gradebook
  • Peer assessment
  • Static pages application (for "regular portfolio" websites)
  • Personal Messenger: eliminate overhead content objects

Content Objects

  • Peer assessment content object types

Midterm

General

  • Implement "FrontController" as single launch point
  • Request handling
  • Response handling
  • Error handling

Core

  • Package Manager
  • Authentication API refactoring
  • Database API refactoring

Applications

  • Courses: Survey tool
  • Survey
  • Streaming media archive

Content Objects

  • Survey question types
  • Streaming media extensions

External Repository Managers

  • Opencast Matterhorn integration / backend

Long term

General

  • Extend and implement visual templates
  • REST API
  • Full TinyMCE HtmlEditor support

Core

  • Replace QuickForm by FormLibrary
  • Move form-based business logic from views to models
  • SCORM player
  • Export: Mahara portfolios
  • Sessions
  • Extended multi-publishing from repository to application(s)
  • Migration (more platforms and versions)

Applications

  • Campus plugin with timetables and student tracking
  • Tool / Application abstraction
  • Workspaces

External Repository Managers

  • CMIS protocol support

Updated by Anonymous over 11 years ago ยท 10 revisions