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?

18 Feb

Scary document morning

When it comes down to working with text documents collaboratively, I’m a happy user of the track changes and comment functionalities because they allow people working together on a document to easily communicate about the text and see each other’s changes.

Over the last few days, a colleague and I have been working on a long document in LibreOffice. The document contains a number of tables and we’ve been making extensive use of comments as well as tracking our changes in this 40+ pages document. Last night, I was working on the document and accepted changes to a table as well as deleted some comments while the changes were still being recorded. I worked away at the document saving frequently. I left the document open over night since I wanted to work on it some more this morning. All went well until I closed the document.

Before sharing it with my colleagues, I wanted to double-check something in the document, but could not open it. Instead, I was presented with the following error message: Read-Error. Format error discovered in the file in sub-document content.xml at 2,4879(row,col).

LibreOffice error message

LibreOffice error message

Before going into panic mode, I tried the obvious: Closing the document and trying to open it again: No luck. I then sent it to a colleague to check if he could open it: Still no luck. Since I don’t know XML well, I went in search of someone who might be able to provide help.

That’s when my luck turned around since the first person I asked for help (actually rather if he knew who might have some more knowledge) was Grant McLean. He offered to take a look and if he could find the cause quickly, fix it for me. We conducted a quick search that revealed that it might be a problem due to an attribute being used twice in the style definition. The instructions didn’t prove too helpful, but Grant whipped up something very quickly which I’m going to share here for others to use if they are in need and for me to refer back to if I ever come across the problem again.

The instructions are for a Linux-based environment, in my case Ubuntu 14.04.

  1. Open the LibreOffice ODT file in the Archive Manager.
  2. Drag the content.xml file out onto the desktop to extract it.
    At this stage, the xml file displays everything in one long line which is not really helpful for debugging. So Grant used a little Perl script to make the file more readable. Since we were only interested in parts of the file, this script was sufficient and put in some line breaks.
  3. The script finds every instance of “/>” in the document and replaces it with a line break before “/>”. That preserves the syntax of the document itself, but allows us to get at least some line breaks in there making the document more readable. In the terminal at the prompt, type the following:
    perl -i -p -e ‘s{/>}{\n/>}g’ content.xml
  4. If you don’t have XMLLint installed, you can get it via:
    sudo apt-get install libxml2-utils
  5. Run the XML file through XMLLint to check where the error is. Note down the line number:
    xmllint –noout content.xml
  6. Open the file in your favorite text editor where line numbering is turned on:
    vim content.xml
  7. Navigate to the line with the problem. In my case, we saw the “office:name” attribute twice for one content item. Once it was removed, I could open the document again and continue editing.

But that’s not where the story ends. That would have been too easy. ;-) Since we saw that the problem was close by to / in a table, we assumed that the problem might lie there. So I located the table and removed all formatting, saved the file and could not open it again. Next I deleted the table from the file that Grant had sent me, re-created it manually, but still no luck. After some more tries with Chris Cormack who could open the file and edit and save it, we updated my LibreOffice to the latest version hoping that the bug might have been fixed. No such luck. So I went back to Grant to get the above instructions from him on how to fix this issue as it seemed that I would not be able to erase the problem quickly, but would need work on the document and after each closing run through the procedure to open it again. For the sake of being able to continue working, I was willing to use that workaround and leave the document open as much as possible.

Grant explained the steps and we jotted them down. While we looked at the document, he also showed me a neat trick:

If you open the document in vim, navigate to an attribute and press Shift+*, you are taken to the next place in the document where the same attribute is used. That’s how we found that the issue was actually with the annotations / comments and not the tables. Somehow working with annotations (possibly in a table) and deleting them while the track changes functionality was turned on, caused a problem.

Now I could get rid of the issue entirely: I deleted all comments in the document, and I could open it correctly again without dabbling in XML.

We assume that this is a LibreOffice bug, and I am happy to report it. Unfortunately, I have not yet been able to reproduce it in a small test document. It works fine there. I’ll probably need to create a longer document similar to the one that I’m working on and see if I can re-create the problem.

I’m thankful to Grant and Chris for their help, and also to LibreOffice whose files are actually archives and include an XML file that you can open in a simple editor and manipulate when you can’t open it in LibreOffice itself.

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.

12 Jan

The power of “Recent”

For several weeks now I have been using a functionality of my file browser that I had ignored religiously in the past. You see, Ubuntu, a Linux-based operating system, comes with Nautilus, which is the built-in file browser. For the most part, I file all my downloads or files that I create away in folders so that I can find them again later more easily and don’t have to hunt them down via search. That’s been working pretty well in the past.

However, I do save and create quite a few files per day. Especially when I save quick screenshots to send to our designers or clients, it does take a few clicks to get to the file again in my folder hierarchy. In order to speed up that process, one day I did click on “Recent” in the side panel, and a whole new world opened up. Suddenly, I had instantaneous access to all files that I had saved recently no matter in which folder they were located. Thus, I could save them in my folder structure with a bunch of clicks, but had them only one click away to add to an email or a support request.

Ubuntu Nautilus panel with recent files easily accessible

Ubuntu’s Nautilus with recent files easily and quickly at hand

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. ;-)