Useful to write a proposal as to why we want / need Technical Writing, this one is OCIO specific
Is it worth asking for funding? Do other projects have these needs?
OCIO needs more than just documenting the code base, that part is pretty good, needs ongoing work, but it’s under control. What’s not there are things like how to use OCIO, how to make sure that everyone has the same expectations of what it means to support OCIO in your software.
Have had a WG for 12-18 months to try and standardizing around UI/UX considerations for OCIO. Have relied on early standards established around how UIs should work around OCIO, and the industry has standardized on current ACES config, that’s help since it provided a starting place. But still lots of inconsistencies around functionality, different apps deal with automatic conversations differently, may or may not be transparent to the user. Color picking also a source of differences. We think it should be more consistent between OCIO apps.
This proposal is based on the work of this WG, with a link to the full document.
It’s a lot of work to get this document in a final form that end users could take in and digest, this is what the writing proposal is about.
Need someone to be hired to help with the writing work, not only do we not have the time, but also not the skillset. Would like this done well, by someone who’s job it is to write technical documents. Will need to work with this technical writer, may not be less work for the OCIO team at first, but with it long term.
Went through exercise of how we would expect this to work, 1-2 days a week maximum, estimate what would something like that would cost.
Wanted to present this to the TAC.
Kimball: ACES at one point didn’t want to mandate a particular UI, but to get ACES certification, you had to get certain components in your app? Carol: not the first time the LF has done something like this, outcome could be a conformance program, but first need to establish what the guidelines should be. Kimball: can put you in touch with tech writer team at WETA, other member companies may also have tech writers, could count as a member contribution, apart from writing code. Or at least could put in touch with resources. Carol: want to identify common needs and trends between projects, how do we use funding and is this a good way to use it. John: from experience, least attractive job in open source is writing documentation, across LF projects, project communities can churn out small pieces of documentation, but hard for large documents. A tech writer is useful, they can help put that together. LF has used freelancers with success, the document put together by OCIO is a good first step to scope the work. A challenge with tech writers is how to scope the project, easy to eat up a lot of hours, fixed bid can result in more accountability. Best if can define what is the scope of deliverable 1 to get out the gate. Lots of learning in this process.
Kimball: suggesting to get tech writers who have that job, but could use people who work in the current M&E industry. John: hardest part is finding Subject Matter Experts (SMEs). Brian: tried to find tech writing resources within companies on the TSC and didn’t have any luck. Carol: had benefit of Autodesk contribute a tech writer to get over the hump for 2.0 release, took a lot of work to get up to speed, but may have hit the limit of the resource contributed by Autodesk. Consistency is important, would love to be able to have someone who is consistently available through the process, as opposed to only having intermittent access. Also want to keep the voice consistent, and not have to “retrain” multiple people. Would like to get the process done in a smooth fashion.
Kimball: we need someone who is paid to be on retainer, however many hours to help all the projects. John: looking at document, might be helpful for me to join more OCIO TSC to ask more questions, and figure out how to move forward. Also can join a OpenCue TSC. Brian: still working on final list of what we need.
Carol: not expecting final decision today. Jonathan: on the alignment between projects, the OCIO documentation is great, including the web site, would like to borrow ideas that are shareable, would like to borrow ideas to up level our documentation. That can improve harmonization across projects, and increase the quality of documentation across projects. Carol: we need a document describing how we did our documentation, how all the pieces and systems fit together. It’s not all that complicated, but leverages a number a tools, and no reason to to reinvent the wheel. Jonathan / Larry: want to second how well the OCIO documentation works, OCIO had a separate documentation subcommittee that met weekly for months, it was not a small feat. Project that wants to emulate how well that turns out may need to emulate the amount of work. Carol: needed to figure out what direction wanted to go in. Sometimes you get a pretty result, but it was a lot of work to get there.
Kimball: seems the next non-strategy meeting of the Governing Board should explore funding for something like this.
Linux Task Force
Linux task force presented by Nick Cannon at Open Source Forum. Focussing on desktop experience, anyone interested should run out to Kimball or JF. Looking at various distributions, and looking at where to go next, how to keep Linux a core desktop environment for our community. If anyone has anything to contribute, feel free to reach out.
John: Jim Zemlin had offered resources at the Open Source Forum, did this happen? Kimball: don’t think anything happened yet. John: can help find the right people to engage.
Scott: letting someone else organize the group (Rust WG is already a lot!). Carol: how to they propose to control scope? Scott: studio pipeline tends to be unique per studio, but if you dig to the core, for the most part they are all similar, initial scope would be to identify common components. What if a new studio pops up and needs to start a pipeline, ASWF could provide a pipeline with all the resources you need to get going. What is a shot, what is an asset, what is a publish, can we be in sync when it comes to terminology.
Kimball: could it be like the Virtual Production glossary? Scott: could start with that approach.
Kimball: do you think this working group could help bring more people into the foundation? So it’s not just the same group, spending time on another topic? Scott: I think so, I’m a pipeline TD, and could see more pipeline TDs get involved. A common thread between pipeline TDs is moving between studios and new studio has just started setting up their pipeline, so have to rewrite something from scratch. So people “in the trenches” could help put together something that could get started. So I think the answer is “yes”.
Larry: what do you see as specific deliverables? Pipelines tend to be very studio specific, so what parts could become portable? Pipeline means different things to different people. Scott: core elements that you would use. For instance the Shotgun Toolkit provides the core: entities, path resolution system, how to publish, how to save your files… But that’s tied to the Shotgun ecosystem. WG or project coming from WG could be an open source back end agnostic core foundation of a pipeline, as time progresses, could start adding more “opinions”. For a studio focussing on episodic work, here are tools that will get you 90% there. Or could just focus on foundation. Talked briefly about what a non-legacy / cloud native pipeline would look like. For instance using an object store for your objects, how would that look. Could be a layer on top of the core infrastructure. Core infrastructure has entities, layer on top looks at files, the higher the layer, the more concrete / specific you get.
Carol: there could be a lot of directions this group could go into. There are things in here that could be interesting. When I read this, let’s not reiterate what’s already been done. A taxonomy has already been done in the context of a “traditional 90s VFX pipeline”. We don’t necessarily need a “what to name things” group, since that’s been done. But a “pipeline next” that identifies the missing bits.. “What tools do I need to write to get to a specific result” is how pipelines are built. So may be hard to envision a “pipeline WG”, what would be the deliverables / goal? Just making it open source may not be enough.
Scott: may not have an answer on that. Carol: we want to continue having discussions. Sean McDuffee: M&E has been in a POSIX / NFS world for a bit too long, there are interesting things happening in the HPC world that could be of interest to look at. Also the underlying fundamental data models, how to store and retrieve files, could this use modern HPC filesystems. Scott: yes, that seems aligned with the proposal. What is the next stage of what a studio pipeline could look like. Original thought was more along the lines of “here’s what we consider a good, solid foundation to build your pipeline upon, but need to consider the cloud”. For instance how do you sync between the cloud and your studio, what tools and technologies could be provided to help manage that. Also a new studio starting out, how do you hit the ground running without having to write a ton of tools from scratch.
Kimball: should ask to reconsider the scope to narrow down to make it clear what the WG wants to work on. Seems to be the general feedback from the group? Allen Rose: is it an incubator for other projects, break off other pieces of work that could be tackled. Or maybe conversations can be more informal, and spin off WGs for specific topics?
Proposal to the mailing list, with some back and forth discussion
Larry: not necessarily a complete proposal, more of an introduction. Some questions may be “what the intention is”
Kimball: there’s some source code involved, include files, sample plugins
How do we want to manage open standards.
David: OFX is a good example of a set of libraries that has both open source and commercial aspect. Existing ASWF projects are being used in commercial projects. Larry: commercial use makes these projects work! David: some companies have used open source to advance their own needs, we may come in touch with those in the future. OFX is a good project to develop our “muscles” around those areas, possible improvements between open source libraries and the ways people use them. Also how we would want to clean up the ecosystem if we wanted to.
How does an existing foundation joining a LF foundation work? John: was involved was an independent project called ODPI, was an independent organization, merged into LFAI project, had to merge governance structure, membership tiers, was more complex since there was significant revenue and assets involved. Right now in the process of doing due diligence to understand what this could look like. From the email, seems like there would be a welcome to fold in, but they may be looking more at the benefit of the TAC. To comment about standards: ASWF hasn’t done a lot of standards work, but LF has a lot of expertise it could contribute.
John: these types of conversations would likely happen at the Governing Board. David: yes, will take care of it. The TAC decides whether to accept the project, but also develop a good vision with the people from OFX as to where it should go from here. Joshua: would be good to hear from OFX project what is their vision and hope to gain from joining.
Michael Min: could they be a TAC participant like USD without being an official project, does it have to be a project? Kimball: interesting question, do we need a group focussed on open standards, more than some of us may be interested in. Did interface initially with Bruno Nicoletti on creating the OFX standard.
Larry: have never used OFX, can someone speak to it? Also if what we saw in the repo is just a PDF that lays out a standard, would be a more meaningful debate about becoming a caretaker. But there’s code, lots of our projects make a standard + API. Is there a missing library that should be fully fleshed out that would give a substantial improvement? Or are their header files already fully fulfilling the need? Header only libraries have value. Kimball: at the time OFX was created, it was the least common denominator, so hard to do anything that’s performance. Deke: Katana supports OFX. Larry: if it needs a complete rewrite, that’s a different thing, may need to start from scratch.
Kimball: it may have undone that, some things were added for threading, GPU support.
Carol: have used OFX in a couple of situations, have some OCIO OFX plugins, useful way to demonstrate functionality. But don’t suggest using it in production. There’s usefulness in debugging. But the foundation should get behind such a standard we would want to use in our projects.
JF: OFX plugins used a lot in mid tier facilities.
Kimball: we should have them present, seems the general consensus. Does it have wider implications for us becoming a standards body…
Tentative: WG mission statement update process (context of CI WG)