On 16/12/13 23:49 +0000, Mark McLoughlin wrote:
Hi Thierry,On Fri, 2013-12-13 at 15:53 +0100, Thierry Carrez wrote:Hi everyone, TL;DR: Incubation is getting harder, why not ask efforts to apply for a new program first to get the visibility they need to grow. Long version: Last cycle we introduced the concept of "Programs" to replace the concept of "Official projects" which was no longer working that well for us. This was recognizing the work of existing teams, organized around a common mission, as an integral part of "delivering OpenStack". Contributors to programs become ATCs, so they get to vote in Technical Committee (TC) elections. In return, those teams place themselves under the authority of the TC. This created an interesting corner case. Projects applying for incubation would actually request two concurrent things: be considered a new "Program", and give "incubated" status to a code repository under that program. Over the last months we significantly raised the bar for accepting new projects in incubation, learning from past integration and QA mistakes. The end result is that a number of promising projects applied for incubation but got rejected on maturity, team size, team diversity, or current integration level grounds. At that point I called for some specific label, like "Emerging Technology" that the TC could grant to promising projects that just need more visibility, more collaboration, more crystallization before they can make good candidates to be made part of our integrated releases. However, at the last TC meeting it became apparent we could leverage "Programs" to achieve the same result. Promising efforts would first get their mission, scope and existing results blessed and recognized as something we'd really like to see in OpenStack one day. Then when they are ready, they could have one of their deliveries apply for incubation if that makes sense. The consequences would be that the effort would place itself under the authority of the TC. Their contributors would be ATCs and would vote in TC elections, even if their deliveries never make it to incubation. They would get (some) space at Design Summits. So it's not "free", we still need to be pretty conservative about accepting them, but it's probably manageable. I'm still weighing the consequences, but I think it's globally nicer than introducing another status. As long as the TC feels free to revoke Programs that do not deliver the expected results (or that no longer make sense in the new world order) I think this approach would be fine. Comments, thoughts ?Thanks for writing this up; a few thoughts ... I'm not totally convinced we need such formality around the TC expressing its support for an early-stage program/project/effort/team. How about if we had an RFC process (hmm, but not in the IETF sense) whereby an individual or team can submit a document expressing a position and ask the TC to give its feedback? We would record that feedback in the governance repo, and it would be a short piece of prose (perhaps even recording a diversity of views amongst the TC members) rather than a yes/no status vote. In the case of a fledgling project, they'd write up something like a first draft of an incubation application and we'd give our feedback, encouragement, whatever.
This sounds reasonable. It also sounds like a good way to officially put a TC stamp on an emerging technology before the request for incubation. The benefits I see from this is that: 1. The team working on that project knows there's an interest on the work they're doing and that the project fits into OpenStack 2. They don't have to worry about what program the project fits in, yet. Instead, the team can focus on working towards incubation. 3. The TC will be aware of this emerging technology. Emerging technologies could request 'follow-up' meetings to the TC, or the other way around. (Brainstorming) I still think that emerging / incubated projects shouldn't worry about programs. If they've been tagged as emerging or entered into incubation is because the TC thinks they fit into OpenStack and that should be enough until the project is ready to graduate.
Setting a very low bar for the officialness of becoming a Program seems wrong to me - I wouldn't like to see Programs being added and then later removed with any sort of regularity. Part of what people are looking for is an indication of what's coming down the track and the endorsement implicit in becoming a Program - before a long-term viable team has been established - seems too strong for me. Even though this doesn't grant ATC status to the people working on those projects, I'm struggling to see that as a burning issue for anyone - honestly, if you're working on an early-stage, keen-to-be-incubated project then I'd be surprised if you didn't find some small way to contribute to one of our many ATC-granting projects.
+1 I agree here. One of the requirements for entering incubation is being integrated with some of the OpenStack tools. Encouraging those emerging teams to contribute to the tools they're using is the way to go, IMHO.
One thing I'm noticing that's missing from these new docs: http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements http://git.openstack.org/cgit/openstack/governance/tree/reference/new-programs-requirements is any caution around increasing the scope of OpenStack. I think we are cautious about this, but we haven't mentioned it beyond e.g. ** Project must have a clear and defined scope ** Project should not inadvertently duplicate functionality present in other OpenStack projects. If they do, they should have a clear plan and timeframe to prevent long-term scope duplication. ** Project should leverage existing functionality in other OpenStack projects as much as possible How would something like: ** Project must have a clear and defined scope which, in turn, represents a measured and obvious progression for OpenStack as a whole sound?
+1 Cheers, FF -- @flaper87 Flavio Percoco
pgpIGHvRb2pnl.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
