25 Feb

Growing Mahara community

For 2013, our chief Mahara designer Evonne created a series of Mahara merchandise with the Mahara logo in various incarnations. We have the plain Mahara logo, but also various Mahara characters representing community members / roles. I love these special logos because they show that Mahara is not just a software, but that people are very important in it. People make the software and contribute to it to make it better.

Spot the difference in the image of the two laptop skins below. What has happened between 2013 and 2015?

Mahara community then and now

Mahara community then and now

Yes, It’s a different computer. I switched from silver to black. Fun fact on the side: The Mac Air only has a 13″ screen, but is even slightly wider than the Lenovo X1 Carbon which has a 14″ screen.

But back to the subject matter: The one on the right is more crowded because a bunch of Mahara community members joined. We now have the following contributor roles represented (starting at the top of the Mahara m):

  • Ninja: The all-around bug reporter, person answering questions in the community; bug fixer and all-around super contributor;
  • Student / user: Mahara user;
  • Robot: Not really a human person, but an important part automating things;
  • Translator: People who take on the big task of making Mahara available to non-English speakers;
  • Instructor / teacher / assessor (new): Complementary to the student;
  • Designer: People with magic skills making things pretty;
  • Packager: People involved in getting the codebase ready for release to the community;
  • Tester: People who test new or changed features before they make it into the codebase;
  • Writer: People who contribute to the documentation, no matter whether user or technical documentation, written or through screencasts and so on;
  • Organizer (new): People who organize Mahara conferences or user group meetings etc.;
  • Code reviewer: People who examine the code closely while it is in review. They comment on it to make it better before it is being put into the codebase;
  • Core developer: People with mad programming skills implementing changes in the core code;
  • Support (new): People who give support either in the community or also in their own organizations;
  • Security guard: People who make sure that Mahara is secure by either reporting issues, examining them or fixing them.

It’s amazing to have all these people in an open source project contributing to the improvement of it and working together towards a common goal.

Last year for Mahara Hui we asked the participants during the registration with which of the above roles (minus the new ones) they identified and displayed these on their name tags. That way, anyone looking at them knew directly how they were involved in the project and had an easy conversation starter.

Mahara Hui name tag with contributor roles displayed

Mahara Hui name tag with contributor roles displayed

How do you contribute to Mahara or another open source project?

25 Jan

High school students contribute to Mahara

This year, Catalyst organized the fifth annual Open Source Academy. It took place in our Wellington HQ from 5 to 16 January 2015. It was a full house again with 23 students. They came primarily from Wellington, but we also had a few from the Auckland and Canterbury regions. This year, girls outnumbered boys by three students. 🙂

The Academy

The first week, as usual, was a tutorial week in which the students learn programming basics, get acquainted with open source philosophy and tools, as well as learn what it takes to pull a software project together.

In the second week they get the chance to work on an open source project. There were five projects that the students could choose from:

  • Drupal – content management system
  • Koha – integrated library management system
  • Mahara – ePortfolio system
  • Piwik – web analytics platform
  • SilverStripe – content management system

All five software projects are popular open source applications that are used around the world. Catalyst staff who are core developers and experienced programmers in Drupal, Koha and Mahara, mentored students in these applications. It was great to have the Piwik core team on board again, and core SilverStripe developers for the first time.

The students fixed bugs, wrote new features, tested patches, and in the case of Piwik and SilverStripe also created a new theme each.

Students working in a group during the Academy

Students fleshing out user stories for their persona during the first week of the Academy. Source: Kristina Hoeppner, CC BY-SA

The Mahara team

This year, we had five students who wanted to work on Mahara. Hugh was the main mentor for the week helping the students with their programming questions and reviewing code. Jinelle introduced the students to automated functional testing using Behat.

Our five students created 29 patches over the course of just 3.5 days of which the majority has been merged into Mahara already. They fixed some bugs that have been around for a while and created a few new features that could be accomplished in that time. Not to forget the numerous tests they wrote for their fixes or features which enhance our growing test suite of automated tests. For example, they added:

  • Added help icons to numerous pages.
  • Replaced the old paginator with the newer one and added a drop-down menu for more flexibility on how many items to display on a page.
  • Added more passwords that users would not be able to choose because they are too simple.
  • Limited the number of characters that could be typed for a message type.
  • Changed language strings to improve them.
  • They removed superfluous items in the “Profile completion” administration interface and re-arranged another one.
  • Added a link to an artefact that was marked as objectionable so that the admin can go to it directly instead of just being taken to the page in which the artefact appears.
  • Added a bunch of automated tests.

The students had a good investigative sense when they read bug / feature descriptions and scoured the code to find the place where the change needed to be made. They were also pros at the end of the week working with git, checking out code, pushing code to the review system and finding files in the code base.

Although I was not able to spend lots of time with the students, it was always a treat to check in with them a few times during the day and see where they had gotten to and see if they needed any additional help.

At the end, the teams were asked to present what they had done over the course of the project week, and the Mahara students decided to write a Behat test to have their presentation run automatically within Mahara. What a great way to show their skills!

5 students working together on 1 computer

The Mahara students work together on their final presentation. Source: Kristina Hoeppner, CC BY-SA

View more photos from the Academy.

11 Jan

Tending to the Mahara feature request garden

The Mahara project has a vibrant community where users report bugs and also new features. We triage them regularly so that we have an overview of bugs that need fixing and also know what features users would like to see implemented.

However, our feature wish and bug list is quite long, and I’ve had the suspicion that there were items on it that we have already implemented, but not closed the item yet because it was reported a second time or because we implemented it in a slightly different fashion.

Thus, after reading Steve Klabnik‘s “How to be an open source gardener” the other day (hat tip to Hugh for pointing this blog post out), I decided to sit down this weekend and try to go through as many reports as I could to reacquaint myself with the requests and also see how many I could close.

Computer screen that contains a garden

I wanted to focus on the feature requests so as not to get mixed up with bug testing. Besides, there were already plenty reports to look at so that I didn’t need bug reports on top of that. 😉

Altogether, I reviewed 260 reports out of 476 in slightly less than 8 hours (approx. 1.8 minutes per report). I could already mark 28 as having been fixed in previous versions of Mahara. Closing off these almost 6% of triaged feature requests is a win even though it may not seem to be so much. It is great to remove items from the long improvement list and show users that we are making progress.

I was also able to identify feature requests that may not require much work that could be used for getting started to developing for Mahara. A developer is going to look at these items to determine whether they are really small tasks developmentwise or require more knowledge of Mahara. It is always good to have a number of small tasks readily available for people who want to contribute to Mahara so that they can succeed submitting a patch quickly. Our easy-to-fix bugs and features have the tag “bite-sized”. For slightly more experienced developers, the “snack-sized” items are a greater challenge, but still produce results quickly.

I also transferred all reports that I wanted to keep into a spreadsheet so that we can go through them more easily in the team and can filter them, add priorities etc. While I like Launchpad quite a bit, it does not allow for the exporting of bug lists as far as I know so that you can do some analysis around it or get a spreadsheet for further managing of individual items.

Next week, we will have a number of students of the Catalyst Open Source Academy working on Mahara. They will be looking at easy-to-fix bugs or features to leave their mark in an open source project. I already look forward to this year’s group of students working on Mahara. Their contributions will go into Mahara core and become part of the next release, which will be in April 2015.

Latest next weekend, I’ll tackle the remaining reports. Now that I know it is doable in quite an efficient fashion, it’s not such a daunting task anymore and definitely better than pulling weeds. 😉

21 Oct

Have your Mahara with music

Today was a big day as we released a new version of Mahara. It’s version 1.10 that contains a whole bunch of new exciting features and also bug fixes. Usability improvements are made alongside new functionality to help people create their ePortfolios and work collaboratively on projects that could be described as group portfolios.

Initially unrelatedly, I saw Josh Woodward‘s tweet about his Kickstarter project to fund the publishing of his new CD. I came across Josh’s music years ago when I was in Luxembourg looking for music to use for photo slideshows being mindful to only use music that I could use legally. What better place to look for music than on Jamendo where Creative Commons-licensed music abounded. It took me quite some time to dig through songs upon songs upon songs, but when I heard some of Josh’s I got stuck and have been looking forward to new songs from him since.

So when I saw his Kickstarter project I checked it out and was intrigued by the option to have a tune composed on any topic that I liked. Mhh… Why not have a song for the Mahara project? Wouldn’t that be cool? That’s what sprang to mind very quickly because I like topical songs like “Get my data out” and Josh’s own “Airplane mode“. But how to accomplish that without making it cheesy and like an advertisement jingle?

Josh was great with that because all I needed to do was give him an outline of the project, what we wanted to accomplish with Mahara and that I wanted the song to be more about the concept of portfolios and learning rather than mentioning Mahara all the time. I also noted down a couple of songs that I liked in particular in terms of mood and direction of tempo. And that was it. A few weeks later, I had a tune in my inbox. 🙂

Mahara tune

Mahara tune

What better time to take it live for the Mahara 1.10 release?

If you like it, sing along and enjoy some cool music. If it’s not your musical style, remix it and make it your own Mahara song. We publish it under Creative Commons BY-SA 3.0. Let me know if you want the instrumental version for your own Mahara song remix.

Icon by Thomas Grollier from the Noun Project CC BY 3.0.

07 Aug

Mahara User Group gathering at Pratt Institute

Yesterday, 5 August 2014 New York time, the New York Mahara User Group (MUG) met at Pratt Institute in Brooklyn, NY. The day started out for me by saying goodbye to Pleasantville, which indeed is very pleasant, where I visited with Beth from Pace University. She is one of the organizers of MUG New York and a long-time Mahara user.

We arrived right on time without a minute to spare for the start of the meeting because what would New York be without some traffic hiccups? 😉 Fortunately, I had already toured the Faculty Commons of Pratt two weeks ago and knew where we needed to go and what the room looked like. the Faculty Commons is an area for faculty to gather for learning about new technology, trying things out with the assistance of the Learning Technologies team and getting inspired by other users.

It was fantastic to see a great group of 15 Mahara enthusiasts from a number of institutions gathered. We could also welcome a number of people remotely. Unfortunately, the microphone did not work out well, and we ran into technology problems making it difficult for some of our remote participants to continue being in the session. Hopefully, future meetings will run more smoothly in that regard. However, 4 or 5 soldiered on, and it was great to get Sam T’s input from Southampton Solent University on assessment, support, badges and Mahara goodness in general.

If the video recording of the meeting worked out, it will be shared for any follow-ups. Beth will also share the resources that Sam mentioned so everyone can take a closer look at them.

We received a brief update from Pratt on using ePortfolios, discussed assessment possibilities and how to support users in working with assessments, and looked at a couple of work flows besides getting people excited and talking about badges and how they can work with them in Mahara.

Attendees were very interested in Sam’s work flows that she showed, and it was suggested to create an area where work flows could be shared.

The face-to-face MUG meeting was great because it fostered a different kind of interaction between the participants. Since we were sitting in one room, discussions were easier than if everyone were online. Sadly, the online participants didn’t have a great experience, but we hope they’ll stick with the group and participate next time that there is a purely online meeting. This will most likely happen at the end of October / beginning of November.


This MUG meeting was very helpful because it confirmed some things I already knew and sparked interest in exploring certain ideas further.

MUGs and MUGgers

User group meetings are great to facilitate discussions amongst users, share ideas, help each other, and connect people. Sam Egan and Beth Gordon from Pace University, who are the main organizers of the New York MUG do a fantastic job with these meetings. They are joined in their triumvirate by Keith Landa from Purchase College who makes the webinar technology available allowing remote participation and also the recording of the meetings.

Face-to-face beats online hands down

Face-to-face meetings still beat online meetings by far. I was fortunate to meet a bunch of Mahara users over the past two weeks and learn how they use Mahara and areas that they would like to explore.

Resources pool expansion

We are going to have areas on the wiki where users can share work flows for commonly used processes as well as templates that they have created. I am also thinking how to link to this in the Mahara user manual in an attempt to include more resources on the portfolio creation process and not just keep it as reference manual. This can be part of the crowdsourcing for expanding the Mahara user manual that I spoke about at Mahara UK in July.

Exploring badging

Badges are a hot topic and not one that is quickly discussed but needs a lot of thought and discussion at individual institutions. It is great that Mahara already has two plugins to display badges and to issue badges. I’d love to see colleges and universities discussing badges download these plugins and install them on a testing server to experiment with them and feed back their ideas about the functionality and possibilities of expanding them to make them work for their circumstances.

Badges are still a new idea in education, and thus, experimentation is needed to gain more insight. Don’t get me wrong, a whole lot of research has already been conducted or is currently under way, and badges are not thought of as just individual badges but as part of a badging ecosystem. However, there is still more work needed to implement it at more institutions and find the hooks why individual institutions might want to join the badging community.

So what is next?

There are few things in the making:

  • Canadian Mahara User Group meeting
  • Sharing of templates as Leap2A files for easy importing into other Mahara instances
  • Sharing of work flows
  • Organizing of the next New York MUG meeting which will be held online

If you want to get active in any of these initiatives or see what others are sharing, stay tuned for updates and links to the various resources on mahara.org or via Twitter.