Grants talk:Programs/Wikimedia Community Fund/Rapid Fund/Wikireceipt Machine Toolkit Creation and Workshop 2026 (ID: 23654226)
Add topicComments from I JethroBT (WMF)
[edit]Hello ~fjpaz-net, and thanks for preparing this proposal stemming off from your showcase at the WikiGameJamNYC and preparatory development work. Please see my questions and comments below:
- It's great to see proposals working to build and make fun things in the Wikimedia movement. This is the kind of work that helps builds a positive and joyful cultural identity in the movement that celebrates the mission and the volunteers who help realize it. As you said, experienced editors who received a paper print out of articles they like were appreciative.
- The overall budget is above the funding limit for Rapid Funds, and while I understand the proposal is set for 5,000 USD, it would be helpful to hear about what other funding sources are available to you to support this work.
- The budget also calls for fiscal sponsorship, but this is not typically needed for an individual project. What is the need for a fiscal sponsorship in this case?
- There are significant risks to funding a project whose impact is premised on speculation that other people will adopt the technology and develop additional, future projects that are undefined. This means that the remaining outcomes are limited to participation and resources on how to use the technology, but these outcomes do not make the clear the benefit of the technology itself for the communities that can use or interact with it. For this level of investment (the maximum for this funding program), more concrete impact will need to be offered beyond these metrics. For example, if receiving a paper printout of an article helps people be more motivated or enthusiastic about their participation in the movement as you reported (whether as a reader or a contributor), is there a way to ask participants about this?
- Importantly, if this project is to be funded in this or a future cycle, it is important to note that Rapid Funds cannot sustain funding for the development of this project, as it was not resourced for this purpose. As noted in the proposal, it would be important to consider other funding sources for this project's longer-term development outside of Rapid Funds.
I have sent the proposal back to you for revisions on this need, as well as any other needs based on the above points. With thanks, I JethroBT (WMF) (talk) 18:31, 12 December 2025 (UTC)
- @I JethroBT (WMF): Dear Chris,
- Thank you for the detailed feedback, and apologies for the slow reply over the holidays.
- Regarding other funding sources: The only confirmed external support to date is a USD$1,000 seed grant from WikiHaus that was provided to me directly to begin early prototyping and planning work because they saw the potential of this project from the WikiGameJam after event. Beyond that, I will ensure the core deliverables below are achievable within the USD$5,000 request. If we later secure additional funds, they would be used only to scale beyond the minimum plan (e.g., additional features, hardware or deployments).
- Regarding fiscal sponsorship: This project has several parties who will receive payment or reimbursement (myself for software work, Hex House for space rental, and vendors for equipment, event supplies, etc.). As I'm new to the Wikimedia grant process, having an experienced fiscal sponsor handle the finances would help things flow more smoothly and ensure accountability and good reporting.
- Regarding risk, impact, and participant feedback: I agree that the strongest impact claim here should not depend on other people potentially building additional projects. I'm revising the project framing accordingly, such that the primary outcomes are (a) a reproducible toolkit that can be deployed by Wikimedians/affiliates for personal use & at events, and (b) direct + measurable engagement from at least two real-world deployments.
- Concretely, within the Rapid Funds scope I will deliver:
- A v1 release: open-source code + installation/run documentation, along with a hardware bill of materials and setup guide for running the kiosk with a standard receipt printer.
- A basic web UI for straightforward "search → preview → print," with an admin panel for print settings and basic diagnostics.
- Improved article formatting fidelity versus the current prototype (prioritizing tables/structured content, special characters, images & layout) to get closer to parity with the native/digital reading experience.
- A public-facing workshop/activation at Hex House where participants use the kiosk, exchange printouts, and provide structured feedback. (This is intended to be equally accessible to non-technical participants and developers alike.)
- At least one additional deployment with a Wikimedia community group / affiliate (e.g., Wikimedia NYC), focused on community use and feedback.
- Each printout's QR code (at the bottom of the sheet) currently points to the corresponding Wikipedia article URL. During public activations, printouts' QR codes will lead to an intermediary page where users can opt to provide structured feedback before accessing the article page.
- We also surveyed a few of the Wikimedians who tried out the prototype Wikipedia receipt printer for the first time at the WikiConference North America WikiGameJam gathering, and here is the feedback they provided:
- "It's a nice physical reminder of my digital efforts and also represents my passions"
- "On my bedroom door, I have a receipt of two pages I wrote—“White Ferrari,” the Frank Ocean song, and “Supernatural,” the NewJeans song. Both are very meaningful to me and nicely represent my contributions to Wikipedia in physical form. In particular, the latter was written in Japanese and didn't print properly in the early prototype, so as a bilingual Wikipedia user, I'm excited to see more support for this project such that more languages, and other kinds of functionality, can be developed!"
- "I thought it was really cool to have a physical version of something that's constantly updating, capturing an article I really like in the moment. I printed stationery & leopard gecko [lizard emoji]"
- We can build in a survey as part of this project, to see the impact it has on editors and the public (and see if they differ).
- Thanks,
- ~fjpaz-net (talk) 18:16, 5 January 2026 (UTC)
Sundance 2026 Deployment Report
[edit]@I JethroBT (WMF): Dear Chris,

I'm writing to share results from the first major deployment of the wikireceipt system at the 2026 Sundance Film Festival (January 22–February 1), where WikiPortraits, WikiReceipts and related Wikimedia activities combined for WikiHaus at The Shop, a 4,000 square foot space in Park City.
Over a series of 4 events, we used the opportunity to tackle some kinks in the software and physical presentation.
Metrics
[edit]| Metric | Target | Progress |
|---|---|---|
| Participants interacting with kiosks | 75 | ~85-100 |
| Wikireceipts printed | 100 | ~110 unique articles |
| Events/activations | 1 workshop + 1 affiliate | 6 deployments (Wikipedia Day, WikiPortraits gathering, cinematographer's lunch, hot pot party, film screening + dumpling party, film programmers' meetup) |
Technical Deliverables
[edit]The software has reached a functional v1 state. Core features implemented so far:
- TypeScript package with modular architecture (wiki parsing, printer interaction, QR generation, Unicode/multilingual support via image rendering)
- Web UI for search → preview → print workflow, with settings panel for printer actions/options
- Two print modes: Content (summary/lead, full article, or custom sections) and Links (browse mode with scannable QR codes for linked articles)
- Revision history support: users can select & print any historical revision of an article (feature added in response to user request)
- Language selector: user can switch to & print in available alternate languages, with nearest-revision selection
- LaTeX/math rendering via SVG rasterization
- Partial table rendering: equivalent to tables as rendered on narrow screens
- Inline image galleries with caption support
- Dual barcode scanner interaction: multiple scanners can operate in different modes (view vs. browse), enabling depth-first exploration of Wikipedia's link graph
-
Image gallery rendering (Bánh mì)
-
Set of varied-length Fall Out Boy printouts
-
Basket containing receipts produced over the course of an activation
Qualitative Findings
[edit]User engagement / social dynamics:
- Wikipedians gave sustained engagement (trying multiple articles, exploring features)
- Non-Wikipedians enjoyed printing articles for works they had contributed to
- The printer became a gathering point for conversations about Wikipedia; people learned about each other through their article choices
- A group from the same hometown (Pleasant Grove, Utah) clustered around printing local articles including Máni and Christa McAuliffe Space Center
Coverage gap surfacing: At a film festival programmers' meetup, one programmer repeatedly searched for things from her festival that weren't on Wikipedia. She tried different queries with no results, seeming somewhat disappointed that Wikipedia didn't reflect the festival's real-world importance. The printer became a sort of mirror showing / prompt to find content missing from Wikipedia, versus what's there.
Feature requests that drove development:
- ja:Supernatural (NewJeansの曲), which failed to print properly at WikiGameJam in New York, inspired full-fledged multilingual support (which I implemented via rendering & printing GNU Unifont text in appropriately-sized images in advance of the festival). A friend of the contributor who'd requested it was present at the last printing session in Park City, and we were able to print the full Supernatural article (along with a number of others) for this user to take home.
- A friend of a contributor wanted an early revision of Monobrow printed (the article's first substantial version was written by the contributor in question). I was able to add revision support to the UI and layout system in time to print the article the next evening.
- A CS undergrad requested Dijkstra's algorithm and Big O notation, which prompted LaTeX rendering implementation.
Challenges
[edit]
Survey feedback: The QR code feedback survey received zero responses despite being technically functional throughout the festival. In addition to explicitly mentioning or otherwise highlighting the existence of the survey to more users, I'll rely on proxy metrics going forward, including print history logs and GitHub engagement.
Presentation clarity: Early events had relatively low engagement because it wasn't clear what the station was, and we had to be located in a corner to have access to outlets. We adjusted the presentation layout to be more inviting, with great success at the dumpling party in particular. Future deployments could use similarly clear signage, like a banner or more wholly-integrated kiosk design.
Length estimation: Users were sometimes surprised (albeit often positively) by print lengths for long articles. This is a friction point I plan to address with clear visual indicators of receipt length in the web UI.
Hardware Configuration
[edit]
Laptop + Epson TM-series thermal printers, with barcode scanners used primarily with Wikipedians on final days.
Next Steps
[edit]- Wikipedia Day NYC March 2026: I expect to present a more refined version of the system in New York at the rescheduled Wikipedia Day event this March. This will allow me to collect more feedback and see whether the Sundance observations were unique or more broadly applicable.
- Hex House workshop (not yet scheduled): I plan to focus on the multi-scanner interaction model. Considering a "buddy system" where Wikipedians bring friends who don't know Wikipedia to test approachability.
- Length estimation feature: Visual preview showing receipt length / "scroll thickness" before printing.
- Documentation: README, setup guide, and hardware bill of materials for reproducibility.
- Public repository release with open-source code.
Reflections
[edit]The most salient takeaway so far is that this project's strength seems to be in its use socially. The printer serves as a reason for people to talk about Wikipedia, to share what they care about, and to discover feature gaps (leading to improvements to the system); in its best moments, the tactile artifacts feel almost secondary to the human interaction facilitated by the process of creating them.
Thanks, ~fjpaz-net (talk) 00:01, 5 February 2026 (UTC)