GSoC 2026 Week 8

8 Jul 10, 2026 – Jul 17, 2026

Week 8 was the official midpoint of GSoC 2026, and it felt like one. My focus shifted slightly from implementation toward documentation and process — submitting a website PR based on feedback, writing a formal server access proposal, finishing the mid-term evaluation, and looking into an infrastructure problem with the live DBpedia mapping website. Each of these meant stepping back from code to think about where the project was heading.

Website PR #2

Based on mentor feedback from the PR #1 review cycle, I refactored the Amharic DBpedia website again and submitted the changes as PR #2. This PR addressed specific UI and UX suggestions from the review: I adjusted the layout for better readability on smaller screens, refined the data presentation components to better communicate what each statistic means to a visitor unfamiliar with knowledge graphs, and made several minor accessibility fixes based on mentor comments.

Working through a second review cycle was worth more than just the specific changes it produced. The feedback pattern — submit, review, revise, re-submit — is the real-world open-source contribution workflow, and practising it on a project with active mentors is better training for future contributions than just merging my own PRs would be.

Server access proposal

The cluster administrators at Leuphana required a formal written proposal before granting GPU access, so I wrote and submitted a detailed server access proposal describing the experiment design in full: the research motivation (benchmarking multilingual LLMs for Amharic property mapping), the specific models to run (five from the candidate list), the compute requirements (minimum 48 GB VRAM for the 32B parameter model), the expected run time per configuration, and the output format (per-model CSV files in a structured results directory).

Writing the proposal was a useful exercise on its own. Explaining the experiment design precisely enough that an administrator unfamiliar with NLP could evaluate it forced me to be clear about exactly what I was testing and why. This is the document that eventually unlocked H100 access in Week 11.

Mid-term evaluation

I completed the GSoC mid-term evaluation this week. In the discussion with mentors, we went over the first eight weeks: the website build and two PR cycles, the mapping pipeline experiments on Kaggle, the model selection and benchmarking rationale, and the extraction framework work. It gave mentors a formal chance to give structured feedback, and it gave me a clear milestone marker — a written record of what I'd done and what was left for the second half.

The mid-term also clarified my priorities for Weeks 9–14: the extraction framework bugs I'd been accumulating in notes but hadn't filed as formal issues yet, the multi-model benchmark that would need H100 compute, and the integration plan for the best-performing configuration.

DBpedia mapping website — VPN issue

I found a significant infrastructure problem this week: the live DBpedia mapping website at mappings.dbpedia.org is inaccessible without a VPN connection routed through specific European university networks. For contributors working from Ethiopia or elsewhere in Africa, that's a real barrier — the VPN access isn't publicly available, so the very people who might contribute Amharic mappings can't reach the platform where mappings are submitted.

I discussed it with Thomas Tsoru, who confirmed it's a known hosting configuration restriction, not a temporary outage. We agreed this would need to be raised as an infrastructure issue with the broader DBpedia organisation, since it affects any volunteer working from a network outside the allowed ranges, not just Amharic contributors. This became one of the background findings that led to building kgproxy in Week 14.