OLPC talk:Volunteer Infrastructure Group

Your ideas

IRC gateway for the Big Bosses

It might be nice to provide a web irc gateway for the big bosses in case they need to ping people who typically hang out there. There could even be a channel on oftc somewhere where knowledgeable people could hang out to answer VIP questions. Just an idea Seth 19:40, 21 August 2008 (UTC)

Forge a software development community

Proposal

please comment! Mchua 20:25, 21 October 2008 (UTC)

1. Solicit proposals from volunteers who want to install, configure, and maintain an OLPC gforge as to how they're going to install, configure, and maintain it, and why their group has the expertise to run it. One requirement is that the group that runs the gforge must always have a person in VIG as a point of contact, and another requirement is that the group must have a (publicly stated) way to welcome/train new gforge-maintenance members, and full public documentation on how to run that instance of gforge (minus things like passwords) so that it can be easily passed on if needed.
2. Choose one, run small (1 month?) trial. If the selected group needs resources, find non-OLPC resources (server-sponsorship, etc.) to get it up and going. Plaster "THIS IS A TRIAL" signs all over the page. Encourage small sprint groups to use it (have the month coincide with a Game Jam or two, or something similar.)
3. If 1 month trial period goes well, point an official laptop.org (gforge.laptop.org) thing at it, announce publicly.

Original discussion

This wiki should be replaced. Groups of pages need to be owned by individual people. Only they can write to them. If you wish to contribute, you should email them patches. If you wish to create your own pages, you should fill out a form, and email it to the wiki administrator. What? You what? You think this profoundly misguided? Disastrous? Sure to stop wiki development dead in its tracks? Certain to dissipate and prevent formation of a wiki development community? Well, yes. Of course. That's exactly what it's done for the activity development community.

No gforge, gitorious, github, or launchpad for OLPC. Little FOSS cell phone projects have better software development community infrastructure than OLPC has managed. That a community might collectively work together to develop activities, rather than each being created in isolation, has repeatedly seemed alien to OLPC core. Let alone community or infrastructure being a project roadmap objective. The open-source project with, hands down, the greatest potential to attract developers of any, has managed to almost entirely avoid doing so. And sometimes appears oddly puzzled and confused as to how. MitchellNCharity 05:26, 15 September 2008 (UTC)

What you say doesn't preclude a wiki, as you well know. It's clear that organization of Activity teams needs to be much improved to encourage development. It doesn't help that we break the api every few months :S. Christoph's Activity Handbook is a good step in the right direction, but not nearly enough.

The openmoko community is surviving in the face of multiple competing frameworks (and crippled hardware). I suspect api changes merely serve as rot, revealing there is no one around doing maintenance. MitchellNCharity 03:42, 28 September 2008 (UTC)

What would you specifically like to see? What do you think works best to organize activity development? I would love to see the VIG implement it. Send this to the mailing list, you have good points. Seth 00:42, 21 September 2008 (UTC)

Create a gforge. For years, it's been on the list of obvious things to do when creating a community software project, right next to create a wiki and mailing lists. Yes, it's PHP, and a headache. But lots of folks manage. Then perhaps consider some more modern, experimental tech, after OLPC has thus been unbroken.

Why doesn't OLPC have one? Someone tried for a day or so to set one up, got frustrated, and wandered off. Declared OLPC would never ever have an <explicative> gforge. Which is what passes for OLPC project management, with respect to community software development. All milestones can be met without interesting anyone in developing any activities. It's just never been a mission objective. Lack of a forge isn't an isolated failure. Emulation, documentation, all the building blocks of a community have been off-the-books, half-hearted efforts. So big picture, I'd like to see some project management for whatever fragment of OLPC wouldn't be entirely satisfied with all XO's going out XP or bare sugar.

Consider garage.maemo.org and projects.openmoko.org, forges for some Nokia tablets, and a non-working cell phone. Both projects are similar to OLPC - customizing linux, and developing applications, for specific and odd hardware. They have faced many of the same issues. But they have developers. They have, in general, done a much better job of creating community infrastructure and community. Despite the potentially much greater appeal of OLPC. Or perhaps because of it. They knew attracting community would make or break them, and prioritized it. OLPC has had dreams of "there will be a big bang, we'll suddenly have millions of orders, and everything will take care of itself". Didn't happen, isn't going to, and OLPC hasn't adapted.

Note that wandering maemo.org and openmoko.org can be a source of other ideas as well. MitchellNCharity 03:42, 28 September 2008 (UTC)

See http://blog.melchua.com/2008/09/28/forging-a-software-development-community/ for more notes on this topic. Mchua 20:19, 21 October 2008 (UTC)

How can we optimize a system - technical and social - that gives us the largest and most varied pool of stable, volunteer-maintained, open-source, kid-hackable educational Activities possible? Gforge, workshops, bounties, documentation, toolchains, access… through any means possible, how would you maximize the number of Activites that meet the above criteria?

At the risk of indefinitely delaying matters by mentioning alternatives, here are some other points in design space.

• Set up an olpc gitorious site, forking and developing gitorious. Gitorious is a FOSS ruby on rails and git-based site. It started at the same time as the closed source github, which unfortunately won the first to market network competition for the ruby community. Advantages: simple; easy forking; clean integration with existing trac gits. Disadvantages: betaish code; does only a few things; doesn't support teams; minimal community; development in ruby required; politics of ruby vs python. The amount of ruby coding needed makes this a non-starter from a project perspective, unless there is someone(s) out there with ruby skills for whom this would inspire a major commitment. Then olpc could end up with something quite nifty, rather than merely "not great, but that's the sad state of FOSS SCM". This could be parasitic on existing OLPC infrastructure, and furthering gitorious a valuable thing in itself, so if you are a someone(s) so inclined, I'd suggest just do it. MitchellNCharity 21:42, 21 October 2008 (UTC)
• Declare launchpad home. Canonical's site for Ubuntu and FOSS projects. Advantages: requires only a policy decision; exists; supports teams; stable; large ubuntu and python communities. Disads: easy forking isn't there yet[1] (though teams softens the impact somewhat); closed source (though FOSS promised for next year); non-olpc community; it's someone else's system; bazaar vs git; canonical vs redhat. The large non-olpc community seems likely to both be an advantage (pool of people to attract from; better integration with non-olpc projects), and disadvantage (less olpc-centric sense of community, so less tight nit and focused). Teams are great, lack of easy forking regrettable, but no FOSS SCM has both yet. MitchellNCharity 21:42, 21 October 2008 (UTC)

I-g documentation discussion

Currently most sysadmin documentation is on OLPC internal wiki, which is generally only open to NDA'ed employees and select contractors.

Here are some proposals on how to publish and protect i-g documentation.

1. Put docs, passwords and other information onto a protected area of teamwiki.
2. Put the information onto public wiki, and use encryption such as gpg to encipher sensitive data such as passwords.
3. Use git, and rely on git access controls for protection. Possibly transclude git to wiki.
4. Put data into a text file on the root directory of a machine.

Please edit and add arguments pro and con.

Hhardy 17:41, 20 August 2008 (UTC)

See Michael's proposed infrastructure-documentation-system requirements and comments on that Talk page

Adric's draft RT_Strategies doc

User:Adricnet/RT_Strategies

Page needs reorganization

Competing and uncoordinated edits have made the page not as clear and well organized as it could be. Hhardy 01:56, 3 December 2008 (UTC)