Login

u/Junior_Bake5120

Looking for 2 teammates! Odoo Hackathon 2026 (₹5L prize pool) + FAR AWAY 2026 (Top 5 fly to Japan, fully sponsored)
▲ 8 r/hackathon

Looking for 2 teammates! Odoo Hackathon 2026 (₹5L prize pool) + FAR AWAY 2026 (Top 5 fly to Japan, fully sponsored)

Hey everyone,
Looking for 2 people to join our team for two hackathons this summer.

The hackathons:

Odoo Hackathon 2026 : 24-hour coding marathon, Rs. 5 Lakh+ prize pool, hiring offers up to 8 LPA on the table for strong performers. Problem statements are revealed at the start and judging is heavy on UI quality, real-time data, and clean execution.

https://hackathon.odoo.com/hackathon/event/odoo-hackathon-2026-33

FAR AWAY 2026 by Zuup : India's biggest international youth hackathon (ages 15–25). Three rounds: online, in-person in Delhi, then a fully sponsored grand finale in Tokyo (flights, hotel, meals covered) for the top 5 teams. Open innovation theme.

https://unstop.com/hackathons/far-away-zuup-1677472

Who we are:

Currently two of us me and a PM.

Me! final year student at a T1 uni, working as an AI engineer. Been doing remote internships for about 2 years, about 1 year into proper AI engineering work — agents, production ML systems, high-velocity projects. GSoC contributor '25 and mentor '26. Won Smart India Hackathon. Attended YC Startup School and placed 4th at the first-ever YC Hackathon out of 2,500+ applicants as a college student, losing only to people 3 teams 2 of them had dev with 3–7 years of experience.

Portfolio: https://chiruu12.github.io

Our PM 1 YOE, currently working remotely at a US-based startup. She handles product-market fit, decks, and pitching. Judges notice when a team can actually present.

Who we're looking for:

A strong frontend dev with a good eye for UI/UX. Odoo judges on this specifically — layout, responsiveness, color consistency. If you can ship something that looks and feels polished under time pressure, that's the role.

A generalist full-stack dev who knows how to deliver. Someone who's been in crunch situations before and figured it out.

If you're interested, drop a comment or DM with something you've built. Both hackathons require being in India and under 25 for FAR AWAY eligibility.

Let's actually compete to place.

u/Junior_Bake5120 — 1 day ago
▲ 88 r/gsoc_2027+1 crossposts

If you’re starting with open source, read the CI config before you trust the README

I mentor for Jenkins under GSoC. Every cycle I watch contributors go through the same sequence: find an issue, fork the repo, spend 3 hours trying to build it locally, give up.

The README says “run npm install.” Actual build needs three system deps nobody documented. Or the project switched from yarn to pnpm six months ago and the docs never caught up.

One thing that saves a lot of time: read the CI config first. Look at the GitHub Actions workflow or the Jenkinsfile. CI has to work (nothing merges otherwise), so it’s the real source of truth. You’ll find the right Node version, the system packages, the env vars, everything.

A few other things I wish contributors knew before their first PR:

  • Pick issues filed by maintainers or org members, not random users. Issues from outside users often get closed without review.
  • Read CONTRIBUTING.md before writing a single line of code. Half of rejected PRs fail on process (wrong branch, missing sign-off), not code quality.
  • Writing tests is a great first contribution. Lower risk than a bug fix, teaches you the codebase, and maintainers appreciate it.
  • After your PR merges, don’t disappear. Your second contribution is what turns you from “random contributor” into someone maintainers recognize.

I also built a set of open source tools that automate the research side of this (reading docs, tracing code, checking repo eligibility). Free, works with most AI coding tools: https://github.com/chiruu12/OSS-Skills?ref=devindia

But even without any tools, the CI config trick alone will save you hours.

u/Junior_Bake5120 — 6 days ago
▲ 24 r/SideProject

I built a proof of concept for something I think is inevitable: machine-readable developer identity.

The thesis is simple. We built robots.txt for crawlers, schema.org for search engines, llms.txt for AI docs. Every time machines needed to consume human content, a structured standard emerged.

Developer profiles are next. AI agents are getting good enough to screen GitHub profiles for hiring, contributor matching, code review assignment. But GitHub profiles were designed for human eyes. Pinned repos, green graphs, polished bios. None of that is structured data.

I spent a couple days building a proof of concept to explore what a structured developer identity could look like.

What it does:

  • Takes any GitHub username, extracts 14 signals from public data
  • Generates a structured JSON schema (devcard.json)
  • Scores profiles on two axes: Human Visibility (recruiters) and Agent Readiness (AI tools)
  • 5 SVG themes you can embed in your README
  • Profile advisor with actionable critiques
  • Compare two developers side-by-side

Not saying this is the final answer, but I believe this layer of the developer ecosystem is going to exist eventually. Someone is going to build the schema.org for developer profiles.

What do you think? Is this inevitable, or am I overthinking it?

GitHub: https://github.com/chiruu12/devcard

reddit.com
u/Junior_Bake5120 — 11 days ago
▲ 1 r/indianstartups

Should developer profiles have a machine-readable standard? Like robots.txt but for devs.

We have robots.txt for crawlers schema. org for search engines. llms.txt for AI documentation. But there’s nothing equivalent for developer identity.

Right now, AI agents are getting good enough to evaluate developers. Devin ships code. Claude reasons through codebases. It’s not hard to imagine agents screening GitHub profiles, checking commit quality, stack depth, collaboration patterns, and surfacing candidates before a recruiter opens a tab.

When that happens, GitHub profiles have a problem. Pinned repos, green graphs, polished bios. All designed for human eyes. An agent sees unstructured HTML, inconsistent READMEs, and zero standardized signals about what someone actually builds or how they work.

I’ve been thinking about what a structured developer identity format could look like. Built a proof of concept in Python to test the idea. It takes any GitHub username and extracts 14+ signals (languages, stack, activity, code quality, collaboration style) into a JSON schema.

Two scores per profile:

  • Human Visibility (0-100): how findable by recruiters
  • Agent Readiness (0-100): how readable by AI tools

Not pitching this as the answer. Genuinely curious what this community thinks: is a machine-readable developer identity standard inevitable, or am I solving a problem that won’t actually materialize?

Link in the comments. Please check it out if you also think this shift is coming sooner than people expect.

reddit.com
u/Junior_Bake5120 — 11 days ago
▲ 0 r/github

Your GitHub profile was designed for human eyes. AI agents are about to be the ones looking.

Think about how the web evolved:

  • robots.txt so crawlers could understand websites
  • schema.org so search engines could understand content
  • llms.txt so AI agents could understand documentation

Developer identity has no equivalent yet.

You spend time on your GitHub profile. Pinned repos, contribution graph, maybe a profile README with badges. It looks good to humans. But AI agents evaluating developers? They see unstructured HTML, missing metadata, and zero standardized signals. No structured data about your tech stack, code quality patterns, or collaboration style.

This gap is going to matter. Agents are getting good enough to screen developer profiles for hiring, open-source matching, contributor evaluation. The question isn’t if this happens, but when. And when it does, the developers whose profiles are machine-readable will have an edge over the ones who only optimized for human scrolling.

I built a proof of concept to explore what a structured developer identity format could look like (adding the link in the comments)

reddit.com
u/Junior_Bake5120 — 11 days ago
▲ 1 r/PythonProjects2

Should developer profiles have a machine-readable standard? Like robots.txt but for devs.

We have robots.txt for crawlers. schema.org for search engines. llms.txt for AI documentation. But there’s nothing equivalent for developer identity.

Right now, AI agents are getting good enough to do several things. Devin ships code. Claude reasons through codebases. It’s not hard to imagine agents screening GitHub profiles and evaluating devs in near future, checking commit quality, stack depth, collaboration patterns, and surfacing candidates before a recruiter opens a tab.

When that happens, GitHub profiles have a problem. Pinned repos, green graphs, polished bios. All designed for human eyes. An agent sees unstructured HTML, inconsistent READMEs, and zero standardized signals about what someone actually builds or how they work.

I’ve been thinking about what a structured developer identity format could look like. Built a proof of concept in Python to test the idea. It takes any GitHub username and extracts 14+ signals (languages, stack, activity, code quality, collaboration style) into a JSON schema.

Two scores per profile:

  • Human Visibility (0-100): how findable by recruiters
  • Agent Readiness (0-100): how readable by AI tools

Tech details if you’re curious: Python 3.11+, Typer, async httpx with semaphore-based rate limiting, Pydantic, Rich, diskcache. 14 extractors run concurrently via asyncio.gather. 361 tests with httpx.MockTransport, zero real API calls in the test suite.

Not pitching this as the answer. Genuinely curious what this community thinks: is a machine-readable developer identity standard inevitable, or am I solving a problem that won’t actually materialize?

GitHub: https://github.com/chiruu12/devcard

reddit.com
u/Junior_Bake5120 — 11 days ago
▲ 55 r/gsoc_2027+6 crossposts

GSoC results just came out. Whether you got selected or not, if you're contributing to open source, this might help.

As a mentor and a past contributor, I see the same patterns over and over:

  1. Contributor picks a random issue filed by some user. It never gets reviewed.

  2. Contributor skips CONTRIBUTING.md. PR gets rejected for process, not code.

  3. Contributor uses AI to write the fix. Can't answer a single question during review. PR dies.

  4. Contributor doesn't understand the codebase. Patches the symptom, not the root cause.

I built [OSS-Skills](https://github.com/chiruu12/OSS-Skills) - 8 Claude Code skills that walk you through the contribution process step by step. The key difference: the AI researches, you think.

What it does:

  • Finds unclaimed issues filed by actual maintainers (not random users)

  • Checks if the repo even accepts outside contributions before you waste time

  • Reads CONTRIBUTING.md so you don't skip the thing that gets your PR rejected

  • Walks you through the codebase architecture before you touch anything

  • Teaches you unfamiliar tech using examples from the actual repo (not generic docs)

  • Won't let you submit code until you can explain what it does and why

What it doesn't do:

  • Write your code for you

  • Generate PR descriptions

  • Let you skip understanding the codebase

Every skill has "thinking gates" where you have to explain your understanding before moving forward. The AI gives you hints about where to look, but you have to articulate the answer.

Requires Claude Code and the GitHub CLI.

If you try it, I'd genuinely like to hear what worked and what didn't. Open an issue or drop a comment here.

For GSoC candidates who didn't get selected this round: these skills are specifically designed to help you build the kind of deep project understanding that makes GSoC proposals stand out. Contributing well > contributing fast.

u/Junior_Bake5120 — 3 days ago