From Mahara Wiki

Revision as of 18:00, 12 July 2020 by Anitsirk (talk | contribs) (Components of each release)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.
New feature development
to offer tools to learners that they need to create the portfolios they want or are required to set up.
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.
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.

Individual roadmaps