02 April, 2014

Laying Stones for Mozilla India Developer Engagement v2.0

In this post, I'm gonna briefly raise some key issues & suggest half-baked solutions about events in India. It's heavily focused on developer-events, but some bits are pretty generic. These are from the discussions, experiences and findings under the lights of the following events:
Before I dive in - like a side-note, I'd like to mention - since 2012, we've tried to increase developer contributions in India heavily. Some low hanging fruits, to start with; and they have generated results. Now it's time to take some further steps, and evolve further.

But there are some blockers.

Very real ones.
Most challengingly(!), non-technical ones.

Thoughts on developer-hosted events

  • They are Procedural
    • They can plan properly and execute efficiently. Something that's not vastly common in South Asian region.
  • They are Innovative
    • Given an opportunity, they make a mark with something unique. Aniruddha's Contributor Training Days, Sankha's MozBoot, Avik-Gaurab-Subhashis' ProgramIIEST are the examples. These events set higher bars, and formats/templates for others to follow.
  • They offer quality over quantity
    • Most successful developer events we have now a days, have much less number of participants, yet very high impact in terms of outcomes from them.
  • Deprived of appreciation & support
    • Even though most of them don't enjoy handling the logistics, they do it just as good when they have to.
    • But, instead receiving supports while they're at it, they get last minute budget approvals, budget cut-downs, enforced change of plans, and all sorts of things which make them re-think whether it was a bad idea to conduct an event at the first place.
    • This discussion can go a long way, cutting it short for now.

Organizing Developer Events has to be re-shaped

  • Per City events, instead of per Institute
  • Better screening of the participants
    • When we're talking about city/region wide events, it's obvious that there will be a heck load of participation - along with noises.
    • Thinking about a process to screen the participants which ensures quality, and yet is very efficient at it without requiring tiring efforts
      1. The Events Task Force does the needful to promote the event in a region.
      2. The open-invitation contains a link to a test-paper (in form of a Google Form) with related technical questions (objective/MCQ) & contact info.
      3. The Form-Response will be conditionally formatted to automatically screen as a first pass.
      4. Based on the event's intake-capacity, we send out followup to 1.5x numbers of candidates from the merit list. This followup will contain the ask-for-confirmation of the participant's availability; and some objective (yet not-auto-screenable) questions - such as GitHub profiles, related experience, expectations & focus at the event etc.
      5. Based on the response, final invitation is sent to the 1.2x (top 120, if the venue capacity is 100) candidates. There will always be last minute turn-downs from some candidates. We'll have to tweak the quotient (1.2x) after few trial and errors.
    • The process of tests, registration, followup also ensures the candidates are mentally seasoned & committed to participate, and has the sense of making their way through all the initial applications.
  • Continuous follow-up with attendees
    • Usually, we get 1/2 participants in each event who are pretty quick to learn the mode-of-communications in FOSS-world. Readily swims through IRC, Mailing Lists, figures out how they work & says "hi" to the known nicks.
    • In cases where they don't, we need to actively think through what all options can we explore to have a connection with them, after we leave.
    • There are several suggestions on this; all very obvious, most quite spammy and none very effective.
  • Venue rating system for future events
    • Even if we have major per-city events, there going to be per-institute events as well, we can't totally block that.
    • But we can have a rating-chart for venues where we already have hosted events, how was the experience & what's the prospect of hosting another event in there.
    • We can have pretty objective details, such as:
      • Interests of the faculties
      • Interests of the Students
      • Effectiveness & turnouts
      • Quality of Infrastructure (Lab, Systems, Internet)
      • Quality of Logistics (Travel, Costs, Environment)
      • ...and more

Lesser side-loaded overheads, more deep-dive

  • Stop losing the first half of the event setting up the development environments. That's a big bummer. Everytime.
    • It wastes time
    • It expects developers to be SysOps too
    • Requires good Internet (which, bytheway, is a myth)
    • Requires dealing with unnecessary complexities, which can be abstracted away
    • Once set up on Lab-PC, the student has to go through again on his own system, at home - hitting gotchas, and getting frustrated.
  • Distribute ready-made DevEnvs
    • We've tried giving out setup VMs
      • Works as expected, but
      • Requires setting up VM itself
      • A 20GB image is not quite portable
      • Can't use the full system/processing power.
      • Looooooooooooooooooooooooooong build-times.
  • Distribute Live USB drives
    • How about branded, special-edition pen-drives with ready-to-boot Linux image, and persistent developer-environment (dependencies, cloned sources etc.) in it?
    • A USB 3.0 16GB can have a proper Linux installation in it - and can be readily replicated to as many as required
    • A monthly ISO image of the same, hosted from a trusted source - just like mercurial bundles
    • The participant can use the same thing on the Lab-PC & his laptop back home without losing a thing!
    • The pen-drive itself can be a very useful giveaway.
  • Ready to use OpenStack instances
    • OpenStack can give us an infrastructure to create a couple of identical running systems in seconds
    • In longer run, we can have a beefy OpenStack deployment where we can quickly create pre-setup small VMs for the participants
    • We can also have a couple of build-machine VMs as local-tryservers.
    • A lot of discussion may need to go into it - but this has a prospect of being a cross-project, cross-community, permanent solution for the problem in hand.

Thanks to Avik, Gaurab, Manish, Saurabh, Subhashis, Umesh - everything discussed here are collective decisions (albeit among a small group), in multiple passes.

If you have thoughts regarding/around these - I'd be eager to know.