Consider renaming prog, it's a bit unclear to me what's going on, since we're sourcing the value from a docker.PullStatus and returning it as a docker.PullStatus. Is this a status value?

it is a reference to a object which the consumer can poll for status continually

If this is an exported lib function, it'd be good to write a short explanation of what the function does as a doc comment.

I'll follow up in general with better docs for all of these functions

I see the case for int here, as opposed to string, since it looks like you use the values assigned via iota for marking progress later on. In this approach, you need the parsePhase function just to make sense of a given value. I think this is probably fine. At the same time, it's helping me to better think through my philosophy about this, and I might've approached it a bit differently. To me, the string values seem more directly associated with a phase's identity, whereas the progress values seem like a derivative use case. In that scenario, I think I'd define these values as strings, and then use a map or something similar to declare the associated progress values for a given phase (e.g. map[PullPhase]int64). Primary reason: this makes the identity of the value the first class citizen (i.e. doesn't require a specialized function like parsePhase) and the specific use within the progress/eventing system use one extra logic step. Secondary reason: this lets you decouple the scale of iota with how you want to scale progress. For example, maybe you want to make the WaitingPhase a lower value, since not much has been accomplished; maybe you want to me the PullingFsPhase take longer since it's I/O and represents more work; whatever, hopefully you get the idea 😄

to summarize our conversation: I'll leave the type of PullPhase alone and I'll translate the existing parse function for a map