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
- Quality over quantity is good, but one single institute doesn't often has enough quality students to participate.
- Having per-city events, however, can solve this issue. As there are multiple institutes in each cities, each having handful of kick-ass students who can benefit from the events. And together, the number of participation will also be spectacular.
- We can start with 6 events in 6 cities - i.e. holding 1 event each 2 months. The candidate cities can be:
- P.S: having a lot of swags/goodies/giveaways do solve the number of participation - but remember, we're talking about quality here.
- P.P.S: ...and I'm not saying "no" to goodies, for the ones who deserve it. I'm okay standing up a while with goodies in hand to giveaway, while the person to receive them is too busy uploading his second patch of the day, just 5-feet away & completely ignores the rest of the world. :'D
- 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
- The Events Task Force does the needful to promote the event in a region.
- The open-invitation contains a link to a test-paper (in form of a Google Form) with related technical questions (objective/MCQ) & contact info.
- The Form-Response will be conditionally formatted to automatically screen as a first pass.
- 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.
- 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.
- 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.
- 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.