31 Jan

Career portfolios – gathering evidence for the Field Guide

At last year’s AAEEBL conference, a new initiative was founded: Writing The Field Guide to ePortfolio. The writing part is accompanied by a series of webinars. The Field Guide is geared towards administrators and decision-makers in higher education. In essence, it’s going to be an executive briefing on ePortfolio and thus a fairly short but information-packed and valuable publication.

Why a Field Guide?

Primarily, the question “How” is going to be answered to support them in realizing the concrete potential of ePortfolios and their place in their institution not just for one department or a small group of students but at scale across the entire campus.

To answer “How”, the Field Guide author team is looking at the following areas to be covered in 12 chapters (working titles):

  1. What does it mean to move to a portfolio-based institutional learning ecology?
  2. Redesigning learning: ePortfolios in support of connected, social, and reflective pedagogies
  3. Authentic learning and teaching
  4. Reflective practice and folio thinking
  5. Learners and the digital era: Digital identity; literacy in digital forms
  6. ePortfolios and institutional challenges: Assessment, outcomes, engagement, retention, completion, quality
  7. New ways to demonstrate achievements: Warranting evidence
  8. Transition to career and career development
  9. Learning analytics and the learner
  10. Creative teaching portfolios
  11. Internationalisation and global learners
  12. How important is the technology

Career portfolios

I chose to be part of chapter 8 and look into portfolios preparing students for their career and support career development. There are four other collaborators on my team from institutions of higher education in Australia and the U.S.A.:

The five of us have the challenge to condense our ideas into three pages for the Field Guide (yes, that includes abstract and references and everything else!). Fortunately, we can link to more extensive resources and case studies elsewhere online. Some of them may sit on the companion website for the Field Guide that is going to be set up.

Our timeline is short (chapter drafts are due by the end of March) and our ideas are many. Currently, we are in the gathering phase, which will come to a conclusion soon. We decided to focus on the following areas for the gathering of articles, research and supporting arguments:

  • Why do we do what we do, i.e. work with ePortfolios?
  • Are employers demanding ePortfolios?
  • Do we need our résumé anymore?
  • Where do authentic experiences come to play?
  • How is the voice of the student translated?
  • What about assessment as work-integrated learning?
  • How is career development and not just career entering supported?
  • What about branding – self- and institution branding, self-marketing and promotion?
  • How do graduate attributes fit in?

These are a lot of areas to cover off in three short pages. During our current brainstorming phase, we may consolidate a bit more and see what we’ll include eventually.

How you can help

While we already have a good amount of information and resources, if you have research or studies or surveys that could support our writing in the above mentioned areas, please let us know in the comments.

For example, we’ve come across a couple of employer surveys from 2008 and 2013 in which they were asked about their position towards ePortfolios. If you conducted your own survey at your institution or with employers recently (within the last two years) it would be great if you could share it. Did you conduct a survey amongst students or graduates or even alumni on their use or perceptions of a career portfolio? Does your career services department have evidence of portfolios supporting students entering the workforce or continuing at university?

Or if you prepared a document for your own administration in which you highlighted reasons for implementing career portfolios and have research for us to look into, please let us know.

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.