Infrasity-Labs/awesome-developer-conferences

What's wrong This repository doesn't have a .gitignore file at all. That means anything a contributor generates locally while running the fetchers/checks — __pycache__/ directories, .pyc files, local .env files with API keys, editor artifacts, events_*.json intermediate output, etc. — is one git add . away from being accidentally committed. (Sibling repo developer-marketing-jobs already has a .gitignore covering the basics, worth using as a starting point.) What to do Add a .gitignore at the repo root covering at least: __pycache__/ *.pyc .env .DS_Store Consider also ignoring the intermediate events_*.json files produced by individual fetchers before aggregate.py consolidates them into README.md, and events_added_count.txt, if those are meant to be regenerated per-run rather than committed — check with a maintainer/existing CI workflow if unsure which generated files are intentionally tracked. Acceptance criteria A .gitignore file exists at the repo root. No functional/runtime

What's wrong aggregate.py deduplicates events using config.event_deduplication_key(event), which builds a key from the event's name, date (year+month), and location — deliberately, per the code comment, "to avoid deleting different editions of the same conference series." The standalone root-level dedupe_readme.py script does the same job — cleaning duplicate rows out of README.md — but with its own, separately hand-rolled logic: # 1. Dedupe by Exact URL if url and url in seen_urls: is_dup = True # 2. Dedupe by Substring Name if not is_dup: if name_clean in seen_names: is_dup = True This key is based only on name and URL — it never looks at date or location at all. So depending on which script is used to clean up README.md (aggregate.py's inline dedup vs. running dedupe_readme.py directly), duplicate detection behaves differently for the same data. That's confusing to reason about and a likely source of subtly inconsistent README cleanups over time. What to do

What's wrong fetchers/config.py already defines a shared, fairly thorough determine_region(location, name='', link='') used by aggregate.py to bucket every event into a region section of the README. However, fetchers/meetup.py and fetchers/luma.py each define their own local determine_region(location) function that: duplicates the same job with a much smaller/less accurate country & city list than config.py's version (e.g. missing most of Africa, South America, and many Asian/European countries config.py covers), and is never actually called anywhere in either file — __main__ in both fetchers just dumps raw events to events_meetup.json / events_luma.json with a location string, and it's aggregate.py (via config.determine_region) that does the real region categorization downstream. So these two local functions are both dead code and a maintenance trap: someone might reasonably assume editing meetup.py's determine_region() affects region categorization, when in reality only config.py

Bug Description There's no tests/ directory or test runner anywhere in the repo, despite fetchers/config.py (determine_region, deduplicate_events, parse_date) and checks/parse_readme.py (parse_date, parse_readme) containing exactly the kind of fiddly string logic that regresses silently, as shown by the substring-dedup and escaped-pipe bugs already filed against this repo. Link to the Conference (if applicable) Not applicable, this is about test coverage for the shared parsing and classification logic, not a specific listing. Expected Behavior The core logic used to classify and dedupe events should have test coverage so a regression gets caught before it reaches main. Additional Context Suggested fix: add a tests/ directory with pytest covering: determine_region(): a handful of city and country strings per continent, plus the "unknown location gets rescued from name or link" path for virtual events. deduplicate_events(): same series in a different city should not be treated as a dupl

check_url() function in checks/url_check.py currently validates every conference link by spawning a fresh subprocess.run(["curl", ...]) process per entry. Even with ThreadPoolExecutor(max_workers=50) handling concurrency, each check pays the overhead of launching an external shell process, and being tied to subprocess rules out true async I/O. We'd like this rewritten to do the HTTP check natively in Python using requests or aiohttp. Replace the curl subprocess call in check_url() with a native HTTP request (requests.head()/.get(), or an aiohttp equivalent) Preserve the existing timeout behavior (--max-time 10) and retry behavior (--retry 2) Keep the same User-Agent string (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36) — some sources block default Python/requests UAs Preserve the exact status-code classification logic already in place (0, 200, 301, 302, 403, 415, 429, and all 5xx codes count as "alive"; anything else is dead) as this logic intentionally treats WA