Open Stack

On Fri, Nov 21, 2014 at 3:08 AM, Thierry Carrez <thierry at openstack.org>
wrote:

> Hi, fellow TC members,
>
> After a noisy ML thread, opinionated blogposts, and strawmen on Gerrit,
> we are at a stage where we seek potential convergence between TC members
> around a common proposal (before we put it in words and RFC to the wider
> community). This phase started as informal in-person discussions in
> Paris, and we set up TC 5-members hangouts (2 so far) to continue that
> discussion over a high-bandwidth medium. This email summarizes the
> progress so far for everyone to know.
>
> Note that there is little point in commenting on this thread, the
> discussion is still very much at its early stages and we don't know yet
> what the final proposal will be (nor if it will be truly consensual
> amongst the TC members). At this point I prefer we continue to solidify
> it in high-bandwidth discussions between TC members.
>

I know you said there is little point in commenting on this thread, but I
do have one comment to add anyway.

While I am excited to see the TC working towards a collective opinion.
There is one group that I would really like to hear from in this debate,
the ATC community (including stackforge) as a whole.  IMHO TC members and
active community members alike are too close to the problem to see all
perspectives. Furthermore I don't know what the most common opinion(s) is
on project structure reform.

To that end, I would like to propose polling ATC members to get some rough
numbers on where the community as a whole stands on this issue. Based on
the summary below it looks like project structure reform has now been
broken down into several smaller concrete questions, perhaps we can take
those and turn them into a poll. The results of this poll would naturally
be non-binding and only there to help the TC converge on a solution.



>
>
> A. Apparently-consensual points (so far):
>
> A1. A big tent for the "OpenStack Community"
>
> So far we seem to all agree that we need to allow more projects in "the
> OpenStack Community", to allow competition, diversity, and allow
> projects produced by members of our community to truly exist. Projects
> need to be at least vaguely aligned with the OpenStack mission, and
> adhering to the OpenStack way (the 4 opens in a large sense) -- which
> should be objective criteria. Even if we want to allow competition,
> obvious and gratuitous duplicates/forks could be argued to not follow
> the "open development / open design" values, and exceptionally be
> rejected on that account. The TC would keep ultimate ownership of that
> (even if we can delegate most of the checks), and be able to clean up
> dead projects.
>
> A2. Horizontal projects will reset expectations
>
> Horizontal projects (release management, infra, QA...) naturally can't
> be expected to directly handle ALL projects in the big tent. However
> they need to empower all projects by providing general processes, tools
> and advice to everyone. They all need to describe how their work would
> evolve in a bigtent new world order. They may still choose to directly
> handle some projects (think: ensure common synced release for the
> release management, writing the doc itself for documentation) if that
> makes sense and they can handle it.
>
> B. Maybe consensual points:
>
> B1. A tag-based taxonomy to navigate the big tent
>
> It is still the duty of the TC to help downstream consumers of OpenStack
> to understand what each project in the big tent means to them, and have
> a rough idea of its status. The TC would define a number of tags that
> can be applied to projects in the big tent, and the rules to apply them
> (some tags could be set by the TC itself, some others could be delegated
> to other groups). Some tags could be used to answer the Foundation Board
> questions under the bylaws (like defining a set of projects that the
> board can pick from to build a specific trademark license program). But
> most other tags should just facilitate navigating and understanding the
> status of projects in the big tent (like an "translated" tag that the
> I18N team would apply to project with a satisfying degree of
> translations coverage).
>
> C. Non-consensual points:
>
> C1. Special-case a "Compute Group" in the governance
>
> The idea that we should codify an opinionated "Compute Group" and make
> it the focus of the TC activities was consensual in the first group, but
> had strong opponents in the second group. So we need to continue the
> discussion on that one to see if TC consensus can be reached. I guess we
> can't prevent some TC members to care more about a fundamental set of
> projects, but do we need to carve it in stone in our charter ? Wouldn't
> the taxonomy be enough to cover the "foundational" aspect of certain
> projects (Keystone is obviously foundational, but do we need to
> special-case it in our project structure itself?)
>
>
> PS1: We haven't reached out to all TC members yet, and we still need to
> figure out how to handle some limited resources in a bigtent world, so
> this is still very much WIP. Personally I'm working on proposals on how
> to cover design summit space and trademark checks in a bigtent world,
> and I think we can find a solution there as well.
>
> PS2: We used WebRTC for the second "hangout" and it worked quite well
> (and my internet connection is not that fast). I think it would be worth
> exploring how we could host such a video meeting open source hub under
> OpenStack Infrastructure directly.
>
> Raw notes of the hangout meetings:
> https://etherpad.openstack.org/p/project-restructure-hangouts
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20141121/96489028/attachment.html>