> > We are discussing adding at least one new project this cycle, and > the specific case of Adjutant has brought up questions about the > criteria we use for evaluating new projects when they apply to > become official. Although the current system does include some > well-defined requirements [1], it was also designed to rely on TC > members to use their judgement in some other areas, to account for > changing circumstances over the life of the project and to reflect > the position that governance is not something we can automate away. >
Good question to get the conversation going Doug. This is an interesting point that I think will require some longer term discussions. It would be nice if we can narrow this down to a more defined decision tree, but I also think it may be too difficult to get to the point where it is something that can be that black and white. For better or worse, I do think there is some subjective evaluation that is required for each of these so far. I think following our four opens is the basis for most decisions. They need to be developing projects in an open way, and open to community involvement with the implementation and direction of the project, as a basic starting point. If they are not willing to follow these basic principles then I think it is an easy decision to not go any further from there. We do care about diversity in contributors. I think it is very important for the long term health of a project to have multiple interests involved. But I do not consider this a bar to entry. I think it is perfectly OK for a new (but open) project to come in with the majority of the work coming from one vendor. As long as they are open and willing to get others involved in the development of the project, then it is good. And at least sometimes, starting off is sometimes better with one perspective driving things toward a focused solution. I think one of the important things is if it fits in to furthering what is "OpenStack", as far as whether it is a service or functionality that is needed and useful for those running an OpenStack cloud. This is one of the parts that may be more on the subjective side. We need to see that adding the new project in question will enhance the use or operation of an OpenStack environment. There is the question about overlap with existing projects. While I think it's true that a new project can come along that meets a need in a better way than an existing solution, I think that bar needs so be raised a lot higher. I personally would much rather see resources joining together on an existing solution than a bunch of resources used to come up with a competing solution. Even with a less than ideal solution, there is a lot that is learned from the process that can be fed into and combined with new ideas to create a better solution than just having a new replacement. There's probably a lot more that can be said about all of this, but that's my initial take. Looking forward to seeing what everyone else has to say and learning from how we are the same and how we are different on this topic. Sean __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
