[maemo-community] Council Nomination: Ryan Abel

[From: Ryan Abel]

On Mar 15, 2010, at 9:47 PM, Ryan Abel wrote:

> Much appreciated, Matthew. I've actually been flip-flopping over whether or not to run for the past few months, but I think I've finally decided to do so, sooo here's my spiel:

And here are my responses to Andrew's questions. . . .

> Sprint process
> ~~~~~~~~~~~~~~
> This is the main organised point of contact between Nokia, the paid
> contributors and the community, however the maemo.org sprint process
> is quite heavy for volunteers and it often seems to be a checklist
> affair; rather than a collaborative planning exercise.
> 
> 1) Do you see any flaws in it, and how do you think it can be improved?

I do, a big part of the purpose of the monthly meetings is to get as many of the stakeholders and interested parties together in the same place as possible. Simply running through a list of tasks doesn't require that everyone be in one place, and I believe contributors are starting to forego the meetings because of this. It's tough to get people from so many disparate timezones with such hectic schedules in one place, and utilizing everyone's time as well as possible is a must.

To that end, the focus of the monthly meetings needs to change. Task summaries can easily be placed on the wiki before the meeting, so the meeting itself should consist of focused discussion of tasks and priorities. More discussion, less box-checking.

> 2) What are your thoughts on ongoing communication during the sprint?

It's difficult to keep communicating while you're working. It tends to feel like it distracts from the work itself (we all know how expensive context switching can be), but good communication is a must to reap full benefits of the agile development process.

While communication has improved greatly since we first implemented the sprint process on maemo.org (use of Quaiku, in particular, has been a big help), it's difficult for people not directly involved in a task to get a good overview of progress at a glance. Following the workstreaming is great for seeing that activity is taking place, but doesn't give you much of an overview, and doesn't exactly invite outside participation. Task owners need to be more zealous about updating a task's corresponding wikipage as work progresses and making sure anybody outside looking in can get a good idea of where progress stands and where they can help.

Opaque processes discourage contributors, transparent ones will help increase the number of helping hands and make things easier for everybody in the long term.

> MeeGo
> ~~~~~
> MeeGo is, IMHO, the single biggest thing to happen to Maemo since the
> 770. In many ways, it's the opening up of the design processes that
> many of us have wanted in Maemo for so long. As Maemo as an operating
> system disappears, this will have a big effect on the community.
> 
> 3) As we move from "day zero" to "day one", what do you think the
> priorities for the MeeGo community should be?

We need to take the lessons about infrastructure and community-building learned at both maemo.org and moblin.org and make sure we have a rock-solid foundation in place for when the first MeeGo devices start shipping and people come streaming in. We want to avoid, or plan for, the growing pains as much as we can to reduce community turbulence and direct as much of that new energy towards productive ends as possible.

> 4) Should leaders in the MeeGo community (whether from a Moblin or
> Maemo background) try to move the existing communities with them to
> form the MeeGo community; or should a new community form around the
> operating system and its devices?

Obviously simply moving user databases and changing themes on existing tools makes no sense. MeeGo is a new platform whose focus doesn't really match that of either Maemo or Moblin. I don't think we can try to force those communities together into a MeeGo community. People who are interested in MeeGo and what it represents will follow, those who aren't will hopefully have a strong infrastructure to carry them forward for as long as possible.

> 4a) If yes, what steps should be taken to prevent overreactions and
> allegations of "take over" that happened when internettablettalk.com's
> theme changed to match the rest of maemo.org?
> 
> 4b) If no, how do you see the relationship between the Maemo community
> which has been "left behind" and the MeeGo community? How does the
> Maemo community stay vibrant if large portions on moving on to Maemo's
> successor, or drifting away to other mobile platforms?

Honestly, I think a lot of this will depend on Nokia. Although I hesitate to bring up the dreaded MeeGo-on-N900 issue here, the fact is it's going to have a /very/ large effect on what the MeeGo community ends up looking like in its infancy. If the large number of N900 users (and, even, possibly N8x0 users) get a viable upgrade path to MeeGo then it's really a moot point, but if not the best that can be done is to assure that the infrastructure is as solid as it can be. Without new development vibrancy is certain to fade over time, and there's really little that can be done to fight that.

> 5) What are your thoughts about existing maemo.org resources (such as
> Extras, auto-builder, Bugzilla) as Nokia, and the paid contributors,
> look to the future?

There's a part of me that hopes Nokia chooses to do its best to obsolete them by giving customers an upgrade path moving forward. So, really, it's going to depend, but at the very least I think we'll just have to get them as usable and stable as we can over the next year or so so whatever userbase remains with Maemo will have a strong infrastructure to support it.

> Community
> ~~~~~~~~~
> 
> 6) How can we encourage more, and higher quality, applications for
> Maemo - and specifically through Extras?

The QA process needs to be streamlined to reduce developer overhead as much as is reasonable (without losing the QA part ;)), the Extras acceptance process needs faster turn-around (Niels does a great job, but even 12-24 hours is too much), and we need better organized and easier to find documentation to back all of this up. Extras has to be either be easier and/or provide more benefits than any alternative. Things like the autobuilder go a long way towards that goal, but it needs to be fast (ideally at least as fast as the fastest desktop rig out there), it needs to be hassle-free. Side benefits like bug tracking in Bugzilla and free QA through Valério's testing squad will also encourage more developers to use Extras.