Open Stack

On Nov 20, 2013, at 10:27 AM, Thierry Carrez <thierry at openstack.org> wrote:

> Anne Gentle wrote:
>> It's nigh-impossible with the UX resources there now (four core) for
>> them to attend all the project meetings with an eye to UX. Docs are in a
>> similar situation. We also want docs to be present in every project.
>> Docs as a program makes sense, and to me, UX as a program makes sense as
>> well. The UX program can then prioritize what to focus on with the
>> resources they have. 
> 
> The key difference between docs and UX is that documentation is a
> separate deliverable, and is reviewed by the docs core team. UX work
> ends up in each project's code, and gets reviewed by the project's core
> team, not the UX team.
> 
> Blessing a separate team with no connection with the project core team
> is imho a recipe for disaster, potentially with tension between a team
> that recommends work to be done and a team that needs to actually get
> the work coded, reviewed and merged.
> 
> That's why I see UX more like security or scalability, than like
> documentation. A design goal rather than a deliverable. And design goals
> need to be baked in the team that ends up writing and reviewing the
> code. Making it separate will just make it less efficient.

What if “the UX” team was not focused on dictating standards; but rather outlining them and then directly working with the individual teams to actually do the work? This is something I’ve been actually thinking about heavily and planned on typing up a proposal on, primarily focused on SDK / API / CLI consistency and developer experience.

This is something near and dear to my heart - I’ve actually been talking to Doug Hellmann and others about this and trying to find a balance between the competing forces you describe: I don’t think a stand alone team that doesn’t write the actual code/backend in conjunction with the individual projects can work; but I do feel there needs to be a unified vision and common plan held together by a team focused on this subject.

So in *my* ideal world: the “ux” team for this would be a mixture of individual project members, people solely focused on this but writing code *and* specifications and generally working across teams.

Jesse