Open Stack

Jesse Noller wrote:
> [...]
> Given the schism in audiences, it looks like Horizon, this project, a unified CLI project and management of the individual CLI tools would fall under a Consumer / User Experience umbrella. 
> 
> If you look at the governance setup:
> 
> 	http://git.openstack.org/cgit/openstack/governance/commit/
> 
> It seems to make sense that the UX proposal potentially be revived; but have actionable items under 3-4 sub teams:
> 
> 1: Unified SDK / Consumer-Developer tools
> 2: Unified Client tools (CLI)
> 3: Horizon (UI)
> 4: Security
> 5: i18n 

A few remarks...

I agree that the current CLI / developer experience is sub-optimal. From
an organizational perspective, I think we can blame having the client
libraries attached to each corresponding project's program, and having
no clear home for the common client efforts.

So I'd definitely welcome a team working on that, and would also
definitely consider placing the existing client libraries under that
umbrella if that group is willing to maintain them.

But there are two key things to take into account.

(1) Teams should exist first
You can mandate anything you want, in the end if nobody is doing the
work you won't get anywhere. That's why in OpenStack we took the view of
letting teams spontaneously form rather than mandating that they exist,
or rather then having them ask for permission first. A lot of people
have been talking about CLI work in the past, but they never formed a
team. The first step here is to gather the group of people interested in
that topic and self-organize.

(2) Teams scope should match what they work on
There is no point in defining a scope if it doesn't match an existing
team's focus. Yes, from an organizational perspective it makes sense to
have Horizon and CLI folks in the same group, but if those end up being
two separate subgroups working on those two sub-aspects, then two
separate teams make a lot more sense.

In summary, I'd really like we have a team working on unified CLI. But
me saying it won't make it happen. A group of people working on that
will make it happen. That group should form, self-organize, and start
working on stuff. If the overlap between that team and another existing
team is very large, then it will make sense for them to regroup. If not,
they should exist as a separate team. Once that team starts producing
outputs, it can apply to be recognized as an official program (which
would make a lot of sense to me).

-- 
Thierry Carrez (ttx)