The following is a video interview with Stephan Heilner, project lead with the Gospel Library and LDSTools iOS projects. We talk about how to help out with the iOS projects, among other things. We recorded this video at the August LDSTech Service Day.
The following is a general transcript of the video.
TOM: I’m Tom Johnson and we’re at the LDS Tech Service Day. I’m talking with Stephan Heilner, one of the project leads for the iOS projects. iOS is Apple’s mobile operating system, used on devices such as the iPhone and iPad. Stephan, tell me about your role -- what kinds of projects are you managing, what’s the scope?
STEPHAN: The two projects I mostly work with are LDS Tools and Gospel Library. Internally, I’m the only one working on LDS Tools. With Gospel library, we have two full-time employees working on it. I probably spend 90% of my time on the Gospel Library.
TOM: How many people from the community are part of these iOS Projects?
STEPHAN: We have a lot of people signed up on the LDSTech site. But as far as actively engaged volunteers on the project, we probably have 10 volunteers on each project, actively contributing and involved in weekly meetings, committing code, testing, and responding to users. The community participation level comes and goes. The summer time right now is different from the rest of the year because many people would rather be out at night instead of sitting behind their computers programming (I think).
TOM: You mentioned that you have about 10 active people on each project. About how many people are there total on the project?
STEPHAN: I’ve never actually counted, but I bet it’s somewhere between 80 and 100. On each of these two projects we have a huge list of people who have at least set up to be observers. Most of them are testers on our apps and they get early access builds.
TOM: As a community project manager, how do you engage all the incoming people? Even 10% participation isn’t bad for community participation.
STEPHAN: To keep people involved, we have weekly meetings and try to coordinate with the whole team to see what times work best. We’ve tried early mornings as well as late nights. The best time for people is a lunch time meeting. For whatever reason, people can usually take 30 to 45 minutes during lunch and call in.
We also assign each task and issue to different releases in JIRA and make sure we keep JIRA up to date all of the time so that people know what’s been worked on and what remains.
During our weekly meetings, we literally pull up JIRA and go through it line by line. We also assign tasks to volunteers at this time, and if people need any explanation about what something means, we offer that right there. Part of what’s made community involvement successful is using JIRA regularly. That way the community knows what we know about the status of everything.
TOM: Let’s say you have a weekly meeting and you get only 5 people on the call. How do you engage the rest of the people who don’t participate in the weekly meetings?
STEPHAN: We have a project manager, usually a community volunteer, on the call every week to keep notes during the meeting. He or she writes out a summary and sends out meeting notes. People who weren’t able to attend the meeting can get the list of what we talked about and try to stay in the loop. We also use Google Groups to communicate with the team. All of the 100 people or so are in our Google Group. Whenever we send an e-mail to the group, everybody gets it. People can follow things as they progress. This helps everyone feel like they are tied into the project.
TOM: I recently listened in on one of your past meetings. You talked about focusing community efforts on bug fixes, testing, and e-mail support. Can you talk a little bit about that strategy?
STEPHAN: One of the biggest challenges we face is handling user feedback. Unlike a lot of the other groups, all of the feedback comes directly to us. We don’t have the Global Help Desk field these e-mails for us. We get all of that feedback. Bug reports, feature requests, complaints -- everything comes straight to us.
We have a hard time staying on top of it all because of the volume. We have around 350,000 users on the iOS platform using the Gospel Library and another 150,000 using LDS Tools. With that many users, it’s a numbers game. We are going to get feedback. Even if the app were perfect, we would still get lots of e-mail.
Being able to respond to users when they ask questions or have problems is something that’s important to us, but we don’t have the time. If we get 100 e-mails in a day, it’s hard to take the time to go through them and respond to every user. We do respond, but most of the time we spend responding is on our own time -- at night time or early morning and in weekends. Overall, we spend a lot of personal time responding to those e-mails.
Since a lot of the questions are the same, we create text snippets that we can send to people over and over again to make it easier. Having community help, however, would alleviate the load that we feel. These responses would be easy for anyone to create who knows the app and its known issues and fixes. We’ve had community help out with support in the past -- they were great. A lot of times they gave more thorough responses than we ever did. It was really cool when we had it working. If community volunteers would like to help out with e-mail support, we could really use their help.
TOM: What about your strategies for bug fixes and testing?
STEPHAN: With the Gospel Library, we have a lot of internal dependencies right now. We love having development help, but our current phase doesn’t lend itself well to community development. What we can really use help with is quality assurance.
With the quality assurance (QA) tasks, we ourselves try to do QA, but it’s much better having a lot of people view and test the app. Having engineers that know QA go through lists of test cases and follow things that we want them to specifically test is helpful. Additionally, if users already have the right device, that’s also helpful because they may use it in a way we aren’t expecting.
In contrast, submitting an app to the app store, waiting a week for the approval process before it goes live, and then finding problems isn’t very efficient because then you have to go through the process all over again to fix bugs that are later discovered. If we can find bugs in our test cycles, we can quickly fix it and push out another update immediately.
TOM: For people who want to get involved in testing, e-mail support, or bug fixes, they can go into LDS Tech, click Projects, and join your project. Then what happens?
STEPHAN: We periodically add those people to our project’s Google Group. As we push out releases and as we get closer to a release date (we’re getting close with our 2.4 release), we’ll start sending out communication about how we need some help with testing. We also plan to work with Kevin Fitzpatrick on the QA side to come up with some test cases that we can have some community volunteers go through. That’s when we want to start engaging the testing resources within our project community. It is so much less painful for us to find bugs before we release the app to the public.
TOM: Thanks for talking with me Stephan. I appreciate it.