Actions

Difference between revisions of "Roadmap"

From Mahara Wiki

m (Protected "Roadmap": Mahara core team responsibility ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite)))
Line 23: Line 23:
 
* '''Infrastructure updates''' to facilitate the smooth running of the project, the server infrastructure that hosts community sites used for conversations with people using or planning to use Mahara and developers.
 
* '''Infrastructure updates''' to facilitate the smooth running of the project, the server infrastructure that hosts community sites used for conversations with people using or planning to use Mahara and developers.
  
=Decision on way forward=
+
=Decision on what to include in a release=
  
 
The decision of what is being included in a release is guided by two elements:
 
The decision of what is being included in a release is guided by two elements:

Revision as of 22:21, 2 May 2019

The Mahara team strives to provide a portfolio system that supports people in their learning journeys, gathering evidence, showcasing achievements, making their learning visible, and engage others in the learning process.

Since the start of the Mahara project, the roadmap has been influenced by ideas from the project team and feature requests of community members to keep Mahara relevant to the organisations using it.

The core team engages with community members to learn how they are using Mahara, what they like, what can be improved, and also what the direction is that their portfolio implementation is taking. So for example, at the beginning of the Mahara project, the idea of the personal learning environment was the driving force behind the feature development. Over the years, assessment elements have been added as organisations had a demand in integrating portfolios more tightly into formal teaching and learning scenarios for which they required a different portfolio approach. These features were then developed and are enhanced over time.

Time-based releases

In logistical terms, the Mahara project has two releases per year: One in April and one in October to make it possible for organisations in the Northern hemisphere and in the Southern hemisphere to upgrade to a recent version of Mahara.

The switch to a continuous release cycle was discussed but not adopted for the time being because most organisations require a stable period of features so as not to disrupt learners during an academic year and also not require that support staff needs to update institution-specific documentation several times a year.

The time-based releases require that features are ready for inclusion by a certain time. If they are not, they get pushed out to the next available release and are considered for that.

Components of each release

The Mahara community tackles a number of general items in each release:

  • Usability improvements to simplify the user interface, keep up with the changing world of how people interact with web applications and thus expect from Mahara.
  • Technical updates to make use of new libraries that are used and keep current with technology that is included. That also supports the usability of the site.
  • New feature development to offer tools to learners that they need to create the portfolios they want or are required to set up.
  • Issue resolution to fix problems that people have come across.
  • Infrastructure updates to facilitate the smooth running of the project, the server infrastructure that hosts community sites used for conversations with people using or planning to use Mahara and developers.

Decision on what to include in a release

The decision of what is being included in a release is guided by two elements:

  • Work that the core project team is tackling;
  • Features developed / sponsored by community members.

For each release, the core project team outlines a few areas that it is going to work on. Because the core team knows that throughout each release cycle, community members propose new features that are included into Mahara core and it works closely with community members who sponsor features for the core team to develop, a number of features are not always planned at the start of the development cycle for each release.

This gives the core team the opportunity to respond to the demand from community members to support them in getting their features included into Mahara.

Proposing new features

When new features are proposed for Mahara, the requirements are shared with the project team and ideally also the rest of the community. The project team evaluates these requests and decides whether the proposed feature would be a good addition to Mahara, benefiting not just this one organisation but multiple.

The evaluation process from the project team takes into consideration whether other community members have been discussing a similar idea, the demand for such a feature is seen in the wider community (e.g. through questions in requests for proposals, presentations, feature discussions, learning scenarios that require support) and also into which directions the project wants to grow.

The size of the features is very varied. Some are quick changes enhancing the usability whereas other features can take several days or even weeks to develop.

Mahara 19.10 specific items

For the release of Mahara 19.10, the October 2019 release, a number of features were identified to support the growth of Mahara:

  • Usability improvements:
    • Change the way learners interact with the building of pages in edit mode to make it more intuitive and reduce the number of clicks to achieve a preferred layout.
    • Make Mahara pages look less blocky, i.e. outsource comments and artefact details information more elegantly allowing viewers who are after the showcase to see that yet at the same time allow those that need to assess the content to still have all those elements available from the same page.
  • Technical updates: Remove database triggers to support cloud-based hosting infrastructures better.
  • New feature development:
    • Implement a moderation mode for sharing of portfolios in contexts that require higher privacy and supervision of shared content.
    • PDF export of an entire account and all learning artefacts within.
    • Allow learning evidence to be linked to a competency via SmartEvidence directly.
  • Infrastructure updates: Move all issues from Launchpad to Gitlab for improved usability when interacting with the software and keeping better track of items via the more comprehensive and modern feature set of Gitlab.

There are a few other features that are currently in discussion for Mahara 19.10. Their inclusion will depend on the progress that is made until the feature freeze for 19.10:

  • Add SmartEvidence capability to Mahara Mobile
  • Place a generic block onto a page and only then choose the block type rather than defining it at the start. That will support the creation of templates.
  • Enhance the plan functionality to tie them better to assignments and the creation of specific portfolios.
  • Implement the Moodle assignment submission plugin for LTI.
  • Additional Moodle-Mahara integration, e.g. in regards to the sharing of notifications.
  • ObjectFS storage for Open Stack (AWS and Microsoft Azure are already supported).

Mahara 20.04 specific items

For the release in April 2020, a couple of items are of interest to investigate more closely.

  • Changes to the SmartEvidence editor after having received feedback from the community (Mahara 19.04 or hight required).
  • Review the status of the new LTI standard 1.3 and its implications for Mahara, including supporting it.