Skip to content

Dev Days 2024

Larry Gritz edited this page Jun 11, 2024 · 5 revisions

Hello, and welcome to ASWF Dev Days!

What is this?

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 haven't contributed to these projects (or maybe any open source project) to pick a "1-day" task and make their first contribution. It's scheduled for September 25-26, 2024 (you pick whichever day or time split is convenient to you). During that time, the senior developers of the project will be monitoring the mail list, Slack, and GitHub, standing by to answer questions 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).

Why is this helpful to you (and your company)?

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.

Preparation, if you are interested

  • Check out https://wiki.aswf.io/display/DEVDAYS/ASWF+DEV+DAYS+2024, they will (when we get a little closer) have 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 Sep 25, 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.
  • Choose a task. See below.

Choosing a task

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.

On our Issues Page, we try to mark things of this size -- maybe a one-day task for somebody who is new to the project -- with a tag called "good first issue."

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).

  1. Turning documentation examples into tests

    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 "obsolete" (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.
  2. 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, because it's related to how you or your company use OpenImageIO? YES YES YES! This would be the ideal case.

Get set up ahead of time

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.

Clone this wiki locally