Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Please create a copy of this template and curate a learnig activity
Name: A catchy, descriptive title for the activity.
Category: The broad area the activity falls under (e.g., Tech, Soft Skills, Community Building).
Type: The activity format (e.g., Workshop, Seminar, Meetup, Hackathon).
Summary - oneliner: A brief, engaging sentence that captures the essence of the activity.
Purpose: The main goal or objective of the activity. What do you aim to achieve?
How: A step-by-step explanation of how the activity will be conducted. Include main agenda items.
Expected outcome: What participants should gain or achieve by the end of the activity. List key takeaways.
How to measure impact: Methods to evaluate the activity's success and participant learning. Include both quantitative and qualitative measures.
Pre-event checklist: Essential tasks to complete before the activity begins. Include logistics, materials, and communications.
Post-event checklist: Follow-up tasks to ensure the activity's impact is maximized. Include feedback collection, resource sharing, and next steps.
Curated by: Name or team responsible for designing and organizing the activity.
Ideal audience: The target group that would benefit most from this activity. Include any prerequisites if applicable.
Resource Links: Useful references, tools, or materials related to the activity. Include both preparation and follow-up resources.
This template provides a comprehensive framework for documenting activities, ensuring all important aspects are covered and making it easier for others to understand and potentially replicate the event.
ask about the activity trying to structer it to the teamplate, ask many as questions connected to the activity
Please create a copy of this template and curate a learnig activity
Name: A catchy, descriptive title for the activity.
Category: The broad area the activity falls under (e.g., Tech, Soft Skills, Community Building).
Type: The activity format (e.g., Workshop, Seminar, Meetup, Hackathon).
Summary - oneliner: A brief, engaging sentence that captures the essence of the activity.
Purpose: The main goal or objective of the activity. What do you aim to achieve?
How: A step-by-step explanation of how the activity will be conducted. Include main agenda items.
Expected outcome: What participants should gain or achieve by the end of the activity. List key takeaways.
How to measure impact: Methods to evaluate the activity's success and participant learning. Include both quantitative and qualitative measures.
Post-event checklist: Follow-up tasks to ensure the activity's impact is maximized. Include feedback collection, resource sharing, and next steps.
Curated by: Kurian Jacob
Ideal audience: The target group that would benefit most from this activity. Include any prerequisites if applicable.
Resource Links: Useful references, tools, or materials related to the activity. Include both preparation and follow-up resources.
This template provides a comprehensive framework for documenting activities, ensuring all important aspects are covered and making it easier for others to understand and potentially replicate the event.
ask about the activity trying to structer it to the teamplate, ask many as questions connected to the activity
Name: Flutter Study Jam – Online
Category: Education, Mobile Development, UI/UX
Type: Study Jam
Summary - oneliner: A 5-day online program introducing Flutter and Dart for building real-world cross-platform apps with Firebase integration.
Purpose: To provide hands-on experience in Flutter development, covering Dart basics, UI building, state management, and Firebase backend integration in a peer-learning format.
Core Concepts Coverage:
Dart Language Basics (syntax, functions, data types)
Flutter SDK Setup & First App
UI with Stateless and Stateful Widgets
App Navigation & Routing
State Management using Provider
API Integration using http
Firebase Setup, Auth, and Firestore
How:
Program run over 5 consecutive days online
Daily theme: content, practice, and activity
Live coding, group projects, and doubt clearance
Project: Todo or Notes App with Firebase backend
Expected Outcome:
Strong foundational understanding of Flutter
Ability to build and deploy multi-screen mobile apps
Familiarity with state management and Firebase
Practice with peer programming
How to Measure Impact:
Completion of daily hands-on activities
Project completion and demo
Firebase integration and data handling
Peer review participation
Pre-event Checklist:
Share prerequisites and install guides
Setup support channels (Discord, WhatsApp)
Publish Flutter intro and Dart basics resources
Assign facilitators or buddies
Post-event Checklist:
Host project demos & record showcases
Collect feedback from participants
Share continuous learning resources
Connect learners with Flutter dev communities
Curated by: Anirudth, Toch
Ideal Audience: Beginners interested in app development. No prior Flutter knowledge required.
Resource Links:
Name: Useless Project
Category: Tech
Type: Project Building
Summary - oneliner: An overnight project-building activity challenging makers to create impractical projects, fostering creativity and skills development in a fun and engaging environment.
Purpose: To provide a unique, engaging platform for makers to showcase their technical skills and creativity by creating intentionally impractical projects, all while having fun.
How:
Set up the venue with necessary infrastructure (Wi-Fi, power outlets, etc.)
Welcome participants and assist with registration
Facilitate the live-streamed opening ceremony
Support idea generation and team formation in both Software and Hardware
Provide ongoing support and mentorship during project development
Oversee project finalization and preparation for presentations
Manage local project presentation
Participate in the live-streamed closing ceremony
Expected outcome:
Students gain hands-on experience in project development
Enhanced creativity and problem-solving skills among participants
Strengthened campus community and increased interest in technology
A unique, impractical tech project representing your campus
How to measure impact:
The number of makers who completed the project
Quality and creativity of projects (based on judging criteria)
Participant feedback surveys
Social media engagement and reach
Pre-event checklist:
Secure and prepare the venue (ensuring 18-hour access)
Set up reliable Wi-Fi and power supply
Arrange for food, water, and necessities
Coordinate with campus administration for permissions and support
Post-event checklist:
Make sure participants mark their feedback in the Hub app
Clean up and restore the venue
Send thank you notes to mentors, supporters
Share project highlights on social media and campus channels
Curated by: Kurian Jacob
Ideal audience: Students from all disciplines interested in technology, innovation, and creative problem-solving. There are no specific prerequisites, but basic familiarity with any tech tools or programming languages is beneficial.
Resource Links:
TinkerHub Foundation guidelines for physical Activities :
Sample Project idea:
Judging criteria:
Branding Guidelines :
Name: Intro to Computer Science - Python
Category: Education, Technology, Community Learning
Type: Study Jam
Summary - oneliner: A collaborative learning program where first-year students master computer science fundamentals through Python while building a strong peer learning community.
Purpose: To build a strong foundation in computer science fundamentals through Python programming in a peer-learning environment, while fostering a supportive campus tech community.
Core CS Fundamentals Coverage:
Introduction to Programming Logic
Variables and Data Types
Control Structures (if/else, loops)
Functions and Methods
Lists and Arrays
Basic Algorithms
Debugging Fundamentals
Problem-Solving Approaches
Basic Object-Oriented Programming Concepts
How:
Program Registration via Hub App (minimum 10 students)
Weekly Study Sessions:
Session 1: Course content review
Session 2: Practice problems
Expected outcome:
Solid understanding of computer science fundamentals
Practical Python programming skills
Experience with peer learning methodology
Integration into the campus tech community
How to measure impact:
Weekly physical meetup discussions
Course completion progress tracking
Peer review sessions
Group problem-solving success rates
Pre-event checklist:
Register program on the Hub App
Set up clear participant requirements
Create study group guidelines
Prepare meeting schedule
Post-event checklist:
Collect feedback through the Hub App
Connect participants to TinkerHub community
Share success stories
Introduction to campus tech communities
Curated by: Kurian Jacob
Ideal audience: First-year students interested in computer science and programming, with no prior experience required but a strong commitment to learning.
Resource Links:
Khan Academy Python Course:
Name: Monitoring Dashboards with Grafana
Category: DevOps, Backend Monitoring, Observability
Type: Study Jam
Summary - oneliner: A 1-day offline workshop to help learners build end-to-end monitoring dashboards using Prometheus and Grafana.
Purpose: To teach participants how to instrument applications, collect metrics, and visualize system performance using the Grafana observability stack.
Core Concepts Coverage:
Prometheus fundamentals & metric scraping
Name: Intro to Computer Architecture & Assembly Language
Category: Education, Technology, Community Learning
Type: Study Jam
Summary - oneliner: A hands-on study jam where students explore how computers work at the lowest level by learning assembly language and basic computer architecture.
Purpose: To provide students with foundational knowledge of how computers execute instructions at the hardware level, develop an appreciation for low-level programming, and build a peer-learning community around systems thinking and computer internals.
Core Concepts Coverage:
Basics of Computer Architecture (CPU, RAM, Registers)
Name: O-Penn Mic Category: Discussion Series Type: Weekly Tech Discussions Summary - oneliner: A women-exclusive weekly discussion series fostering tech confidence and knowledge sharing across campus communities. Purpose: To boost women's participation and confidence in tech-related fields through regular discussions, learning, and project sharing.
How:
Weekly topic release in WIT Leads group and via email
Participants review provided learning resources
Name: Arduino-Powered Automatic Light System
Category:
Type:
Summary - oneliner: A hands-on project to build an automatic light system that controls itself based on ambient light using Arduino and a Light Dependent Resistor (LDR).
Purpose: To teach Arduino programming, sensor integration, and basic electronics by creating a practical automatic lighting system, which can be applied to scenarios like streetlights.
How:
Introduction to Arduino and its components
Name: Model Context Protocol – FastMCP Workshop
Category: AI Infrastructure, Developer Tooling, LLM Ecosystems
Type: Study Jam
Summary - oneliner: A 3-day deep-dive workshop into building and deploying tools using the Model Context Protocol (MCP) and FastMCP framework.
Purpose: To help participants understand, implement, and deploy MCP-compliant tools and servers to integrate with LLMs like Claude or Cursor.
Core Concepts Coverage:
What is MCP and why it matters ("USB-C for AI tools")
Name: Arduino-Powered Digital Distance Scale
Category:
Type:
Summary - oneliner: A hands-on project to build a digital scale that measures distance using an ultrasonic sensor and Arduino.
Purpose: To teach Arduino programming, sensor integration, and basic electronics by creating a practical distance measurement device.
How:
Introduction to the project and basic concepts
Welcome to INSIDE OUT, a space where you don’t solve problems with tools, apps, or technology… but with your mind, your morals, your logic, and the unexpected corners of your own thinking.
This is not a program about right or wrong. It’s not even a program about finding answers.
It’s about discovering how you think.
Every week, you’ll get one scenario. A situation where human instinct, ethics, judgment, and emotion collide. You will sit together — as groups, circles, or pairs — and unpack it
Summary: A thought-provoking ethical decision-making exercise where participants must choose which 6 out of 13 astronauts should survive on the International Space Station after a catastrophic event on Earth.
Purpose: To stimulate critical thinking about ethical dilemmas, decision-making under pressure, and the complex factors involved in ensuring human survival and species continuation.
How: Participants are presented with detailed profiles of 13 individuals on the ISS and must collaboratively decide which 6 should survive based on limited resources. The decision must be made considering the potential for repopulating Earth.
Expected outcome: Enhanced understanding of ethical decision-making, improved group consensus-building skills, and deeper reflection on the values that guide survival choices in extreme situations.
How to measure impact:
Analyze the rationale behind group decisions
Flask API development & MariaDB persistence
Prometheus instrumentation (latency, request count, etc.)
Grafana dashboard creation
Docker Compose deployment of full stack
How:
One-day offline hands-on jam
Build Flask + MariaDB app
Add Prometheus metrics
Visualize metrics in Grafana (15-panel dashboard)
Deploy stack with Docker Compose
Expected Outcome:
Understand the monitoring pipeline
Experience with instrumenting real services
Create practical Grafana dashboards
End-to-end observability setup using Docker
How to Measure Impact:
Dashboard functionality
Metrics instrumentation completeness
Docker Compose deployment success
Learner feedback
Pre-event Checklist:
Share install guides (Docker, VS Code)
Prepare base Flask repo
Share Prometheus basics docs
Create printable Grafana reference cards
Post-event Checklist:
Final dashboard demo
Share repo with completed setup
Collect participant feedback
Share DevOps/monitoring learning paths
Curated by: Anirudth, TOCH
Ideal Audience: Backend, DevOps, and system engineering beginners.
Resource Links:
Number Systems (Binary, Hexadecimal)
Assembly Language Syntax and Semantics
Registers, Memory Access, and Stack Operations
Instruction Set Architecture (ISA)
Arithmetic and Logic Operations
Branching and Control Flow
Writing and Debugging Simple Programs
System Calls and I/O Operations
Connecting Assembly to High-Level Language Concepts
How:
Program Registration via Hub App (minimum 10 students)
Weekly Study Sessions:
Session 1: Concept deep dive (architecture + syntax)
Session 2: Guided coding (NASM/MASM or online simulator)
Session 3: Hands-on project or peer debug session
Use online simulators (e.g., emu8086, PCSPIM, or OnlineGDB Assembly)
Offline meetups to walk through architecture diagrams and code execution
Peer group code review and low-level debugging exercises
Expected outcome:
Understanding of how code interacts with hardware
Practical exposure to Assembly syntax and structure
Foundational systems knowledge for future OS/compilers courses
Enhanced debugging and logical reasoning skills
Peer group support and collaborative problem-solving habits
How to measure impact:
Weekly project/code review sessions
Progress tracking via practice exercises and mini-projects
Participant engagement in discussion and code walkthroughs
Final mini-project demonstrating understanding (e.g., a calculator in assembly)
Self and peer assessments
Pre-event checklist:
Register program on the Hub App
Choose the assembly language variant (e.g., x86 NASM or MIPS)
Prepare starter guides and tool/simulator links
Share a list of required software/simulators
Design a 4–6 week curriculum outline
Onboard group coordinators and mentors
Post-event checklist:
Collect feedback via Hub App or feedback forms
Celebrate and share notable projects/demos
Connect participants with further systems/OS learning tracks
Publish a “Beginner’s Journey to Assembly” guide
Recommend open-source contribution opportunities in low-level systems
Plan continuation into compilers/OS/build-your-own-CPU learning paths
Curated by: Foundation
Ideal audience: Students curious about how computers really work, interested in low-level programming or systems thinking. No prior assembly experience required, but basic programming knowledge is helpful.
Resource Links:
PCSPIM Simulator for MIPS
OnlineGDB Assembly Editor
x86 Assembly Guide - Wikibooks
MIPS Assembly Programming - Carnegie Mellon
FastMCP server and client development
Resource passing and prompt-based tools
Integration with LLM environments like Cursor
Hosting, deployment, and security practices
How:
3-day workshop with lectures and hands-on labs
Build calculator tool with MCP protocol
Add prompts, clients, and secure endpoints
Integrate with Claude Desktop & Cursor
Explore deployment via Modal, ASGI, and OAuth flows
Expected Outcome:
Deep understanding of MCP & FastMCP
Working server & client tools
Experience with deployment & LLM integration
Ability to build streamable, secure AI tools
How to Measure Impact:
Completion of hands-on modules
Successful integration and testing of tools
Participation in Q&A, brainstorming, and final discussion
Documentation of tool and hosting workflow
Pre-event Checklist:
Install Python, uv, FastMCP
Share starter repos and lab instructions
Prepare test endpoints for integration
Provide Claude/Desktop access details
Post-event Checklist:
Document real-world use cases
Share tool gallery built by participants
Publish MCP learning notes and labs
Connect learners to MCP ecosystem and open tool registries
Curated by: Alosh
Ideal Audience: Tool developers, AI infra engineers, curious builders exploring agent-tool ecosystems.
Resource Links:
You will ask: “Why do I feel this way?” “What is influencing my choice?” “What changes if I look from someone else’s eyes?” “Am I reacting, or am I reasoning?”
There is no AI. There is no Googling. There is no correct answer.
There is only conversation, thoughtfulness, and a chance to understand your mind a little deeper.
Get ready. Some scenarios will surprise you. Some will disturb you. Some will make you rethink what you believed was obvious.
Every session ends with a simple question: “Did I come out understanding myself better than when I walked in?”
If yes—you’re doing Inside Out right.
Future participation in tech events on campus
Find out interesting makers from your campus as mentors
Create a Google sheet template to note down the details {link here}
Set up documentation equipment
Brief volunteers on their roles and responsibilities
Get the list of makers registered on your campus, form a WhatsApp group for the event attend follow-up and early engagement activities
Make sure all the makers who are attending the event are checked in through the Hub app
Make sure all the projects are successfully listed in the Hub app
Conduct a debriefing meeting with the organizing team
Follow up with participants from your campus for future engagement opportunities
Share your feedback with the TinkerHub Foundation team
Session 3: Peer programming and doubt clearing
Progress tracking through Khan Academy course completion
Physical meetups for collaborative learning
Group discussions and problem-solving sessions
Development of problem-solving skills
Building connections with like-minded peers
Set up communication channels
Identify group coordinators
Create documentation of the learning journey
Online discussions with video capability
Bi-weekly offline meetups for in-depth discussions
Project work based on weekly topics
Sharing and voting on best projects
Expected outcome:
Increased confidence among women in tech discussions
Enhanced knowledge of various tech topics
Development of presentation and discussion skills
Creation of a supportive community for women in tech
Completion of practical projects related to discussion topics
How to measure impact:
Participation rates in online and offline discussions
Number and quality of projects completed
Feedback from participants on confidence levels and knowledge gained
Increase in women's participation in larger tech events (e.g., Useless Projects, Tink Her Hack)
Long-term tracking of participants' involvement in tech fields
Pre-project checklist:
Set up WIT Leads group and campus WIT WhatsApp groups
Prepare initial set of weekly topics and resources
Arrange online discussion platform
Brief WIT Leads on facilitation techniques
Create project evaluation criteria
Post-project checklist:
Collect and analyze participant feedback
Document best practices for discussions and projects
Showcase top projects from each week
Evaluate the need for adjustments in format or content
Plan for integration of learnings into larger events
Curated by: TinkerHub Foundation
Ideal audience: Women students interested in technology, from beginners to advanced levels, across all 36 campus communities.
Resource Links:
O Penn Mic Edition 3- Generic Topic: Building side hustle while in college(no doc reference, open flow)
Evaluate the quality of ethical arguments presented
Assess changes in participants' perspectives before and after the exercise
Measure the group's ability to reach consensus
Collect feedback on insights gained about decision-making under pressure
Pre-event checklist:
Prepare detailed character profiles for all 13 astronauts
Create decision-making worksheets for individuals and groups
Brief facilitators on ethical considerations and discussion points
Set up a comfortable environment for potentially intense discussions
Prepare prompts for reflection on various ethical dimensions
Post-event checklist:
Facilitate a debrief session on the decision-making process
Discuss the ethical implications of the choices made
Reflect on how personal biases might have influenced decisions
Explore how this exercise relates to real-world ethical dilemmas
Collect participant feedback on the exercise and its impact
Curated by: TinkerHub Foundation
Ideal audience:
Community members
Leadership development programs
Resource Links/Attatchments:
Recent events: Leads Camp
Setup of Arduino IDE and required libraries
"Hello World" Blink project to familiarize with Arduino basics
Understanding Light Dependent Resistors (LDR)
Hardware assembly: connecting LDR module to Arduino
Programming the Arduino to read LDR data and control LED
Testing and calibration of the device
Troubleshooting and refinement
Final demonstration and discussion of potential applications
Expected outcome:
A functioning automatic light system controlled by ambient light levels
Enhanced skills in Arduino programming and electronics
Understanding of LDR principles and LED control
Improved problem-solving and troubleshooting abilities
Knowledge of potential real-world applications for the technology (e.g., streetlights)
How to measure impact:
Successful completion of working projects
Accuracy and consistency of light detection and LED control
Participant feedback on learning and skill improvement
The ability of participants to explain the project's working principles
Creative ideas for expanding or applying the project
Pre-project checklist:
Acquire all necessary hardware components
Install Arduino IDE
Prepare workspaces with the necessary tools
Create and distribute project guides and wiring diagrams
Test all equipment to ensure functionality
Post-project checklist:
Collect and analyze participant feedback
Document common issues and solutions for future reference
Showcase successful projects and creative variations
Discuss potential improvements and advanced features
Provide resources for further learning in Arduino and electronics
Curated by: MakerGram
Ideal audience: Students, hobbyists, and beginners in electronics and programming. A basic understanding of circuits and programming concepts is helpful but not required.
Resource Links
Required Hardware 🛠
Arduino UNO x 1
USB Type-B Cable x 1
Light Dependent Resistors (LDR) Module x 1
Jumper Wires
A Computer
Required Software 🖥️
Arduino IDE
Setup of Arduino IDE and required libraries
Hardware assembly: connecting ultrasonic sensor and LCD to Arduino
Programming the Arduino to read sensor data and display on LCD
Testing and calibration of the device
Troubleshooting and refinement
Final demonstration and discussion of potential applications
Expected outcome:
A functioning digital distance measurement device
Enhanced skills in Arduino programming and electronics
Understanding of ultrasonic sensor principles and LCD interfacing
Improved problem-solving and troubleshooting abilities
How to measure impact:
Successful completion of working projects
Accuracy and consistency of distance measurements
Participant feedback on learning and skill improvement
The ability of participants to explain the project's working principles
Creative ideas for expanding or applying the project
Pre-project checklist:
Acquire all necessary hardware components
Install Arduino IDE and required libraries
Prepare workspaces with the necessary tools
Create and distribute project guides and wiring diagrams
Test all equipment to ensure functionality
Post-project checklist:
Collect and analyze participant feedback
Document common issues and solutions for future reference
Showcase successful projects and creative variations
Discuss potential improvements and advanced features
Provide resources for further learning in Arduino and electronics
Curated by: MakerGram
Ideal audience: Students, hobbyists, and beginners in electronics and programming. A basic understanding of circuits and programming concepts is helpful but not required.
Resource Links:
Required Hardware 🛠
Arduino UNO x 1
USB Type-B Cable x 1
HC04-Ultrasonic sensor x 1
16x2 LCD Module x 1
Jumper Wires
A Computer
Required Software 🖥️
Arduino IDE
Name: Arduino-Powered Seven Segment Display Counter
Category:
Type:
Summary - oneliner: A hands-on project to interface a seven-segment display with Arduino, creating a simple numeric counter.
Purpose: To teach Arduino programming, display interfacing, and basic electronics through the creation of a numeric display system using a seven-segment display.
How:
Introduction to Arduino and seven-segment displays
Setup of Arduino IDE and required libraries (SevSeg)
Understanding types of seven-segment displays (Common Cathode vs Common Anode)
Hardware assembly: connecting seven-segment display to Arduino
Programming the Arduino to control the seven-segment display
Implementing a simple counter (0-9) on the display
Testing and troubleshooting the display
Final demonstration and discussion of potential applications
Expected outcome:
A functioning numeric counter using a seven-segment display
Enhanced skills in Arduino programming and electronics
Understanding of display interfacing principles
Experience with Arduino libraries (SevSeg)
How to measure impact:
Successful completion of working projects
Accuracy and clarity of displayed numbers
Participant feedback on learning and skill improvement
The ability of participants to explain the project's working principles
Pre-project checklist:
Acquire all necessary hardware components
Install Arduino IDE and SevSeg library
Prepare workspaces with necessary tools
Create and distribute project guides and wiring diagrams
Post-project checklist:
Collect and analyze participant feedback
Document common issues and solutions for future reference
Showcase successful projects and creative variations
Discuss potential improvements and advanced features (e.g., multi-digit displays, alphabetic displays)
Curated by: Circuit Digest
Ideal audience: Students, hobbyists, and beginners in electronics and programming. Basic understanding of circuits and programming concepts is helpful but not required.
Resource Links:
Arduino IDE download page:
SevSeg library by Dean Reading:
Required Hardware 🛠
Arduino UNO x 1
USB Type-B Cable x 1
Seven-segment display (Common Cathode or Common Anode) x 1
Current limiting resistors (330 ohm) x 8
Required Software 🖥️
Arduino IDE
SevSeg library
Name: Vibe Coding: Build Smarter, Not Harder
Category: AI-Driven Development, Web Apps, Developer Workflow
Type: Study Jam
Summary - oneliner: A modern coding workshop focused on building production-ready apps using AI-powered workflows and tools like Next.js, Supabase, and Vercel.
Purpose: To teach developers how to build apps faster using AI-first coding workflows, focusing on prompting, rapid prototyping, and deploying with minimal boilerplate.
Core Concepts Coverage:
Prompt-driven development and AI code generation
Web development with Next.js, ShadCN UI, and Tailwind
Real-time features with Zustand/Context API
Debugging and refining AI-generated code
Deployment using Vercel & Supabase
How:
5-day project-based cohort
Daily themed learning + live coding
Build quiz app with real-time features
Prompt-first approach with ChatGPT and dev tools
Expected Outcome:
Mastery of AI-assisted dev practices
A functional, real-time deployed app
Deep understanding of prompts, debugging, and refinement
Familiarity with modern full-stack tools
How to Measure Impact:
App completion and deployment
Prompt quality and iteration practice
Peer feedback and reviews
Debugging and collaboration reflections
Pre-event Checklist:
Install required tools (Node.js, VS Code, Replit, Windsurf, etc.)
Share prompt cheat sheet and ShadCN docs
Prepare kickoff quiz app starter
Post-event Checklist:
Publish participant projects
Share prompt best practices
Recommend follow-up: AI tools, Vibe Dev community
Document learning journey
Curated by: Sunith VS
Ideal Audience: Early-stage developers and curious tinkerers interested in fast-building apps with AI assistance.
Resource Links:
Name: Arduino-Powered Smart Light System
Category:
Type:
Summary - oneliner: A hands-on project to build a smart light system that can be controlled via a smartphone using Arduino and Bluetooth technology.
Purpose: To teach Arduino programming, Bluetooth communication, mobile app integration, and basic electronics by creating a practical smart lighting system.
How:
Introduction to Arduino and its components
Setup of Arduino IDE and required libraries
"Hello World" Blink project to familiarize with Arduino basics
Understanding Bluetooth communication and the HC-05 module
Hardware assembly: connecting HC-05 Bluetooth module and LED to Arduino
Programming the Arduino to receive Bluetooth commands and control LED
Setting up and configuring the "Serial Bluetooth" mobile app
Testing and troubleshooting the Bluetooth communication
Final demonstration and discussion of potential applications
Expected outcome:
A functioning smart light system controlled by a smartphone
Enhanced skills in Arduino programming and electronics
Understanding of Bluetooth communication principles
Experience with mobile app integration for IoT projects
How to measure impact:
Successful completion of working projects
Reliability of Bluetooth control and LED response
Participant feedback on learning and skill improvement
The ability of participants to explain the project's working principles
Pre-project checklist:
Acquire all necessary hardware components
Install Arduino IDE
Download "Serial Bluetooth" app on participants' smartphones
Prepare workspaces with the necessary tools
Post-project checklist:
Collect and analyze participant feedback
Document common issues and solutions for future reference
Showcase successful projects and creative variations
Discuss potential improvements and advanced features (e.g., multiple light control, scheduling)
Curated by: MakerGram
Ideal audience: Students, hobbyists, and beginners in electronics and programming interested in IoT. Basic understanding of circuits and programming concepts is helpful but not required.
Resource Links:
Required Hardware 🛠
Arduino UNO x 1
USB Type-B Cable x 1
LED x 1
HC-05 Bluetooth module x 1
Required Software 🖥️
Arduino IDE
"Serial Bluetooth" mobile app
Summary: The Work Values Inventory is a self-assessment tool designed to help individuals identify and prioritize their work-related values.
Purpose: To assist individuals in understanding what they consider most important in their work environment and career choices.
How: Participants rate 45 work-related statements on a scale of 1 (Unimportant) to 5 (Very Important). These statements are grouped into 15 work value dimensions.
Expected outcome: Individuals gain insight into their top work values, which can guide career decisions, job searches, and discussions with employers or career counselors.
How to measure impact:
Compare top and bottom work values to current job satisfaction
Track changes in work values over time
Assess alignment between personal values and organizational culture
Pre-event checklist:
Prepare Work Values Inventory questionnaire
Ensure quiet, comfortable environment for completion
Provide clear instructions on rating scale
Have self-scoring sheets ready
Post-event checklist:
Guide participants through self-scoring process
Discuss meaning of different work value dimensions
Encourage reflection on top and bottom values
Provide resources for further career exploration
Curated by:
Foundation
Ideal audience:
Community members
Resource Links/Attachments:
Recent events: Leads Camp
(Impossible? Not around here, partner!)
Hey explorers,
Do you enjoy movies where there is a problem, and the heroes work together to solve it and save the world and yada yada…???
Well, Mission Impossible is all about problem solving.
Every Friday, you will have a problem to solve. Use an entire week to spice up a solution. And yes, working in teams works best out here.
What kind of problems? Am I gonna get in trouble?
Nope! These problem statements would either be something you face on a daily basis or something you see around often but ignored thinking, ”not my circus, not my monkey”.
Or, it could be something that's completely out of your focus. A problem from an area or domain you never really cared about…until now.
Hmm…What’s so big about solving it?
Well, here is the key. We don't want you to ask the question to gemini or gpt and generate a solution. Nah. We are not going to give you problem statements per se either. In fact, these won’t be statements at all.
Summary: Team-based decision game with points awarded based on color choices
Purpose: To simulate strategic decision-making in a team environment
How: Teams choose between black and white options for 12 rounds, with points awarded based on combinations
Expected outcome: Teams will develop strategies to maximize points while considering other teams' potential choices
How to measure impact: Track point totals after each round and note changes in team strategies
Pre-event checklist:
Select team captains
Instead, you are going to read case studies. Things that actually happen. Emotions people go through. Consequences and more.
Tech is a tool to solve a problem.
How to solve it should have more nuances. A lot of what-ifs and but-ifs should ideally come from humans. That is when you completely and deeply solve a problem.
Okay…so what is the actual process? How should we solve a problem???
1. Sit in groups. Groups of 3-5 works best.
2. Go through the case study completely.
3. Identify the problem at core.
4. Extract solutions from each member of the group independently- without the use of AI. This step need not necessarily involve technology. Tech solutioning can come at the end.
5. Ask questions. Ask ‘but what if..’, as much as possible to understand the nuances.
6. Identify how a tech tool or technology can be used anywhere if required to solve the problem.
7. Make a pipeline of your solution, and how it can help.
8. If you can build the solution you came up with…you have made the IMPOSSIBLE - POSSIBLE!.
I would also suggest you to try finding out experts from the area and having an online or offline discussion with them on whether your solution actually works. You will get a deeper understanding of their pain points too.
Or who knows…maybe you would have solved something they have been working on for years!.
So yes. Every Friday, keep a close eye on your inbox. Get the story, know the plot, find your Watson, identify your clues, and SOLVE IT!.
Rajendran had been farming paddy for nearly thirty-two years. People in his village often joked that he knew the soil better than he knew people. His fields lay about a kilometre away from his house in Palakkad, a stretch he had walked thousands of times across seasons—blazing summers, heavy monsoons, and everything in between.
But the last few years had begun to trouble him in ways he hadn’t expected. Four consecutive harvests had brought losses, not profits. Not massive losses, but the slow, painful kind that ate away at savings and confidence. Once or twice, he dismissed it as “climate change,” something he’d heard on television. But the pattern kept repeating.
This year, the trouble began early. One morning, Rajendran walked to the field and found the water level unexpectedly low. He was puzzled—it had rained the previous night. The soil felt dry in patches, almost cracked. He looked around to see if the canal had clogged again, but everything looked normal. He shrugged it off and flooded the field manually. That evening, his ankle began to hurt again, a sharp reminder that the walk to the fields was getting harder.
A week later, he noticed pale yellow spots on the tender leaves. A pest, perhaps. But he wasn’t sure which one. By the time he showed the leaves to the agriculture officer during his next visit, the officer said the infection had already spread. “You should have informed me earlier, Rajendran,” he said kindly. “How, sir? You only come once in two weeks,” Rajendran replied, embarrassed.
The officer scribbled notes in his register, promised to send someone from the Krishi Bhavan, and left. No one came.
Then came the weather problem. Unexpected heat waves, sudden rain, long dry spells—none of the patterns Rajendran had known his whole life seemed reliable anymore. The weather forecast on television hardly matched what happened in his small village. The nearby stations recorded humidity and rainfall, but his fields existed in their own microclimate, unpredictable and unforgiving.
His wife noticed the change in him. He had become quieter, more withdrawn. He ate less and spent more time staring at the field map he had drawn by hand, as if he was trying to find answers in the creases of the paper. “What is worrying you so much?” she asked one evening. He simply replied, “I don’t understand my own land anymore.”
One night, his son, a commerce graduate working in a small firm in Coimbatore, said casually, “Appa, we should stop this. Farming is not worth the stress. Why don’t we give the land on lease?” The words hit him harder than the losses. He had always hoped his son wouldn’t leave farming behind completely, but he didn’t blame him—the boy had only seen farming as struggle, not pride.
The turning point came when the local cooperative society called him to discuss loan settlements. “Rajetta, don’t take this personally,” the officer said, “but many farmers like you are struggling. We’re trying to understand what’s happening.”
For the first time, it dawned on Rajendran that he wasn’t alone. Several others around him were facing similar issues—unpredictable moisture levels, delayed pest detection, lack of timely information, inability to be physically present at the fields daily, and no system to alert them before something went wrong.
Everyone was fighting their battles separately, with no shared data, no collective monitoring, no alerts, and no structured support system. The agriculture officers were stretched thin, visiting twenty or more farms in a single week. Farmers relied on instinct, luck, and outdated schedules. Nothing connected them, and so everything kept slipping through their fingers.
One evening, as he sat looking at his field—still beautiful, still full of potential—Rajendran whispered to himself, “How do I take care of something I cannot see every day? How do I know before the damage happens, not after?”
He was not asking for miracles. He was asking for information—timely, accurate, simple information that could help him act at the right time.
And somewhere, hidden under the weight of his worries, lay a much bigger question: “Is there a way for someone like me to farm smarter, even if I cannot be at the field every day? Is there a way to stop money from slipping away before I can save it?”
That is the mystery waiting to be solved.
Summary: A reflective workshop designed to help participants identify and understand their personal values, both from their own perspective and others'.
Purpose: To encourage self-reflection, enhance self-awareness, and promote understanding of how personal values shape behavior and relationships.
How: Participants engage in a four-page writing exercise, followed by group discussion and collective reflection.
Expected outcome: Increased self-awareness, better understanding of personal values, improved ability to articulate these values, and insights into how values impact relationships and community building.
How to measure impact:
Collect qualitative feedback on insights gained
Follow-up surveys on how the workshop has influenced participants' decision-making or relationships
Track changes in participants' ability to articulate their values over time
Pre-event checklist:
Prepare writing materials (4 pages per participant)
Create a comfortable, quiet environment
Brief facilitators on context-setting and closing discussion points
Prepare examples to help participants understand the exercise
Post-event checklist:
Collect anonymous feedback on the workshop
Summarize key insights from group discussions
Provide resources for further value exploration
Schedule follow-up sessions if needed
Curated by:
Foundation
Ideal audience:
Community Members
Resources /Attatchments:
Following questions can be used by the moderator for context setting Page 1: What do YOU find most valuable about yourself? Page 2: WHY do you think you are like that. e.x if you have mentioned disciplined - why are you like that. think and write it down. for yourself. Page 3: What do your friends, family, colleagues find most valuable about you? They can call them and ask. best wat for them would be to tell this friend what they find valuable in that friend and then ask the same in return.. they can say - of i was thinking about you and how i find this so valuable about you. and was wondering what you found valuable in me. Page 4: WHY do you think you are like that. e.x if you your friend mentioned reliable - why are you like that. think and write it down. for yourself.
Recent events:
Leads Camp
Create catchy team names
Explain rules to all participants
Ensure scoring system is clear
Post-event checklist:
Tally final scores
Discuss strategies used by teams
Reflect on decision-making processes
Award winning team
Curated by:
Foundation
Ideal audience: Community members
Resource Links/Attachments:
Recent events: Leads Camp
Improved problem-solving and troubleshooting abilities
Knowledge of potential real-world applications for numeric displays
Creative ideas for expanding or applying the project to other display scenarios
Test all equipment to ensure functionality
Provide resources for further learning in Arduino, display technologies, and embedded systems
Breadboard x 1
A Computer
Improved problem-solving and troubleshooting abilities
Knowledge of potential real-world applications for smart lighting technology
Creative ideas for expanding or applying the project to other IoT scenarios
Create and distribute project guides and wiring diagrams
Test all equipment to ensure functionality
Provide resources for further learning in Arduino, Bluetooth technology, and IoT
A Computer
A Smartphone (for controlling the light)
Name: Version Control & GitHub Essentials
Category: Education, Technology, Community Learning
Type: Study Jam
Summary - oneliner: A beginner-friendly, hands-on program to learn Git and GitHub for version control, collaboration, and open-source contribution.
Purpose: To help students and early developers build confidence in using Git and GitHub effectively for version control, collaboration, and contributing to real-world projects—all in a peer-learning environment.
What is Version Control? Why Git?
Installing Git and Setting Up GitHub
Basic Git Commands (init, add, commit, status, log)
GitHub Repositories and Remote Setup
Program Registration via Hub App (minimum 10 learners)
Weekly Hands-On Sessions:
Session 1: Git Basics (local workflow)
Session 2: GitHub & collaboration
Comfort using Git for local and remote version control
Understanding of real-world workflows (pull request, branches, etc.)
Ability to collaborate on GitHub-based projects
Confidence to contribute to open-source repositories
Completion of individual Git practice exercises
Team submission of a collaborative mini-project
GitHub contribution graphs (commits, pull requests)
Peer feedback on contributions and reviews
Register program on Hub App
Ensure participants install Git CLI
Help create GitHub accounts
Prepare tutorial materials/slides
Collect feedback via Hub App
Feature participant contributions
Share follow-up learning paths (GitHub Actions, Git Internals)
Encourage contributions to TinkerHub repos or open-source
TinkerHub Foundation
First-year students, coding beginners, and anyone new to version control. No prior experience required.
You are the controller of a railway junction. A high-speed train is rushing down the track, and the brakes have failed. You have only one control in front of you — a lever that decides which track the train will go down.
On Track A, there is an elderly man walking alone. He is slow. He will not be able to move in time.
On Track B, there are three men. They are tied up — unable to escape. Later, you learn they are convicted criminals on work duty.
The train is seconds away. You must choose one track.
You cannot stop the train. You cannot warn anyone. You cannot save everyone.
You must simply choose.
Which track do you switch the train to? Why? What values guide your decision? Does the identity of the people change your choice? Should "number of lives" matter more? Should "innocence" matter more?
There is no correct answer. There is only the inside of your thinking — and the outside you reveal when you speak about it.
Pull Requests and Code Reviews
Cloning and Forking Repos
Resolving Merge Conflicts
Collaboration Workflow (git pull / push / fetch)
Contributing to Open Source
Using .gitignore, LICENSE, and README
Session 3: Real-world project simulation
Git Practice via CLI and GitHub Web Interface
Collaborative exercises and pair programming
Mini-project: Create and contribute to a shared repo
Clear documentation and repo hygiene skills
Confidence check-ins via reflection forms
Create a contribution guideline template
Publish “Git Learner Showcase” with best projects
At the edge of a small town on the outskirts of Kochi, behind the vegetable market and the bus stand, stood a shining example of “India’s green future”: a community biogas plant designed using CSIR’s model.
The plant had become a matter of local pride. School children came on field visits. Panchayat members loved to show it off to visiting delegations. It took in vegetable waste from the market, food scraps from a nearby hostel, and dairy waste from a small cluster of farms. In return, it produced clean cooking gas for the community kitchen and slurry for the farmers’ fields.
On paper, it was perfect.
On the ground, it was a bit more complicated.
Every morning at 6 a.m., before the sun fully rose, Anil would unlock the gate to the plant. He was the “plant operator,” though his actual job description varied depending on who you asked: caretaker, mechanic, waste collector, cleaner, record-keeper, sometimes tour guide.
He walked past the intake pit, checking if last night’s waste had settled properly. The dome of the digester sat squat and silent, full of invisible promise. Nearby, a compact gas meter box was fixed to the side of the plant, connected to the pipeline. It displayed crucial numbers: gas production, pressure, cumulative usage.
Anil pulled out a small notebook and a pen. He pressed a button on the meter, waited for the digital display to change, and copied down the reading.
“Today… 13.2 cubic meters,” he muttered to himself, scribbling the numbers into the notebook along with the date and time.
He did this every morning and every evening. If he missed a reading because he was sick or busy, there was simply no data for that period. When it rained, he balanced an umbrella in one hand and the notebook in the other, trying not to smudge the ink.
The meter worked. The plant worked. In fact, they both worked very well.
The problem was that the information on that little meter stayed exactly where it was: on the wall of the biogas plant.
Once a month, Meera from the local NGO came to collect data. Her organization had helped the panchayat set up the plant using the CSIR design, and they were now trying to prove that such plants could be both sustainable and economically viable at scale.
She would sit at a plastic table in the community hall with Anil’s notebooks spread out in front of her.
“Okay, so from June to August, gas production has increased. That’s good,” she said, drawing lines on an Excel sheet on her laptop.
“But ma’am,” Anil replied, “these numbers are sometimes guesswork. If the meter display was foggy or I had to rush, I just noted roughly. And sometimes the zero resets… Then I’m not sure what to write.”
Meera knew he was doing his best. The plant’s internal technology was solid, based on years of CSIR research. But the interface between the plant and the humans using it was fragile. Data lived in notebooks, on loose sheets, in photos of the meter display sent over WhatsApp.
When potential funders or government officials called her and asked, “Can you show us the trend of gas production over the last year? Can you prove reliability? Can you estimate payback period accurately?”, she would sigh and open several disjointed spreadsheets.
The plant was “highly functional” in the engineering sense. It produced clean fuel reliably. It handled waste sustainably. It had real market potential.
What it did not have was what everyone else now took for granted, even with the cheapest devices in their homes: a way to see what was going on from their phone.
At the same time, on the other side of town, a women’s hostel depended on the same biogas line for most of its morning cooking. The warden, Latha, had a very simple requirement: she needed to know whether there would be enough gas for breakfast, or whether she should switch to LPG backup.
She didn’t want to know about cubic meters or pressure coefficients. She just wanted a clear answer:
“Do I have enough gas for tomorrow morning or not?”
Most days, she would simply call Anil in the evening.
“Chetta, tomorrow gas undavumallo?” “It should be there, chechi, today we got good waste. Meter shows enough.”
“Should?” she would repeat, stretching the word.
If there was less gas than expected the next morning, the hostel kitchen scrambled. LPG cylinders had to be moved in, extra money spent, timelines thrown off. Students complained when breakfast was late. Nobody blamed the biogas plant directly, but a quiet sense of “this is unreliable” began to form in their minds.
All the while, the meter continued to show exactly how much gas was being produced.
Only the person standing in front of it could see that.
When a CSIR team visited one weekend for a review, they were impressed by how well the plant performed.
“Digestion levels are good,” said one of the engineers, checking pH and temperature logs. “Gas production is stable. This is a solid demonstration site. You could replicate this in a hundred markets easily.”
“But can we prove that to a bank?” Meera asked, half joking, half serious. “They want graphs, dashboards, projections. They want to see real-time performance, seasonal trends. Right now, that lives in Anil’s head and these notebooks.”
The CSIR team lead, Dr. Rao, frowned thoughtfully.
“The design we developed focused on mechanical reliability and efficiency,” he admitted. “We always assumed local operators would just read the meter. We didn’t think about… apps.”
“For urban investors and government dashboards, an app is not a luxury,” Meera replied. “It’s the minimum entry ticket.”
Anil, listening from a distance, added in his quiet way, “If I could just take a photo of the meter and send it, or if it showed on my phone automatically, I wouldn’t worry so much about writing it correctly every time.”
Dr. Rao looked at the meter fixed to the plant wall — precise, robust, yet strangely disconnected from the people who most needed its information.
“We solved the digestion problem,” he said softly. “Maybe we forgot the human interface.”
A few weeks later, a startup founder named Arjun visited the plant. He was exploring “climate tech opportunities” and was excited by the idea of decentralized biogas at scale.
“This model is gold,” he told Meera. “Waste to energy, local jobs, circular economy, low carbon, all in one. But if I go to an impact investor and they ask me, ‘How do you monitor your assets across 50 locations?’ I can’t say ‘We have one meter fixed on each plant, and a guy writes it in a notebook.’ They expect at least a basic digital monitoring layer.”
He walked around the plant, staring at the pipes, valves, and the meter.
“You know,” he mused, “if I can order a ₹200 pizza and track it live on my phone, but I can’t see how much gas a ₹20 lakh biogas asset is producing without physically visiting it… something is wrong with the picture.”
Everyone laughed, but they knew he was right.
The biogas plant was technically sound, environmentally friendly, economically promising – and yet, from a user experience perspective, still stuck in an earlier decade.
Operators had no simple, in-hand way to enter or view data.
Hostel wardens and canteen managers had no clear visibility into future gas availability.
NGOs and entrepreneurs had no real-time dashboards or historical graphs to convince partners.
CSIR had no easy way to compare multiple pilot plants across regions.
All the intelligence sat in one place: a single meter, physically attached to each plant.
The panchayat president, who had been supportive of the project from day one, summed it up during a meeting.
“This plant is good,” she said. “People are proud of it. But if we want ten more like this in our block, we need confidence. We need to show performance. We need to know, without going there personally, whether the plant is healthy.”
She looked at the small cluster of young engineers, designers and students who had been invited to brainstorm next steps.
“You are all the ‘next generation problem solvers’, no?” she teased. “We have the plant. We have the meter. We have the waste. We even have the gas. What we don’t have is a way to carry this plant in our pockets.”
She held up her phone and waved it slightly.
“If you can help us do that,” she said, “maybe this really can become a model for the whole state. Maybe one day, for the whole country.”
Your Mission:
You are part of the team invited to work with CSIR, the NGO, the panchayat and the startup to figure out how these highly functional biogas plants can become truly user-friendly, trackable and scalable. Using everything you’ve just read – the fixed meter, the notebooks, the operator’s reality, the hostel’s dependence, the investor’s expectations – you must uncover the core problem and imagine a technology-enabled way to bring these plants “into people’s hands” without breaking what already works.
Meetup
An interactive forum for campus communities to collaborate, share ideas, and shape a vibrant tech ecosystem in your campus.
To foster collaboration among different campus communities, explore collective strategies for learning on your campus, introduce the new TinkerHub campus leadership team, and provide clarity on upcoming initiatives.
Ice breaker activity
A brief introduction to the activity purpose
Round table discussion: "Maker culture in our campus"
How can communities work together for better outcomes?
Identifying shared challenges and collaborative solutions
Brainstorming joint initiatives and events
Presentation of upcoming TinkerHub activities and how they align with collective goals
New campus leadership team introduction
Q&A and networking session
Enhanced sense of shared purpose within the broader tech ecosystem
Stronger bonds formed between different campus communities
Increased awareness of leadership team across communities and potential points of contact
Concrete ideas for inter-community collaboration and campus improvement
A clear understanding of how TinkerHub's activities support collaborative efforts
Post-event survey report
Casual conversations with attendees to gather qualitative feedback
Monitor community interaction levels after the event (e.g., increased communication in community channels, collaborative initiatives)
Track attendance and engagement in subsequent events or activities
TinkerHub Core Team
Potential community partners, Existing community makers, Academic Representative
Tinkerhub Orientation Deck
Ideal audience: The target group that would benefit most from this activity. Include any prerequisites if applicable.
Resource Links: Useful references, tools, or materials related to the activity. Include both preparation and follow-up resources.
Category: Tech, Community Building, Open Hardware
This event is inspired by the Repair Café movement (), but with a different focus. Here, we are not guaranteeing that your device will be repaired. Instead, we aim to revive curiosity—the same curiosity that leads many makers to open up their first RC car, radio, or broken gadget just to see what’s inside.
Over time, many of us lose that curiosity to explore and experiment. This event is about reigniting that mindset by creating a space where people feel comfortable opening up their devices, understanding their components, and learning how they work.The goal is to create a space where people feel comfortable opening up their devices, exploring their components, and understanding how they work. Even if the gadget isn’t fixed, participants will walk away with a better understanding of electronics, repairability, and open hardware. It’s about learning, experimenting, and thinking about how things can be improved.
This event is open to two types of participants:
People who bring gadgets to explore or repair: Those who have broken or old gadgets they want to open up and understand.
People interested in hardware and making: Those who may not have a gadget to fix but are curious about hardware, electronics, and repair culture.
Both groups can learn from each other, share tools, and collaborate.
Introduction to the mindset of repair—why it’s important to explore and understand how things work
Discussion on how many makers start by opening up machines out of curiosity
Participants introduce their gadgets and what they hope to explore
Participants open up their gadgets to see what’s inside
Guidance from knowledgeable attendees on basic troubleshooting and repair techniques
Conversations on why products fail, how they can be improved, and how repairable they are
Collaboration with others to exchange ideas and tools
Short Talks (15-20 minutes each):
Why Repairing Matters: Right to Repair and Sustainability
How Curiosity Leads to Innovation: The Maker Journey
Open Hardware: How Open-Source Electronics and DIY Communities Are Changing Tech
Reflection on what participants learned and what surprised them
Exchange of contacts for future collaboration
Discussion on how to continue learning and applying repair skills
A shift in mindset—seeing technology as something that can be opened, explored, and modified
A better understanding of how electronics work
Hands-on experience with tools and basic troubleshooting
Awareness of open hardware and how communities around the world are working towards repair-friendly tech
Number of participants who actively opened their devices
Number of people who attended for the first time
Number of participants who expressed interest in future repair or maker events
Feedback from participants on what they learned
Stories of discoveries—what participants found inside their gadgets
Observations of collaboration and problem-solving moments
Interest in open hardware and repair culture after the event
Secure a venue with tables, chairs, and power outlets
Promote the event and manage registrations (maximum 50 participants, invite-only)
Set up a community tool station (screwdrivers, pliers, soldering kits, etc.)
Arrange short talks or invite speakers
Collect participant feedback
Share photos, key takeaways, and participant experiences with the community
Create a simple repair guide or key learnings document for attendees
Plan future meetups or an online space for discussions
People who enjoy tinkering with hardware and electronics
Students, hobbyists, and anyone curious about how gadgets work
Those interested in sustainability, repair culture, and open hardware
Anyone with a broken device and a willingness to explore
No prior experience needed—just bring a device and an open mind.
Curated by: Kurian Jacob
Repair Café Movement:
Right to Repair Movement:
Basic Fixing Guide:
Community Repair Initiatives:
This event is about reviving the natural curiosity that leads to making, repairing, and innovating. Whether participants successfully fix their device or not, they will leave with a deeper understanding of technology, repair culture, and open hardware.
Basic Fixing Skills: Soldering, Circuit Checking, Component Replacement
Show & Tell: Participants share what they discovered, whether or not their device was fixed
Connections with fellow tinkerers who share a curiosity for exploring and improving devices
Inspiration to continue learning and experimenting with hardware, even if their device wasn’t fully repaired
Organize refreshments for attendees
Open Hardware Community: https://openhardware.space/community/
Open Source Hardware Association: https://www.oshwa.org/
Open Hardware Projects & Designs: https://www.openhardware.io/
It was 9:15 a.m. on a busy Tuesday at Sree Lakshmi Medical College, a mid-sized teaching hospital in South India. The second case on the list was a 62-year-old man, Mr. Raghavan, coming in for a major abdominal surgery to remove a tumor.
Inside OR 3, the team moved with the familiar mix of routine and pressure. Dr. Anil, the surgeon, stood scrubbed and focused. Dr. Meera, the anesthesiologist, watched the monitors with her usual quiet intensity. Two junior nurses, Deepa and Arun, managed sponges, instruments, irrigation, suction and the constant stream of “Sister, gauze… suction… more saline.”
From the outside, it looked smooth.
From the inside, the numbers were already starting to blur.
As the surgery progressed, the field became increasingly bloody. Deepa opened new packs of gauze, passing them as fast as the scrub nurse asked. Used, blood-soaked sponges piled into a kick bucket. The suction canister slowly filled with a dark red fluid — a mix of blood and the clear irrigation saline used to keep the field visible.
“Can you tell me the blood loss roughly?” Dr. Meera asked over the drapes, eyes still on the patient’s blood pressure and heart rate.
Deepa glanced at the suction canister. “About eight hundred, ma’am?” she said, uncertainty in her voice. “Plus the sponges… I’ll calculate.”
There was no automated system. The “calculation” was a mix of habit, mental math and guesswork.
The rough method in this OR was the same as in many: look at the volume in the suction canister, subtract what you think was irrigation fluid, then add an estimate of how much blood must be on the sponges.
But no one knew exactly how much irrigation had gone in. It was written on a whiteboard, updated when someone remembered. The sponges, all different sizes and degrees of saturation, were waiting to be weighed at the end — if there was time. And everyone knew that by then, decisions about fluids and transfusions would already have been made.
Mr. Raghavan’s blood pressure dipped slightly. “Let’s start a bolus,” said Dr. Meera. “And cross-check blood loss again in ten minutes.”
Two hours later, the operation was still underway. The first unit of blood had been transfused. The suction canister had been changed once, the new one already half full. Irrigation bottles came and went — one litre, another half litre, another litre — scribbled in rushed handwriting on the side of the whiteboard.
At one point, when things became more difficult surgically, everyone’s attention shifted fully to the field.
“More suction… more saline… hold that retractor… give me another pack of gauze.”
Nobody updated the board for twenty minutes.
“Meera, how much are we at now?” Dr. Anil’s voice broke through.
She exhaled slowly. “By my count, maybe fifteen hundred? But I need the exact totals.”
Deepa quickly tried to reconstruct the numbers. “How many litres of saline have we used?” Meera asked.
There was a pause. “Four? Or maybe five, ma’am… One bottle we didn’t write down, I think. I’ll check,” Arun replied, looking worried.
Meera knew this was not their fault. This was simply how things were done everywhere she had ever worked: visual estimation, mental subtraction, retroactive guessing. In textbooks and conferences, everyone agreed this was inaccurate. In real life, this was still the norm.
The surgery finally ended. Mr. Raghavan was shifted to recovery, still intubated but stable enough to move. The team prepared to hand over to the post-op nurses.
“How much blood loss?” the recovery nurse asked, pen hovering over the sheet.
There was a silence that lasted a bit too long.
Deepa opened her notebook. “From the suction: two canisters, around sixteen hundred total. Irrigation… probably about nine hundred ml. For sponges, we’ve written seven hundred based on weight.”
“So what do we write?” the nurse asked again.
“Net blood loss… about fourteen hundred,” Meera answered, doing the math in her head, then immediately doubting it. “Write fourteen hundred.”
Later, while documenting, Meera realized that if she added the numbers another way, she could get a completely different total, still “reasonable,” still technically defensible, and still wrong in ways nobody could precisely prove.
That night, in the ICU, Raghavan’s blood pressure dipped again. The intensivist on duty looked at his file.
“How much did he lose in OT?” he asked.
“Fourteen hundred ml,” the nurse replied, pointing at the sheet.
He frowned slightly. “He looks a bit more dry than that,” he muttered, ordering another fluid bolus and an additional blood test.
By morning, Raghavan was stable, but the team knew it had been close. When the department sat down for a routine morbidity and mortality meeting later that week, his case came up.
“We managed,” the head of surgery said, “but our transfusion and fluid decisions were still built on estimates. If that number was off by even five hundred ml either way, our decisions could have been too aggressive or too conservative.”
Meera added quietly, “If you had asked each of us in the OR what the blood loss was at different times, you would have gotten different answers. Our methods are manual, fragmented and subjective. We track blood on gauze one way, suction fluid another way, urine output somewhere else, irrigation in someone’s head or on a smudged whiteboard. All of that, in real time, in a high-pressure environment.”
The quality officer, who was also in the meeting, listened carefully.
“So you’re saying,” she asked, “that in a modern OR with monitors, ventilators, infusion pumps and electronic records… we still don’t have a reliable, automated way to know how much fluid the patient is actually losing during surgery?”
Meera nodded. “Exactly. We are making high-stakes decisions on top of guesswork. Some companies have apps that estimate blood loss from images of sponges. Some devices measure blood content in fluid lines. Some systems track urine output. But they’re all separate. Nothing gives us one integrated, real-time ‘fluid loss picture’ we can trust.”
There was a long pause.
The hospital’s biomedical engineer, who had recently started a small innovation cell with the residents, broke the silence.
“What if we tried to build something?” he asked slowly. “Even a prototype. Something that could bring all this together — blood on gauze, blood in suction, urine output, irrigation in and out — into one live dashboard for the anesthesiologist?”
Meera looked at him with a mixture of hope and skepticism.
“If you could give me a simple, reliable number,” she said, “even simulated at first… That could change how I manage fluids. It could mean safer surgeries. Fewer close calls like this.”
The room went quiet again, but this time the silence felt different. Less like helplessness, more like possibility.
You are part of the small innovation team invited by this hospital to study what happened in OR 3 and propose a tech-enabled solution. You have access to everything you just read: the messy reality of gauze, suction, urine, irrigation, manual notes, human error, time pressure and patient risk.
Your task is to understand the real, underlying problem in this story, map the points where information is lost or distorted, and design a technology-backed approach that could give clinicians a more accurate, real-time view of fluid loss during surgery — starting with a proof-of-concept that a hackathon team like yours could realistically build.