-
Notifications
You must be signed in to change notification settings - Fork 667
Dev Days
Hello, and welcome to ASWF Dev Days!
The ASWF is organizing an event called "Dev Days," which is kind of a hackathon with the goal of getting a bunch of people who are not frequent contributors to these projects (or maybe any open source project) to pick a "one-day" task and make a contribution. The next ones are scheduled for May 14, 2026, and then again on September 17, 2026. On Dev Day, the senior developers of the project will be monitoring the mail list, Slack, and GitHub, standing by to answer questions, review code quickly, and help you through the process.
Check out the ASWF Dev Days site and the participating projects, and if you are interested in participating, please register! If you have questions, please reach out, or join the #devdays slack channel on the ASWF Slack instance.
If you're reading this, you're probably interested in contributing to OpenImageIO. So also say hi on our Slack or mail list, introduce yourself, and let us know what you'd like to work on (or ask for advice on what to work on).
Here's how I explained it to people in my own company:
I really can't emphasize enough how much participation in these open source projects can be an enriching professional experience: becoming more knowledgeable about, contributing to, and steering technologies that are critical to us and the industry as a whole, while collaborating with, learning from, and having your work seen and acknowledged by your peers at other studios. This event is a low-stakes way to dip your toes into any of these projects for a day.
This is for you to get something out of, but it's also for us as a company. These projects are not just fun, do-gooder tasks. Almost every one is a critical technology underlying our tools and productions. Sometimes, though, we may have only one person who is knowledgeable about the internals and feels comfortable fixing or enhancing these projects, and that's a risk given how important they are. So it's helpful for us to have multiple people who feel like they can jump in and make changes needed.
- Check out the ASWF Dev Days site and blog post, they will have a link to a form to sign up.
- Choose a project (probably OIIO if you're reading this here) that you'd like to learn more about by working on for a day.
- If you're doing this at work, arrange with your supervisor to get the time on those days to work on it, duh, and also your company may need to do some advance work to ensure you have permissions to work on the project, get CLAs signed, etc. Just check with whoever seems to be experienced with open source at your company to have them tell you what, if anything, you need to do. If you are a student or independent, or know for sure that things you work on in open source are your own, then you can skip this step.
- Between now and the designated work day (I advise at least several days in advance), figure out how to check out and build the project so you aren't fumbling with that for the first time on the work day. Many people have unwisely waited until the last day and then never completed their task because they spent the day doing basics like installing dependencies or figuring out for the first time how to compile C++ code.
- Choose a task. See below.
Ideally, you want to choose a task that's big enough that you'll learn something and that will be helpful to the project, but small enough that you can probably complete it in one day. Hard enough to stretch you, easy enough to leave you excited and wanting more.
Our Contribute Page is a list of curated "good first issues" that we think are suitable for somebody's very first code contribution to the project.
A more extensive Issues Page lists all open issues, many of which would be considerable work even for experienced developers on the project. Feel free to choose anything you see, but beware that they are a mix of difficulties, all the way up to open research problems.
Let's suggest a couple that are evergreen, meaning that the issue describes a general task that needs to be done in many places, each of which can be a one-day task, so multiple people may select the same task (as long as they coordinate enough to know they are all choosing separate instances of the task that need to be performed).
-
Turning documentation examples into tests #3992
We have a detailed explanation on our Wiki.
Basically, the task is to take a code example from the documentation, and turn it into a testsuite entry, debugging/fixing if necessary (then changing the docs to just include the test by reference, so it's not duplicated). The point here is:
- Make sure most of the code in the docs is tested, and works for sure, and by being incorporated into the testsuite, can never become "stale" (for example, by the APIs changing but the examples in the docs docs don't change to match).
- Beef up the testsuite with more examples, better code coverage in the tests -- without having to write new tests from scratch, but merely take code already existing in the docs.
-
Annotate API functions as "nodiscard" #4781
We recently added macros
OIIO_NODISCARD(for functions with essential return values, which if ignored are surely consequential errors), andOIIO_NODISCARD_ERROR_RETURN(for functions returning status or error codes). We would like to use these were appropriate across the whole code base. There's a lot, but it can be done in small bits and in parallel:- Pick a single header file or class -- or a subset thereof, if it's big -- and add the annotations.
- Fix up all the places in our own codebase where we previously did not have the error handling logic that should have been there all along. (This is the hard part, and why you probably only want to so annotate a few function calls at a time.)
-
Add self-building abilities for more dependencies #4387
We recently modified OIIO's CMake-based build system to have capabilities to download and self-build certain dependencies if they are not found. It would be great to expand this to more of our dependencies. The PR #4387 lists several of these. Any one of them is a perfect 1-day project for somebody who knows CMake and has some patience for figuring out package build difficulties. There are several examples of packages we do this with, so you're not starting from scratch, and no actual knowledge of OIIO code internals is needed. You don't even need to know C++ (though it helps if you have build a few C++ projects from source using CMake).
-
Something else that you pick
Does it have to be something we suggest above? No.
Does it have to be something we marked as "good first issue?" No.
Can it be something that's not a currently filed issue at all? Yes!
Can it be something that you have a particular interest in, or your management has a selfish ulterior motive because it's related to how you or your company use OpenImageIO? YES YES YES! This would be the ideal case!
There will be a decent amount of prep work and setup required to get your development environment ready to contribute. Please don't underestimate this time - if it's your first time building a project from source, please allow yourself at least a few day's time to familiarize yourself with CMake (helpful documentation is available on the main Dev Days Wiki). Even if you're more experienced with the build process, please allow a few hours for setup, in case you run into issues specific to OIIO and/or your platform. We provide build instructions for Linux, Mac, and Windows, but cannot reasonably test for all permutations within them. For OIIO (like most ASWF projects), please keep in mind that the majority of our developers are based on Linux or Mac development environments. We will do our best to assist with Windows, but please allow ample time.
We suggest going through the process of cloning, forking, building, and figuring out how to submit a PR PRIOR to the actual Dev Days event, so that your time can be actually spent working on your issue, vs. debugging setup. We recognize that the learning curve for getting ready to contribute is steep - but know that once it's working, it will rarely change! It's like riding a bike. And we're here to help - so please reach out.
Please see our AI Coding Assistant Policy.
We strongly discourage use of coding assistants to author Dev Days submissions, because the whole point of Dev Days is to challenge yourself and level up your skills. You're not really doing that if you get the answer from the magic programming oracle.
Feel free to use coding assistants on Dev Days to explain code, review your code before submitting the PR, help you find bugs. But try to write the code with your own brain. That's how you actually learn and get better.
These are curated to be perfect for newcomers. Please leave enough to go around! If you successfully completed one "good first issue" and still have more time on your Dev Days to tackle more contributions, please choose something that is not marked as "good first issue." (Because it's no longer your first issue, duh! Leave it for somebody else who needs a bite-sized task to learn with).