Virtual Working Group Flowchart - v0.1 Draft for comment!

To the ACES community, especially developer-types!

As we have mentioned, in anticipation of the upcoming development work on the next generation of ACES (which we’ve dubbed ACESNext), we’re moving toward a virtual development process vs. our previous physical, slightly Hollywood-centric process. We want to encourage world-wide support and development, as well as faster turn around, and better visibility and accountability.

At Siggraph we previewed a chart that we hope will begin a discussion of how this could work. The chart is attached here and we welcome your suggestions, particularly if you’ve been involved with a similar effort. What worked and what didn’t and what are your suggestions for our ACES development efforts?


Hey @stobenkin, the graph looks good to me, it might evolve as we go but this is a decent start and approach.

Related to the BoF and as discussed over there, would it be possible to make a short summary post about what was said for people who did not attended?



Oh and while I think about it, one of latest point discussed was publishing answers to the ACES - RaE summary bullet points. :slight_smile:



Thanks for comments on Virtual Work Group chart…Summary and responses to RAE questions in the works!!!

1 Like

That’s fantastic, I was going to ask about the same thing. Seeing as I wasn’t there. Boo.

Sean Cooper posted a little somethin’-somethin’ over at the OCIO developer google groups –!topic/ocio-dev/aSc8rz1W7y8
He’s posted a nifty PDF there as well.

My only regret is not sharing my brilliant idea of AMPAS forking OCIO with the explicit intention of focusing efforts to help realize some of the less tangible / accessible aspects of ACES (CTL / CLF / CTF / ACESClip)… and I was gonna suggest calling it…
…wait for it…

Get it? ACIO? Cuz of the A, and the C, and… ah forget it, you ruined it.

Regarding the Proposed Workflow for ACES Development flowchart… are you guys familiar with Agile-style project management / product development practices? I’m hardly an expert, and I’m sure I’m about to misuse terms, but I believe the core philosophy emphasizes the maintenance of a contractual relationship between an enterprise’s development team and its stakeholders (ie, invested representative sample of the user base), as opposed to more major-feature / major-deadline-based approaches. And for ACES in particular, I think there’s enough heartache around major version updates matriculating through to pipelines as allowed for by the lowest common denominator (software / hardware / wetware).

Anyway – the idea is, Agile turns what one might normally call a stakeholder complaint into a stakeholder User Story – see, sounding better already – that explicitly and succinctly takes the form of madlibs: “As a _____, I need __________ in order to _______.” For instance, “as a compositing supervisor, I need to effortlessly and automatically toggle per-shot neutral grades in the cut in order to assess continuity”; “as an editor, I need a way to unambiguously verify the placement of these CDLs, in order to realize the dailies grade intent”; and so forth. And then there are Epics, which is Agile-speak for “multi-faceted / resource-demanding / longer-term / larger projects” (although still ostensibly to serve actual user stories).

(Of course, the RaE paper and subsequent bullet-pointed discussions have been wonderfully articulate and well-formed enough to serve as user stories).

I forgot what I was trying to say with all of this, apart from, if you guys aren’t familiar with Agile, maybe worth having a look; it may serve to conceptually streamline the flowchart without compromising its function.

That said – aesthetically, this flowchart overwhelms me. I don’t know if this is the kind of feedback you were hoping for, but I do know you guys all have flowchart fetishes; a little meaningful color denoting developer sprints / rnd vs community feedback solicitation would go a long way. And maybe the whole linear snake-like flow that forces my eyes to carriage return every four boxes… it’s a little visually unintuitive (to me)… and maybe even a little optimistic? I feel like any box that involves community feedback is either likely to generate less interest than expected, or more interest / sprawling conversation than anticipated. And there’s also no accounting for taste – the most parametric, invertible tonemapping in the world is still gonna leave people unhappy – and after a point, feedback becomes less productive.

I might just be reading the diagram too literally, though. At least there’s no one box that seemingly exists to counteract the effect of another, that’s a nice change of pace.

tl;dr – I think the flow chart is an excellent representation of the team’s best intentions, and serves as a good model for developing with transparency and community feedback in mind. I think it might be a good idea to throw out some specific topics, moderate a thread or two around – ooooh… i don’t know… dynamic metadata? When is too much too much, and where / how is that distinction made? Or… maybe… if we’re feeling particularly fearless, we can discuss TRTs and DETs… I don’t think I’ve ever seen those acronyms mentioned… to what end will they be “cannon” ACES?

just some thoughts. cheers nerds.

Thanks for these thoughts Zack! I’ll bring it up again as we move forward. :slightly_smiling_face:

Thanks for the feedback …

Attached is a revised workflow chart that was presented and discussed at the first ACES ODT Virtual Working Group Meeting.

We’d love to know what you think of this latest rev.

ACES Development Workflow Flowchart (562.0 KB)