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