Skip to main content

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.

Comments

  1. Why not provide links to VMs / setup prerequisites during the event invite? Those who do their homework can get started early.

    ReplyDelete
    Replies
    1. That's already there... we do ask the candidates install dependencies.

      But if using Lab Computers, students can't pre-setup them; most often we don't even get root/su to prepare them beforehand; even if we do have root/su, we don't have access to lab the day before.
      If using pre-configured personal Laptops, often there isn't enough power plugs for all. Also, depending on hardware-spec, the devenv isn't easy replicable. Also, it doesn't solve the problem of initial high-barrier for the student, who is more interested in coding than sysop-gotchas.

      Also, most students don't have much download-limit at home.
      Dependency resolution isn't bandwidth friendly.
      Downloading VM is a joke.

      Albeit unmentioned, we had thought about these as well.

      Delete
  2. Hi,

    I really liked the idea of ready OpenStack instances. Except for the top tier colleges in India, installation is the biggest barrier either due to internet connection, not a well equipped computer labs, etc in most of the Indian colleges which eats half of the time. Pre-configured Vagrant boxes can come in handy.

    Also, I feel that after event communication is necessary and the organizers should identify the interested, knowledgeable participants. Some participants also are shy to talk in public but are extremely talented. Talking to them occasionally helps a lot.

    ReplyDelete
  3. Tim just did this : http://timtaubert.de/blog/2014/04/a-ready-to-use-virtual-build-environment-for-firefox/

    ReplyDelete
  4. I read it.Really a nice and useful post i was looking for this kind of stuff from long time.. thank you...
    Visit:- Mozilla Firefox Support



    ReplyDelete
  5. Though this is old. I kinda got interested in this post (didn't follow you earlier).
    So straight to the question:

    Did you find any solution/implementable solution of your pre-build setup problem? I have something in mind which is tested and I use quite a lot for my workshops hence you can say field tested.

    ReplyDelete

Post a Comment