Re: [openstack-dev] [tc] campaign question related to new projects
On 2018-04-24 09:59:57 -0400 (-0400), Zane Bitter wrote: [...] > the PTG has limited attendance from operators [...] I have high hopes that will not be the case for the next PTG. -- Jeremy Stanley signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
On 24/04/18 05:55, Thierry Carrez wrote: Zane Bitter wrote: [...] I would love to see us have a conversation as a community to figure out what we all, collectively, think that list should look like and document it. Ideally new projects shouldn't have to wait until they've applied to join OpenStack to get a sense of whether we believe they're furthering our mission or not. I agree that we are not really (collectively) taking a step back and looking at the big picture. Forcing myself to work on a map over the past year really helped me reframe how I perceive OpenStack, and I think we should do that sort of exercise more often. What do you think should be the right forum for continuing that discussion? Is that something you think we should discuss at the Forum[tm] ? Or more as an asynchronous discussion at the TC level ? I think we need the widest audience possible, so if I had to pick one forum I would tend toward an asynchronous discussions e.g. on the mailing list. The Forum has limited attendance from developers, the PTG has limited attendance from operators, and both of those offer the opportunity for only a comparatively small number of people to speak, so I don't recommend that we try to have the discussion primarily in-person. It probably doesn't hurt to try to discuss it whenever we can with literally anybody who will listen though :) cheers, Zane. __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
Zane Bitter wrote: > [...] > I would love to see us have a conversation as a community to figure out > what we all, collectively, think that list should look like and document > it. Ideally new projects shouldn't have to wait until they've applied to > join OpenStack to get a sense of whether we believe they're furthering > our mission or not. I agree that we are not really (collectively) taking a step back and looking at the big picture. Forcing myself to work on a map over the past year really helped me reframe how I perceive OpenStack, and I think we should do that sort of exercise more often. What do you think should be the right forum for continuing that discussion? Is that something you think we should discuss at the Forum[tm] ? Or more as an asynchronous discussion at the TC level ? -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
2018-04-23 22:43 GMT+08:00 Doug Hellmann : > > Excerpts from Rico Lin's message of 2018-04-22 16:50:51 +0800: > > Thanks, Doug, for raising this campaign question > > > > > > Here are my answers: > > > > > > ***How you would evaluate a project's application in general > > > > First I would work through the requirements ([1]) to evaluate projects. > > Since most of the requirements are specific enough. And here's more > > important part, to leave evaluate logs or comments for projects which we > > considered but didn't reach some requirements. It's very important to guide > > projects to cross over requirements (and remember, a `-1` only means we > > trying to help). > > > > Then, I work on questions, like: > > > > `How many user are interesting to/needs the functionality that service > > provided?` > > > > `How active is this project and how's the diversity of contributors?` > > Our current policy is to allow projects with contributors from a small > number of affiliations (even a single employer), under the theory that > bringing a team into the community officially will help them grow by > showing them the benefits of being more diverse and by making it easier > for other community members who have employer restrictions on their open > source work to justify contributing. > > Would you change that policy in any way? I'm fine with the number of developers involved in the project. we should encourage people working on any crazy ideas. But the point is `is that developer active? and will he/she helps others to join that projects or just waiting for others?`. If we can try to put such requirement in policy will be better IMO. Otherwise, we can keep the policy but the diversity of developers might help to reduce chances of that risk. > > > > > `Is this project required cross communities/projects cooperation? If yes, > > how's the development workflows are working between communities/projects?` > > > > And last but is one of the most important questions, > > > > `Is this service aligns with the OpenStack Mission`? (and let's jump to > > next question to answer this part) > > > > > > > > **What sorts of things do you consider when deciding whether a project > > "aligns with the OpenStack Mission," for example?* > > > > I would consider things like: > > > > `Is the project's functionality complete the OpenStack infrastructure map?` > > > > Asking from user requirement and functionality point of view, `how's the > > project(services) will make OpenStack better infrastructure for > > user/operators?` and `how's this functionality provide a better life for > > OpenStack developers?` > > > > `Is the project provides better integration point between communities` > > > > To build a better infrastructure, IMO it's also important to ask if a > > project (service) really help on integration with other communities like > > Kubernetes, OPNFV, CEPH, etc. I think to keep us as an active > > infrastructure to solutions is part of our mission too. > > > > `Is it providing functionality which we can integrate with current projects > > or SIG instead?` > > > > In short, we should be gathering our development energy, to really achieve > > the jobs which is exactly why we spend times on trying to find official > > projects and said this is part of our mission to work on. So when new > > projects jump out, it's really important to discuss cross-project `is it > > suitable for projects integrated and join force on specific functionality?` > > (to do this while evaluating a project instead of when it's creating might > > not be the best time to said `please integrate or join forces with other > > teams together`(not even with a smiling face), but it's never too late for > > a non-official/incubating project to consider about this). I really don't > > like to to see any project get higher chances to die just because > > developers chance their developing focus. It's happening when projects are > > all willing to do the functionality, but no communication between(some > > cases, not even now other projects exists), and new/old projects dead, then > > TC needs to spend the time to pick those projects out. So IMO, it's worth > > to spend times to investigate on whether projects can be joined. Or ideally > > to put a resolution said, it's project's obligation to help on this, and > > help other join force to be part of the team. > > Please see my other question about projects with overlapping feature > sets [1]. Done:) > > Doug > > [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html > > > > > `Can projects provide cross-project gating?` > > > > Do think if it's possible, we should consider this when asking if a service > > aligns with our mission because not breaking rest of infrastructure is part > > of the definition of `to build`. And providing cross-project gate jobs > > seems like a way to go. To stable the integration between projects and > > prevent released a failed feature when other services trying to
Re: [openstack-dev] [tc] campaign question related to new projects
On 23/04/18 18:14, Doug Hellmann wrote: > Excerpts from Graham Hayes's message of 2018-04-23 17:23:20 +0100: >> On 23/04/18 17:14, Doug Hellmann wrote: >>> Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100: On 23/04/18 16:04, Doug Hellmann wrote: > Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100: >> 7On 20/04/18 22:26, Doug Hellmann wrote: >> >>> Without letting the conversation devolve too much into a discussion >>> of Adjutant's case, please talk a little about how you would evaluate >>> a project's application in general. What sorts of things do you >>> consider when deciding whether a project "aligns with the OpenStack >>> Mission," for example? >>> >>> Doug >>> >> >> For me, the most important thing for a project that wants to join is >> that they act like "one of us" - what I think ttx refered to as "culture >> fit". >> >> This is fairly wide ranging, but includes things like: >> >> * Do they use the PTIs[0] >> * Do they use gerrit, or if they use something else, do they follow >> the same review styles and mechanisms? >> * Are they on IRC? >> * Do they use the mailing list for long running discussion? >> ** If a project doesn't have long running discussions and as a result >> does not have ML activity, I would see that as OK - my problem >> would be with a team that ran their own list. >> * Do they use standard devstack / -infra jobs for testing? >> * Do they use the standard common libraries (where appropriate)? >> >> If a project fails this test (and would have been accepted as something >> that drives the mission), I see no issue with the TC trying to bring >> them into the fold by helping them work like one of us, and accepting >> them when they have shown that they are willing to change how they >> do things. >> >> For the "product" fit, it is a lot more subjective. We used to have a >> system (pre Big Tent) where the TC picked "winners" in a space and >> blessed one project as the way to do $thing. Then, in big tent we >> started to not pick winners, and allow anyone who was one of us, and >> had a "cloud" application. >> >> Recently, we have moved back to seeing if a project overlaps with >> another. The real test for this (from my viewpoint) is if the >> perceived overlap is an area that the team that is currently in >> OpenStack is interested in pursuing - if not we should default to >> adding the project. > > We've always considered overlap to some degree, but it has come up > more explicitly in a few recent discussions because of the nature > of the projects. Please see the other thread on this topic [1]. > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html > >> Personally, if the project adds something that we currently lack, >> and have lacked for a long time (not to get too close to the current >> discussion), or tries to reduce the amount of extra tooling that >> deployers currently write in house, we should welcome them. >> >> The acid test for me is "How would I use this?" or "Have I written >> tooling or worked somewhere that wrote tooling to do this?" >> >> If the answer is yes, it is a good indication that they fit with the >> mission. > > This feels like the ideal open source approach, in which contributors > are "scratching their own itch." How can we encourage more deployers > and users of OpenStack to consider contributing their customization > and integration projects? Should we? I think a lot of our major users are good citizens and are doing some or all of this work in the open - we just have a discoverability issue. A lot of the benefit of joining the foundation as a project, is the increased visibility gained from it, so that others who are deploying OpenStack in a similar layout can find a project and use it. I think at the very least we should find a way to promote them (this is where constellations could really help, as we could add non member projects to constellations where they are appropriate. >>> >>> Do you foresee any issues with adding unofficial projects to the >>> constellations? >>> >>> Doug >> >> No (from my viewpoint anyway) - I think they will be important to >> include in any true collection of use cases - for example we definitely >> will want to have a "PaaS" Constellation that includes things like >> Kubernetes, Cloud Foundry and / or OpenShift. We need to show how >> OpenStack works in the entire open source infrastructure community >> and not just how it works internally - and showing how you can use other >> open source software components *with* OpenStack is vital for that. > > Would you make a distinction between things that have th
Re: [openstack-dev] [tc] campaign question related to new projects
On 2018-04-23 13:14:59 -0400 (-0400), Doug Hellmann wrote: [...] > I hope that no one considers any of this "noise," so thank you for > highlighting that point. Oh, yes I didn't mean to imply that any of the responses so far have been noise, but I was walking a thin line on it being a hollow sort of "me too" reply. I have added this as one of my suggested bullet points for proposed forum discussion http://forumtopics.openstack.org/cfp/details/122 as well. -- Jeremy Stanley signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
Excerpts from Jeremy Stanley's message of 2018-04-23 17:02:07 +: > On 2018-04-23 12:02:14 -0400 (-0400), Zane Bitter wrote: > [...] > > The main thing I will be looking out for in those cases is that > > the project followed the Four Opens *from the beginning*. Projects > > that start from a code dump are much less likely to attract other > > contributors in my view. Open Source is not a verb. > [...] > > Not to add more noise, but I wanted to mention that I _really_ like > this point in particular. We've definitely seen plenty of > applications for inclusion which started out as an > internally-developed tool behind closed doors somewhere. When they > get "flung over the wall" to the community they tend to flounder in > their attempts to gain traction as properly open projects in their > own right. I don't think we do a good enough job at highlighting > this risk (yet), and will remember to point it out more often when I > spot it in the future. Thanks! I hope that no one considers any of this "noise," so thank you for highlighting that point. Doug __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
Excerpts from Graham Hayes's message of 2018-04-23 17:23:20 +0100: > On 23/04/18 17:14, Doug Hellmann wrote: > > Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100: > >> On 23/04/18 16:04, Doug Hellmann wrote: > >>> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100: > 7On 20/04/18 22:26, Doug Hellmann wrote: > > > Without letting the conversation devolve too much into a discussion > > of Adjutant's case, please talk a little about how you would evaluate > > a project's application in general. What sorts of things do you > > consider when deciding whether a project "aligns with the OpenStack > > Mission," for example? > > > > Doug > > > > For me, the most important thing for a project that wants to join is > that they act like "one of us" - what I think ttx refered to as "culture > fit". > > This is fairly wide ranging, but includes things like: > > * Do they use the PTIs[0] > * Do they use gerrit, or if they use something else, do they follow > the same review styles and mechanisms? > * Are they on IRC? > * Do they use the mailing list for long running discussion? > ** If a project doesn't have long running discussions and as a result > does not have ML activity, I would see that as OK - my problem > would be with a team that ran their own list. > * Do they use standard devstack / -infra jobs for testing? > * Do they use the standard common libraries (where appropriate)? > > If a project fails this test (and would have been accepted as something > that drives the mission), I see no issue with the TC trying to bring > them into the fold by helping them work like one of us, and accepting > them when they have shown that they are willing to change how they > do things. > > For the "product" fit, it is a lot more subjective. We used to have a > system (pre Big Tent) where the TC picked "winners" in a space and > blessed one project as the way to do $thing. Then, in big tent we > started to not pick winners, and allow anyone who was one of us, and > had a "cloud" application. > > Recently, we have moved back to seeing if a project overlaps with > another. The real test for this (from my viewpoint) is if the > perceived overlap is an area that the team that is currently in > OpenStack is interested in pursuing - if not we should default to > adding the project. > >>> > >>> We've always considered overlap to some degree, but it has come up > >>> more explicitly in a few recent discussions because of the nature > >>> of the projects. Please see the other thread on this topic [1]. > >>> > >>> [1] > >>> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html > >>> > Personally, if the project adds something that we currently lack, > and have lacked for a long time (not to get too close to the current > discussion), or tries to reduce the amount of extra tooling that > deployers currently write in house, we should welcome them. > > The acid test for me is "How would I use this?" or "Have I written > tooling or worked somewhere that wrote tooling to do this?" > > If the answer is yes, it is a good indication that they fit with the > mission. > >>> > >>> This feels like the ideal open source approach, in which contributors > >>> are "scratching their own itch." How can we encourage more deployers > >>> and users of OpenStack to consider contributing their customization > >>> and integration projects? Should we? > >> > >> I think a lot of our major users are good citizens and are doing some or > >> all of this work in the open - we just have a discoverability issue. > >> > >> A lot of the benefit of joining the foundation as a project, is the > >> increased visibility gained from it, so that others who are deploying > >> OpenStack in a similar layout can find a project and use it. > >> > >> I think at the very least we should find a way to promote them (this > >> is where constellations could really help, as we could add non member > >> projects to constellations where they are appropriate. > > > > Do you foresee any issues with adding unofficial projects to the > > constellations? > > > > Doug > > No (from my viewpoint anyway) - I think they will be important to > include in any true collection of use cases - for example we definitely > will want to have a "PaaS" Constellation that includes things like > Kubernetes, Cloud Foundry and / or OpenShift. We need to show how > OpenStack works in the entire open source infrastructure community > and not just how it works internally - and showing how you can use other > open source software components *with* OpenStack is vital for that. Would you make a distinction between things that have their own community like kubernetes, and things that mig
Re: [openstack-dev] [tc] campaign question related to new projects
On Mon, 23 Apr 2018, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2018-04-23 12:09:42 +0100: I'd like to see us work harder to refine the long term goals we are trying to satisfy with the projects that make up OpenStack. This will require us to continue the never-ending discussion about whether OpenStack is a "Software Defined Infrastructure Framework" or a "Cloud Solution" (plenty of people talk the latter, but plenty of other people are spending energy on the former). And then Do you consider those two approaches to be mutually exclusive? No, but I do think how we balance and think about them them helps us understand how to make progress. In the past our community has had trouble defining "infrastructure" in a way that satisfies everyone. Some people stop at "allocating what you need to run a VM" while others consider it closer to "everything you need to run an application". How do you define "infrastructure"? In this context I'm thinking of infrastructure in terms of plumbing, using the plumbing and porcelain metaphor sometimes associted with git: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain So in your terms "allocating what you need to run a VM" but with some tweaks. In Zane's response on this topic, he talks a lot about the applications that are using the "cloud" and some of the additional tooling that is needed to satisfy that (some of which might be considered porcelain). Since my introduction to OpenStack that's what I've hoped we are trying to build. An Open Source "Cloud Solution" that enables a healthy application environment that is a clear and complete alternative to the big three clouds. However, over the years it has become increasingly evident that a great deal of our energy is spent working at a different angle to enable software defined data centers (including data centers that are decomposed to the edge) that are hyper-aware of hardware and networks and making that hardware available in the most cost effective way possible. That's a useful thing to do but our attention to it is not well aligned with building elastic web services. (In this particular case I'm speaking from experience perhaps overly informed by Nova, where so much work is devoted to NFV-related use cases. To such extent that people joke about hardware defined software.) While I don't think we need to say that we are doing one thing or the other, we may make some decisions easier by being more willing to identify which domain or perspective we are thinking about in any given decision. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ 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
Re: [openstack-dev] [tc] campaign question related to new projects
On 2018-04-23 12:02:14 -0400 (-0400), Zane Bitter wrote: [...] > The main thing I will be looking out for in those cases is that > the project followed the Four Opens *from the beginning*. Projects > that start from a code dump are much less likely to attract other > contributors in my view. Open Source is not a verb. [...] Not to add more noise, but I wanted to mention that I _really_ like this point in particular. We've definitely seen plenty of applications for inclusion which started out as an internally-developed tool behind closed doors somewhere. When they get "flung over the wall" to the community they tend to flounder in their attempts to gain traction as properly open projects in their own right. I don't think we do a good enough job at highlighting this risk (yet), and will remember to point it out more often when I spot it in the future. Thanks! -- Jeremy Stanley signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
On 23/04/18 17:14, Doug Hellmann wrote: > Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100: >> On 23/04/18 16:04, Doug Hellmann wrote: >>> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100: 7On 20/04/18 22:26, Doug Hellmann wrote: > Without letting the conversation devolve too much into a discussion > of Adjutant's case, please talk a little about how you would evaluate > a project's application in general. What sorts of things do you > consider when deciding whether a project "aligns with the OpenStack > Mission," for example? > > Doug > For me, the most important thing for a project that wants to join is that they act like "one of us" - what I think ttx refered to as "culture fit". This is fairly wide ranging, but includes things like: * Do they use the PTIs[0] * Do they use gerrit, or if they use something else, do they follow the same review styles and mechanisms? * Are they on IRC? * Do they use the mailing list for long running discussion? ** If a project doesn't have long running discussions and as a result does not have ML activity, I would see that as OK - my problem would be with a team that ran their own list. * Do they use standard devstack / -infra jobs for testing? * Do they use the standard common libraries (where appropriate)? If a project fails this test (and would have been accepted as something that drives the mission), I see no issue with the TC trying to bring them into the fold by helping them work like one of us, and accepting them when they have shown that they are willing to change how they do things. For the "product" fit, it is a lot more subjective. We used to have a system (pre Big Tent) where the TC picked "winners" in a space and blessed one project as the way to do $thing. Then, in big tent we started to not pick winners, and allow anyone who was one of us, and had a "cloud" application. Recently, we have moved back to seeing if a project overlaps with another. The real test for this (from my viewpoint) is if the perceived overlap is an area that the team that is currently in OpenStack is interested in pursuing - if not we should default to adding the project. >>> >>> We've always considered overlap to some degree, but it has come up >>> more explicitly in a few recent discussions because of the nature >>> of the projects. Please see the other thread on this topic [1]. >>> >>> [1] >>> http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html >>> Personally, if the project adds something that we currently lack, and have lacked for a long time (not to get too close to the current discussion), or tries to reduce the amount of extra tooling that deployers currently write in house, we should welcome them. The acid test for me is "How would I use this?" or "Have I written tooling or worked somewhere that wrote tooling to do this?" If the answer is yes, it is a good indication that they fit with the mission. >>> >>> This feels like the ideal open source approach, in which contributors >>> are "scratching their own itch." How can we encourage more deployers >>> and users of OpenStack to consider contributing their customization >>> and integration projects? Should we? >> >> I think a lot of our major users are good citizens and are doing some or >> all of this work in the open - we just have a discoverability issue. >> >> A lot of the benefit of joining the foundation as a project, is the >> increased visibility gained from it, so that others who are deploying >> OpenStack in a similar layout can find a project and use it. >> >> I think at the very least we should find a way to promote them (this >> is where constellations could really help, as we could add non member >> projects to constellations where they are appropriate. > > Do you foresee any issues with adding unofficial projects to the > constellations? > > Doug No (from my viewpoint anyway) - I think they will be important to include in any true collection of use cases - for example we definitely will want to have a "PaaS" Constellation that includes things like Kubernetes, Cloud Foundry and / or OpenShift. We need to show how OpenStack works in the entire open source infrastructure community and not just how it works internally - and showing how you can use other open source software components *with* OpenStack is vital for that. - Graham >> >>> Doug >>> - Graham 0 - https://governance.openstack.org/tc/reference/project-testing-interface.html >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >
Re: [openstack-dev] [tc] campaign question related to new projects
Doug Hellmann wrote: > Excerpts from Thierry Carrez's message of 2018-04-22 15:10:40 +0200: >> For the product fit, there is also a lot of room for interpretation. For >> me it boils down to whether "OpenStack" (the product) is better with >> that project "in" rather than with that project "out". Sometimes it's an >> easy sell: if a group wants to collaborate on packaging OpenStack for a >> certain format/distro/deployment tool, it's clearly a win. In that case>> >> more is always better. But in most cases it's not as straightforward. >> There is always tension between added functionality on one side, and >> complexity / dilution / confusion on the other. Every "service" project >> we add makes OpenStack more complex to explain, cross-project work more >> difficult and interoperability incrementally harder. Whatever is added >> has to be damn interesting to counterbalance that. The same goes for > > Why do you think OpenStack has more trouble explaining our feature set > than other cloud systems that have a similarly diverse array of > features? You mean compared to AWS ? It's not the same thing to explain a set of APIs to end users of the cloud and to describe available components to the deployers of the cloud, especially newcomers. For example, Zun API users don't have to know if it relies on Heat, Magnum or Nova to actually do its magic behind the scenes. A Zun deployer absolutely needs to know that. I hope that the Constellation concept will help the latter traverse our product map more efficiently. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100: > On 23/04/18 16:04, Doug Hellmann wrote: > > Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100: > >> 7On 20/04/18 22:26, Doug Hellmann wrote: > >> > >>> Without letting the conversation devolve too much into a discussion > >>> of Adjutant's case, please talk a little about how you would evaluate > >>> a project's application in general. What sorts of things do you > >>> consider when deciding whether a project "aligns with the OpenStack > >>> Mission," for example? > >>> > >>> Doug > >>> > >> > >> For me, the most important thing for a project that wants to join is > >> that they act like "one of us" - what I think ttx refered to as "culture > >> fit". > >> > >> This is fairly wide ranging, but includes things like: > >> > >> * Do they use the PTIs[0] > >> * Do they use gerrit, or if they use something else, do they follow > >> the same review styles and mechanisms? > >> * Are they on IRC? > >> * Do they use the mailing list for long running discussion? > >> ** If a project doesn't have long running discussions and as a result > >> does not have ML activity, I would see that as OK - my problem > >> would be with a team that ran their own list. > >> * Do they use standard devstack / -infra jobs for testing? > >> * Do they use the standard common libraries (where appropriate)? > >> > >> If a project fails this test (and would have been accepted as something > >> that drives the mission), I see no issue with the TC trying to bring > >> them into the fold by helping them work like one of us, and accepting > >> them when they have shown that they are willing to change how they > >> do things. > >> > >> For the "product" fit, it is a lot more subjective. We used to have a > >> system (pre Big Tent) where the TC picked "winners" in a space and > >> blessed one project as the way to do $thing. Then, in big tent we > >> started to not pick winners, and allow anyone who was one of us, and > >> had a "cloud" application. > >> > >> Recently, we have moved back to seeing if a project overlaps with > >> another. The real test for this (from my viewpoint) is if the > >> perceived overlap is an area that the team that is currently in > >> OpenStack is interested in pursuing - if not we should default to > >> adding the project. > > > > We've always considered overlap to some degree, but it has come up > > more explicitly in a few recent discussions because of the nature > > of the projects. Please see the other thread on this topic [1]. > > > > [1] > > http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html > > > >> Personally, if the project adds something that we currently lack, > >> and have lacked for a long time (not to get too close to the current > >> discussion), or tries to reduce the amount of extra tooling that > >> deployers currently write in house, we should welcome them. > >> > >> The acid test for me is "How would I use this?" or "Have I written > >> tooling or worked somewhere that wrote tooling to do this?" > >> > >> If the answer is yes, it is a good indication that they fit with the > >> mission. > > > > This feels like the ideal open source approach, in which contributors > > are "scratching their own itch." How can we encourage more deployers > > and users of OpenStack to consider contributing their customization > > and integration projects? Should we? > > I think a lot of our major users are good citizens and are doing some or > all of this work in the open - we just have a discoverability issue. > > A lot of the benefit of joining the foundation as a project, is the > increased visibility gained from it, so that others who are deploying > OpenStack in a similar layout can find a project and use it. > > I think at the very least we should find a way to promote them (this > is where constellations could really help, as we could add non member > projects to constellations where they are appropriate. Do you foresee any issues with adding unofficial projects to the constellations? Doug > > > Doug > > > >> > >> - Graham > >> > >> 0 - > >> https://governance.openstack.org/tc/reference/project-testing-interface.html > > > > __ > > 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 > > __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
On 20/04/18 17:26, Doug Hellmann wrote: [This is meant to be one of (I hope) several conversation-provoking questions directed at prospective TC members to help the community understand their positions before considering how to vote in the ongoing election.] Thanks Doug, I think this is a really helpful question. 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. Without letting the conversation devolve too much into a discussion of Adjutant's case, please talk a little about how you would evaluate a project's application in general. What sorts of things do you consider when deciding whether a project "aligns with the OpenStack Mission," for example? Doug [1] https://governance.openstack.org/tc/reference/new-projects-requirements.html The first thing to mention is that I take a fairly expansive view of what IaaS comprises. (For example, I think a message queue like Zaqar is a critical component of an IaaS, which often surprises people, but how can an application use its infrastructure as a server without notifications about what's going on in the infrastructure? I guess we could try to optimise for polling in a thousand different places, but it's much simpler to expose events in one place and optimising polling of that.) A while back[1] I threw together a non-exhaustive list of the kinds of goals I think OpenStack should be working towards: * Infinite scaling - the ability in principle to scale from zero to an arbitrarily large number of users without rewriting your application (e.g. if your application can store one file in Swift then there's no theoretical limit to how many it can store. c.f. Cinder where at some point you'd have to start juggling multiple volumes.) * Granularity of allocation - pay only for the resources you actually use, rather than to allocate a chunk that you may or may not be using (so Nova->containers->FaaS, Cinder->Swift, Trove->??? [RIP MagnetoDB], &c.) * Full control of infrastructure - notwithstanding the above, maintain Nova/Cinder/Neutron/Trove/&c. so that legacy applications, highly specialised applications, and higher-level services like PaaS can make fully customised use of the virtual infrastructure. * Hardware virtualisation - make anything that might typically be done in hardware available in a multi-tenant software-defined environment: servers, routers, load balancers, firewalls, video codecs, GPGPUs, FPGAs... * Built-in reliability - don't require even the smallest apps to have 3 VMs + a cluster manager to enforce any reliability guarantees; provide those guarantees using multi-tenant services that efficiently share resources between applications (see also: Infinite scaling, Granularity of allocation). * Application control - (securely) give applications control over their own infrastructure, so that no part of the application needs to reside outside of the cloud. * Integration - cloud services that effectively form part of the user's application can communicate amongst themselves, where appropriate, without the need for client-side glue (see also: Built-in reliability). * Interoperability - the same applications can be deployed on a variety of private and public OpenStack clouds. I'm definitely not claiming to have captured the full range of possibilities there (notably it doesn't attempt to cover e.g. deployment-related projects), but at a minimum any project contributing to one or more of those points is something I would consider to be aligned with OpenStack's mission. (That, of course, is only one of several criteria that are considered.) I would love to see us have a conversation as a community to figure out what we all, collectively, think that list should look like and document it. Ideally new projects shouldn't have to wait until they've applied to join OpenStack to get a sense of whether we believe they're furthering our mission or not. To be clear, although I don't expect it to come up, something like a PaaS (think CloudFoundry, or OpenShift) would be *not* be in-scope for OpenStack in my view. (We should definitely to encourage them to integrate with Keystone anyway though!) One thing I think the TC needs to be wary of is that at this stage of maturity there may be a temptation to engage in a sort of 'regulatory arbitrage': to try to land your pet feature wherever it's easiest to get it accepted, rather than where it makes the most technical sense. Indulging that temptation works against interoperability, which is a critica
Re: [openstack-dev] [tc] campaign question related to new projects
> > > > 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. > > What do you think we can do to be better informed about whether > something is actually useful, or just appears useful? > This is definitely a tricky part. We need to be willing to get out and make connections outside of our small group and learn what we can about how things are used in the real world. This is one of the main reasons I've been involved in the ops meetups. I want to be able to hear directly from the folks running OpenStack clouds what their challenges are and how they are addressing those challenges today. That helps inform later decisions about whether some new service fits in with what they need, or if it would be something that doesn't actually fit with what is commonly done. > > > > 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. > > Where should we draw the line with building something new and using > tools available from other communities? > Fighting "not invented here" tendencies is always a challenge. There's usually no clear line with these things from my experience. I think we need to be willing to take a look at what something is trying to solve, and able to take a look around and see if there is already something solving it, or doing something close enough to be easily adapted to fit our specific usage. Even if there is a potential existing tool available, we also need to evaluate whether that tools technology (programming language, platform, etc) fit and whether its community is compatible enough with our. For example, are they willing to work with outside consumers like us that may have some different needs than their current user base? Are they an open community and not a vendor of a proprietary tool? __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
On 23/04/18 16:04, Doug Hellmann wrote: > Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100: >> 7On 20/04/18 22:26, Doug Hellmann wrote: >> >>> Without letting the conversation devolve too much into a discussion >>> of Adjutant's case, please talk a little about how you would evaluate >>> a project's application in general. What sorts of things do you >>> consider when deciding whether a project "aligns with the OpenStack >>> Mission," for example? >>> >>> Doug >>> >> >> For me, the most important thing for a project that wants to join is >> that they act like "one of us" - what I think ttx refered to as "culture >> fit". >> >> This is fairly wide ranging, but includes things like: >> >> * Do they use the PTIs[0] >> * Do they use gerrit, or if they use something else, do they follow >> the same review styles and mechanisms? >> * Are they on IRC? >> * Do they use the mailing list for long running discussion? >> ** If a project doesn't have long running discussions and as a result >> does not have ML activity, I would see that as OK - my problem >> would be with a team that ran their own list. >> * Do they use standard devstack / -infra jobs for testing? >> * Do they use the standard common libraries (where appropriate)? >> >> If a project fails this test (and would have been accepted as something >> that drives the mission), I see no issue with the TC trying to bring >> them into the fold by helping them work like one of us, and accepting >> them when they have shown that they are willing to change how they >> do things. >> >> For the "product" fit, it is a lot more subjective. We used to have a >> system (pre Big Tent) where the TC picked "winners" in a space and >> blessed one project as the way to do $thing. Then, in big tent we >> started to not pick winners, and allow anyone who was one of us, and >> had a "cloud" application. >> >> Recently, we have moved back to seeing if a project overlaps with >> another. The real test for this (from my viewpoint) is if the >> perceived overlap is an area that the team that is currently in >> OpenStack is interested in pursuing - if not we should default to >> adding the project. > > We've always considered overlap to some degree, but it has come up > more explicitly in a few recent discussions because of the nature > of the projects. Please see the other thread on this topic [1]. > > [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html > >> Personally, if the project adds something that we currently lack, >> and have lacked for a long time (not to get too close to the current >> discussion), or tries to reduce the amount of extra tooling that >> deployers currently write in house, we should welcome them. >> >> The acid test for me is "How would I use this?" or "Have I written >> tooling or worked somewhere that wrote tooling to do this?" >> >> If the answer is yes, it is a good indication that they fit with the >> mission. > > This feels like the ideal open source approach, in which contributors > are "scratching their own itch." How can we encourage more deployers > and users of OpenStack to consider contributing their customization > and integration projects? Should we? I think a lot of our major users are good citizens and are doing some or all of this work in the open - we just have a discoverability issue. A lot of the benefit of joining the foundation as a project, is the increased visibility gained from it, so that others who are deploying OpenStack in a similar layout can find a project and use it. I think at the very least we should find a way to promote them (this is where constellations could really help, as we could add non member projects to constellations where they are appropriate. > Doug > >> >> - Graham >> >> 0 - >> https://governance.openstack.org/tc/reference/project-testing-interface.html > > __ > 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 > signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100: > 7On 20/04/18 22:26, Doug Hellmann wrote: > > > Without letting the conversation devolve too much into a discussion > > of Adjutant's case, please talk a little about how you would evaluate > > a project's application in general. What sorts of things do you > > consider when deciding whether a project "aligns with the OpenStack > > Mission," for example? > > > > Doug > > > > For me, the most important thing for a project that wants to join is > that they act like "one of us" - what I think ttx refered to as "culture > fit". > > This is fairly wide ranging, but includes things like: > > * Do they use the PTIs[0] > * Do they use gerrit, or if they use something else, do they follow > the same review styles and mechanisms? > * Are they on IRC? > * Do they use the mailing list for long running discussion? > ** If a project doesn't have long running discussions and as a result > does not have ML activity, I would see that as OK - my problem > would be with a team that ran their own list. > * Do they use standard devstack / -infra jobs for testing? > * Do they use the standard common libraries (where appropriate)? > > If a project fails this test (and would have been accepted as something > that drives the mission), I see no issue with the TC trying to bring > them into the fold by helping them work like one of us, and accepting > them when they have shown that they are willing to change how they > do things. > > For the "product" fit, it is a lot more subjective. We used to have a > system (pre Big Tent) where the TC picked "winners" in a space and > blessed one project as the way to do $thing. Then, in big tent we > started to not pick winners, and allow anyone who was one of us, and > had a "cloud" application. > > Recently, we have moved back to seeing if a project overlaps with > another. The real test for this (from my viewpoint) is if the > perceived overlap is an area that the team that is currently in > OpenStack is interested in pursuing - if not we should default to > adding the project. We've always considered overlap to some degree, but it has come up more explicitly in a few recent discussions because of the nature of the projects. Please see the other thread on this topic [1]. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html > Personally, if the project adds something that we currently lack, > and have lacked for a long time (not to get too close to the current > discussion), or tries to reduce the amount of extra tooling that > deployers currently write in house, we should welcome them. > > The acid test for me is "How would I use this?" or "Have I written > tooling or worked somewhere that wrote tooling to do this?" > > If the answer is yes, it is a good indication that they fit with the > mission. This feels like the ideal open source approach, in which contributors are "scratching their own itch." How can we encourage more deployers and users of OpenStack to consider contributing their customization and integration projects? Should we? Doug > > - Graham > > 0 - > https://governance.openstack.org/tc/reference/project-testing-interface.html __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
Excerpts from Chris Dent's message of 2018-04-23 12:09:42 +0100: > On Fri, 20 Apr 2018, Doug Hellmann wrote: > > > [This is meant to be one of (I hope) several conversation-provoking > > questions directed at prospective TC members to help the community > > understand their positions before considering how to vote in the > > ongoing election.] > > Thanks for getting the ball rolling on some discussion, Doug. > > > Without letting the conversation devolve too much into a discussion > > of Adjutant's case, please talk a little about how you would evaluate > > a project's application in general. What sorts of things do you > > consider when deciding whether a project "aligns with the OpenStack > > Mission," for example? > > This is an important question because project applications are one > of the few ways in which the TC exercises any direct influence over > the shape and direction of OpenStack. Much of the rest of the time > the TC's influence is either indirect or limited. That's something I > think we should change, in part because I feel the role of the TC > should be at least as, if not more, focused on the day-to-day > experiences and capabilities of existing contributors as it is on > new ones. Please see my other question about the role of the TC, and being active or reactive. [1] [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129658.html > I prefer that we keep a large human factor involved in the > application process. I do not want us to be purely objective because > such a process can never take into account the wider and ever > changing world. The members of the TC can be human info sponges that > do that accounting. The current process was created in part to > overcome the far too heavy and nitpicking (and human) previous > process but it has resulted in what amounts to a dilution in > direction. > > For me, each application tends to result in a lot of questions such > as the list I produced on patchset 34 of the Adjutant review[1]. I > worry that we are predisposed to accept applicants out of a general > sense of being "nice" and a belief that growth is a sign of health. > I'm unsure how these behaviors help to drive OpenStack in its > mission, but while the rules [2] say something as broad as > > It should help further the OpenStack mission, by providing a > cloud infrastructure service, or directly building on an > existing OpenStack infrastructure service. > > I feel we're painted into something of a corner where acceptance > must be the default unless there are egregious interoperability or > "four opens" violations. > > I'd like to see us work harder to refine the long term goals we are > trying to satisfy with the projects that make up OpenStack. This > will require us to continue the never-ending discussion about > whether OpenStack is a "Software Defined Infrastructure Framework" > or a "Cloud Solution" (plenty of people talk the latter, but plenty > of other people are spending energy on the former). And then Do you consider those two approaches to be mutually exclusive? In the past our community has had trouble defining "infrastructure" in a way that satisfies everyone. Some people stop at "allocating what you need to run a VM" while others consider it closer to "everything you need to run an application". How do you define "infrastructure"? > actually follow through: using the outcome of those discussions to > impact not just projects that we accept but also where existing > project focus their attention. We need to be as capable of saying > an informed "no" as we are of saying "yes". > > In the modern OpenSource world there are so many different > ecosystems that are cloud friendly: We don't need to provide a home > for everyone. There are plenty of places for people to go, including > the many different (and growing) facets of the OpenStack community. > I would prefer that we be assertive in how we evaluate for alignment > with the OpenStack mission. Doing that requires fairly constant > re-evaluation of the mission and a willingness to accept that it > does (and must) change. > > [1] https://review.openstack.org/#/c/553643/ > [2] > https://governance.openstack.org/tc/reference/new-projects-requirements.html > __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
Excerpts from Sean McGinnis's message of 2018-04-22 21:01:46 -0500: > > > > 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. What do you think we can do to be better informed about whether something is actually useful, or just appears useful? > > 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. Where should we draw the line with building something new and using tools available from other communities? > > 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
Re: [openstack-dev] [tc] campaign question related to new projects
Excerpts from Thierry Carrez's message of 2018-04-22 15:10:40 +0200: > Doug Hellmann wrote: > > [This is meant to be one of (I hope) several conversation-provoking > > questions directed at prospective TC members to help the community > > understand their positions before considering how to vote in the > > ongoing election.] > > > > 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. > > > > Without letting the conversation devolve too much into a discussion > > of Adjutant's case, please talk a little about how you would evaluate > > a project's application in general. What sorts of things do you > > consider when deciding whether a project "aligns with the OpenStack > > Mission," for example? > > Thanks for getting the discussion started, Doug. > > We have two main criteria in the requirements. The "follows the > OpenStack way" one, which I call the culture fit, and the "aligns with > the OpenStack mission" one, which I call the product fit. In both cases > there is room for interpretation and for personal differences in > appreciation. > > For the culture fit, while in most cases its straightforward (as the > project is born out of our existing community members), it is sometimes > much more blurry. When the group behind the new project is sufficiently > disjoint from our existing team members, you are judging a future > promise to behave in "the OpenStack way". In those cases it's really an > opportunity to reach out and explain how and why we do things the way we > do them, the principles behind our community norms. In the end it's a > leap of faith. The line I personally stand on is the willingness to > openly collaborate. If the new group is a closed group that has no > interest in including new people and wants to retain "control" over the > project, and is only interested in the marketing boost of being a part > of "OpenStack", then it should really be denied. We provide a space for > open collaboration, not for openwashing projects. > > For the product fit, there is also a lot of room for interpretation. For > me it boils down to whether "OpenStack" (the product) is better with > that project "in" rather than with that project "out". Sometimes it's an > easy sell: if a group wants to collaborate on packaging OpenStack for a > certain format/distro/deployment tool, it's clearly a win. In that case Given the number of complaints we have had over the lifetime of the project about the difficulty of upgrading, I am starting to wonder if we wouldn't have been better off sticking to a single deployment tool. > more is always better. But in most cases it's not as straightforward. > There is always tension between added functionality on one side, and > complexity / dilution / confusion on the other. Every "service" project > we add makes OpenStack more complex to explain, cross-project work more > difficult and interoperability incrementally harder. Whatever is added > has to be damn interesting to counterbalance that. The same goes for Why do you think OpenStack has more trouble explaining our feature set than other cloud systems that have a similarly diverse array of features? > competitive / alternative projects: in some cases the net result is a > win (different approaches to monitoring), while in some cases the net > result would be a loss (a Keystone alternative that would make everyone > else's life more miserable). > > In summary while the rules are precise, the way we interpret them can > still be varied. That is why this discussion is useful: comparing notes > on how we answer that difficult question, understanding where everyone > stands, helps us converge to a general consensus of the goals we are > trying to achieve when defining "OpenStack" scope, even if we disagree > on the particulars. > __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
I think it actually relies upon the new team to actively reaching out to the existing team. The new team cannot be lazy and wait for something happen for them, they have to keep reaching out and believe me the core developers from the existing official project will lend a hand in the end :) For Cyborg, I didn't even rush the application for an official project status. We've had more than one year just discuss the necessity and usefulness of the project, because I was not sure as well at the time if we are overlapping with something Nova or other project is already doing or we are just dreaming up some use cases. It turns out by conducting active and long discussions , we've got more than enough help from the Nova team :) I believe this is the team that is famous for their busy schedule, but the core developers helped tramendously because we are the one that is actively reaching out. SO back to topic, for TC's role, it should be to help the new team to find a productive way to actively get in contact with any related existing teams, not to put pressure on the existing projects :) On Mon, Apr 23, 2018 at 10:39 PM, Doug Hellmann wrote: > Excerpts from Zhipeng Huang's message of 2018-04-21 07:06:30 +0800: > > As the one who just lead a new project into governance last year, I > think I > > could take a first stab at it. > > > > For me the current requirements in general works fine, as I emphasized in > > my recent blog [0], the four opens are extremely important. Open Design > is > > one of the most important out the four I guess, because it actually will > > lead to the diversity question. A team with a single vendor, although it > > could satisfy all the other three easily, could not have a good open > design > > rather well. > > > > Another criteria (more related to the mission statement specifically) I > > would consider important is the ability to demonstrate (1)its scope does > > not overlap with existing official projects and (2) its ability to > actively > > work with related projects. The cross project collaboration does not have > > to be waited after the project got anointed, rather started when the > > project is in conception. > > In the past we have had challenges with existing teams having time, > energy, or interest in working with new teams. These issues are > often, but not always, outside of the control of the new teams. > What role can, or should, the TC play in mediating these situations? > > Doug > > > > > Well I guess that is my two cents :) > > > > [0] https://hannibalhuang.github.io/ > > > > > > > > On Sat, Apr 21, 2018 at 5:26 AM, Doug Hellmann > > wrote: > > > > > [This is meant to be one of (I hope) several conversation-provoking > > > questions directed at prospective TC members to help the community > > > understand their positions before considering how to vote in the > > > ongoing election.] > > > > > > 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. > > > > > > Without letting the conversation devolve too much into a discussion > > > of Adjutant's case, please talk a little about how you would evaluate > > > a project's application in general. What sorts of things do you > > > consider when deciding whether a project "aligns with the OpenStack > > > Mission," for example? > > > > > > Doug > > > > > > [1] https://governance.openstack.org/tc/reference/new-projects- > > > requirements.html > > > > > > > __ > > > 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 > > > > > > > > > > > -- > > Zhipeng (Howard) Huang > > > > Standard Engineer > > IT Standard & Patent/IT Product Line > > Huawei Technologies Co,. Ltd > > Email: huangzhip...@huawei.com > > Office: Huawei Industrial Base, Longgang, Shenzhen > > > > (Previous) > > Research Assistant > > Mobile Ad-Hoc Network Lab, Calit2 > > University of California, Irvine > > Email: zhipe...@uci.edu > > Office: Calit2 Building Room 2402 > > > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > > __ > 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 > -
Re: [openstack-dev] [tc] campaign question related to new projects
Excerpts from Rico Lin's message of 2018-04-22 16:50:51 +0800: > Thanks, Doug, for raising this campaign question > > > Here are my answers: > > > ***How you would evaluate a project's application in general > > First I would work through the requirements ([1]) to evaluate projects. > Since most of the requirements are specific enough. And here's more > important part, to leave evaluate logs or comments for projects which we > considered but didn't reach some requirements. It's very important to guide > projects to cross over requirements (and remember, a `-1` only means we > trying to help). > > Then, I work on questions, like: > > `How many user are interesting to/needs the functionality that service > provided?` > > `How active is this project and how's the diversity of contributors?` Our current policy is to allow projects with contributors from a small number of affiliations (even a single employer), under the theory that bringing a team into the community officially will help them grow by showing them the benefits of being more diverse and by making it easier for other community members who have employer restrictions on their open source work to justify contributing. Would you change that policy in any way? > > `Is this project required cross communities/projects cooperation? If yes, > how's the development workflows are working between communities/projects?` > > And last but is one of the most important questions, > > `Is this service aligns with the OpenStack Mission`? (and let's jump to > next question to answer this part) > > > > **What sorts of things do you consider when deciding whether a project > "aligns with the OpenStack Mission," for example?* > > I would consider things like: > > `Is the project's functionality complete the OpenStack infrastructure map?` > > Asking from user requirement and functionality point of view, `how's the > project(services) will make OpenStack better infrastructure for > user/operators?` and `how's this functionality provide a better life for > OpenStack developers?` > > `Is the project provides better integration point between communities` > > To build a better infrastructure, IMO it's also important to ask if a > project (service) really help on integration with other communities like > Kubernetes, OPNFV, CEPH, etc. I think to keep us as an active > infrastructure to solutions is part of our mission too. > > `Is it providing functionality which we can integrate with current projects > or SIG instead?` > > In short, we should be gathering our development energy, to really achieve > the jobs which is exactly why we spend times on trying to find official > projects and said this is part of our mission to work on. So when new > projects jump out, it's really important to discuss cross-project `is it > suitable for projects integrated and join force on specific functionality?` > (to do this while evaluating a project instead of when it's creating might > not be the best time to said `please integrate or join forces with other > teams together`(not even with a smiling face), but it's never too late for > a non-official/incubating project to consider about this). I really don't > like to to see any project get higher chances to die just because > developers chance their developing focus. It's happening when projects are > all willing to do the functionality, but no communication between(some > cases, not even now other projects exists), and new/old projects dead, then > TC needs to spend the time to pick those projects out. So IMO, it's worth > to spend times to investigate on whether projects can be joined. Or ideally > to put a resolution said, it's project's obligation to help on this, and > help other join force to be part of the team. Please see my other question about projects with overlapping feature sets [1]. Doug [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html > > `Can projects provide cross-project gating?` > > Do think if it's possible, we should consider this when asking if a service > aligns with our mission because not breaking rest of infrastructure is part > of the definition of `to build`. And providing cross-project gate jobs > seems like a way to go. To stable the integration between projects and > prevent released a failed feature when other services trying to work on new > ways and provide no guideline, ML, or solution, just only leave words like > `this is not part of our function to fix`. > > > > And finally, > > If we can answer all above questions, try to put in with the more accurate > number (like from user survey), and provides communications it needs, will > definitely help in finding next official projects. > > Also, when the evaluation is done, we should also evaluate the how's these > evaluation processes, how's guideline working for us? and which questions > above doesn't make any sense?. > > > [1] > https://governance.openstack.org/tc/reference/new-projects-requireme
Re: [openstack-dev] [tc] campaign question related to new projects
Excerpts from Zhipeng Huang's message of 2018-04-21 07:06:30 +0800: > As the one who just lead a new project into governance last year, I think I > could take a first stab at it. > > For me the current requirements in general works fine, as I emphasized in > my recent blog [0], the four opens are extremely important. Open Design is > one of the most important out the four I guess, because it actually will > lead to the diversity question. A team with a single vendor, although it > could satisfy all the other three easily, could not have a good open design > rather well. > > Another criteria (more related to the mission statement specifically) I > would consider important is the ability to demonstrate (1)its scope does > not overlap with existing official projects and (2) its ability to actively > work with related projects. The cross project collaboration does not have > to be waited after the project got anointed, rather started when the > project is in conception. In the past we have had challenges with existing teams having time, energy, or interest in working with new teams. These issues are often, but not always, outside of the control of the new teams. What role can, or should, the TC play in mediating these situations? Doug > > Well I guess that is my two cents :) > > [0] https://hannibalhuang.github.io/ > > > > On Sat, Apr 21, 2018 at 5:26 AM, Doug Hellmann > wrote: > > > [This is meant to be one of (I hope) several conversation-provoking > > questions directed at prospective TC members to help the community > > understand their positions before considering how to vote in the > > ongoing election.] > > > > 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. > > > > Without letting the conversation devolve too much into a discussion > > of Adjutant's case, please talk a little about how you would evaluate > > a project's application in general. What sorts of things do you > > consider when deciding whether a project "aligns with the OpenStack > > Mission," for example? > > > > Doug > > > > [1] https://governance.openstack.org/tc/reference/new-projects- > > requirements.html > > > > __ > > 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 > > > > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Product Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
7On 20/04/18 22:26, Doug Hellmann wrote: > Without letting the conversation devolve too much into a discussion > of Adjutant's case, please talk a little about how you would evaluate > a project's application in general. What sorts of things do you > consider when deciding whether a project "aligns with the OpenStack > Mission," for example? > > Doug > For me, the most important thing for a project that wants to join is that they act like "one of us" - what I think ttx refered to as "culture fit". This is fairly wide ranging, but includes things like: * Do they use the PTIs[0] * Do they use gerrit, or if they use something else, do they follow the same review styles and mechanisms? * Are they on IRC? * Do they use the mailing list for long running discussion? ** If a project doesn't have long running discussions and as a result does not have ML activity, I would see that as OK - my problem would be with a team that ran their own list. * Do they use standard devstack / -infra jobs for testing? * Do they use the standard common libraries (where appropriate)? If a project fails this test (and would have been accepted as something that drives the mission), I see no issue with the TC trying to bring them into the fold by helping them work like one of us, and accepting them when they have shown that they are willing to change how they do things. For the "product" fit, it is a lot more subjective. We used to have a system (pre Big Tent) where the TC picked "winners" in a space and blessed one project as the way to do $thing. Then, in big tent we started to not pick winners, and allow anyone who was one of us, and had a "cloud" application. Recently, we have moved back to seeing if a project overlaps with another. The real test for this (from my viewpoint) is if the perceived overlap is an area that the team that is currently in OpenStack is interested in pursuing - if not we should default to adding the project. Personally, if the project adds something that we currently lack, and have lacked for a long time (not to get too close to the current discussion), or tries to reduce the amount of extra tooling that deployers currently write in house, we should welcome them. The acid test for me is "How would I use this?" or "Have I written tooling or worked somewhere that wrote tooling to do this?" If the answer is yes, it is a good indication that they fit with the mission. - Graham 0 - https://governance.openstack.org/tc/reference/project-testing-interface.html signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
On Fri, 20 Apr 2018, Doug Hellmann wrote: [This is meant to be one of (I hope) several conversation-provoking questions directed at prospective TC members to help the community understand their positions before considering how to vote in the ongoing election.] Thanks for getting the ball rolling on some discussion, Doug. Without letting the conversation devolve too much into a discussion of Adjutant's case, please talk a little about how you would evaluate a project's application in general. What sorts of things do you consider when deciding whether a project "aligns with the OpenStack Mission," for example? This is an important question because project applications are one of the few ways in which the TC exercises any direct influence over the shape and direction of OpenStack. Much of the rest of the time the TC's influence is either indirect or limited. That's something I think we should change, in part because I feel the role of the TC should be at least as, if not more, focused on the day-to-day experiences and capabilities of existing contributors as it is on new ones. I prefer that we keep a large human factor involved in the application process. I do not want us to be purely objective because such a process can never take into account the wider and ever changing world. The members of the TC can be human info sponges that do that accounting. The current process was created in part to overcome the far too heavy and nitpicking (and human) previous process but it has resulted in what amounts to a dilution in direction. For me, each application tends to result in a lot of questions such as the list I produced on patchset 34 of the Adjutant review[1]. I worry that we are predisposed to accept applicants out of a general sense of being "nice" and a belief that growth is a sign of health. I'm unsure how these behaviors help to drive OpenStack in its mission, but while the rules [2] say something as broad as It should help further the OpenStack mission, by providing a cloud infrastructure service, or directly building on an existing OpenStack infrastructure service. I feel we're painted into something of a corner where acceptance must be the default unless there are egregious interoperability or "four opens" violations. I'd like to see us work harder to refine the long term goals we are trying to satisfy with the projects that make up OpenStack. This will require us to continue the never-ending discussion about whether OpenStack is a "Software Defined Infrastructure Framework" or a "Cloud Solution" (plenty of people talk the latter, but plenty of other people are spending energy on the former). And then actually follow through: using the outcome of those discussions to impact not just projects that we accept but also where existing project focus their attention. We need to be as capable of saying an informed "no" as we are of saying "yes". In the modern OpenSource world there are so many different ecosystems that are cloud friendly: We don't need to provide a home for everyone. There are plenty of places for people to go, including the many different (and growing) facets of the OpenStack community. I would prefer that we be assertive in how we evaluate for alignment with the OpenStack mission. Doing that requires fairly constant re-evaluation of the mission and a willingness to accept that it does (and must) change. [1] https://review.openstack.org/#/c/553643/ [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ 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
Re: [openstack-dev] [tc] campaign question related to new projects
> > 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
Re: [openstack-dev] [tc] campaign question related to new projects
Doug Hellmann wrote: > [This is meant to be one of (I hope) several conversation-provoking > questions directed at prospective TC members to help the community > understand their positions before considering how to vote in the > ongoing election.] > > 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. > > Without letting the conversation devolve too much into a discussion > of Adjutant's case, please talk a little about how you would evaluate > a project's application in general. What sorts of things do you > consider when deciding whether a project "aligns with the OpenStack > Mission," for example? Thanks for getting the discussion started, Doug. We have two main criteria in the requirements. The "follows the OpenStack way" one, which I call the culture fit, and the "aligns with the OpenStack mission" one, which I call the product fit. In both cases there is room for interpretation and for personal differences in appreciation. For the culture fit, while in most cases its straightforward (as the project is born out of our existing community members), it is sometimes much more blurry. When the group behind the new project is sufficiently disjoint from our existing team members, you are judging a future promise to behave in "the OpenStack way". In those cases it's really an opportunity to reach out and explain how and why we do things the way we do them, the principles behind our community norms. In the end it's a leap of faith. The line I personally stand on is the willingness to openly collaborate. If the new group is a closed group that has no interest in including new people and wants to retain "control" over the project, and is only interested in the marketing boost of being a part of "OpenStack", then it should really be denied. We provide a space for open collaboration, not for openwashing projects. For the product fit, there is also a lot of room for interpretation. For me it boils down to whether "OpenStack" (the product) is better with that project "in" rather than with that project "out". Sometimes it's an easy sell: if a group wants to collaborate on packaging OpenStack for a certain format/distro/deployment tool, it's clearly a win. In that case more is always better. But in most cases it's not as straightforward. There is always tension between added functionality on one side, and complexity / dilution / confusion on the other. Every "service" project we add makes OpenStack more complex to explain, cross-project work more difficult and interoperability incrementally harder. Whatever is added has to be damn interesting to counterbalance that. The same goes for competitive / alternative projects: in some cases the net result is a win (different approaches to monitoring), while in some cases the net result would be a loss (a Keystone alternative that would make everyone else's life more miserable). In summary while the rules are precise, the way we interpret them can still be varied. That is why this discussion is useful: comparing notes on how we answer that difficult question, understanding where everyone stands, helps us converge to a general consensus of the goals we are trying to achieve when defining "OpenStack" scope, even if we disagree on the particulars. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
Thanks, Doug, for raising this campaign question Here are my answers: ***How you would evaluate a project's application in general First I would work through the requirements ([1]) to evaluate projects. Since most of the requirements are specific enough. And here's more important part, to leave evaluate logs or comments for projects which we considered but didn't reach some requirements. It's very important to guide projects to cross over requirements (and remember, a `-1` only means we trying to help). Then, I work on questions, like: `How many user are interesting to/needs the functionality that service provided?` `How active is this project and how's the diversity of contributors?` `Is this project required cross communities/projects cooperation? If yes, how's the development workflows are working between communities/projects?` And last but is one of the most important questions, `Is this service aligns with the OpenStack Mission`? (and let's jump to next question to answer this part) **What sorts of things do you consider when deciding whether a project "aligns with the OpenStack Mission," for example?* I would consider things like: `Is the project's functionality complete the OpenStack infrastructure map?` Asking from user requirement and functionality point of view, `how's the project(services) will make OpenStack better infrastructure for user/operators?` and `how's this functionality provide a better life for OpenStack developers?` `Is the project provides better integration point between communities` To build a better infrastructure, IMO it's also important to ask if a project (service) really help on integration with other communities like Kubernetes, OPNFV, CEPH, etc. I think to keep us as an active infrastructure to solutions is part of our mission too. `Is it providing functionality which we can integrate with current projects or SIG instead?` In short, we should be gathering our development energy, to really achieve the jobs which is exactly why we spend times on trying to find official projects and said this is part of our mission to work on. So when new projects jump out, it's really important to discuss cross-project `is it suitable for projects integrated and join force on specific functionality?` (to do this while evaluating a project instead of when it's creating might not be the best time to said `please integrate or join forces with other teams together`(not even with a smiling face), but it's never too late for a non-official/incubating project to consider about this). I really don't like to to see any project get higher chances to die just because developers chance their developing focus. It's happening when projects are all willing to do the functionality, but no communication between(some cases, not even now other projects exists), and new/old projects dead, then TC needs to spend the time to pick those projects out. So IMO, it's worth to spend times to investigate on whether projects can be joined. Or ideally to put a resolution said, it's project's obligation to help on this, and help other join force to be part of the team. `Can projects provide cross-project gating?` Do think if it's possible, we should consider this when asking if a service aligns with our mission because not breaking rest of infrastructure is part of the definition of `to build`. And providing cross-project gate jobs seems like a way to go. To stable the integration between projects and prevent released a failed feature when other services trying to work on new ways and provide no guideline, ML, or solution, just only leave words like `this is not part of our function to fix`. And finally, If we can answer all above questions, try to put in with the more accurate number (like from user survey), and provides communications it needs, will definitely help in finding next official projects. Also, when the evaluation is done, we should also evaluate the how's these evaluation processes, how's guideline working for us? and which questions above doesn't make any sense?. [1] https://governance.openstack.org/tc/reference/new-projects-requirements.html May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin __ 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
Re: [openstack-dev] [tc] campaign question related to new projects
As the one who just lead a new project into governance last year, I think I could take a first stab at it. For me the current requirements in general works fine, as I emphasized in my recent blog [0], the four opens are extremely important. Open Design is one of the most important out the four I guess, because it actually will lead to the diversity question. A team with a single vendor, although it could satisfy all the other three easily, could not have a good open design rather well. Another criteria (more related to the mission statement specifically) I would consider important is the ability to demonstrate (1)its scope does not overlap with existing official projects and (2) its ability to actively work with related projects. The cross project collaboration does not have to be waited after the project got anointed, rather started when the project is in conception. Well I guess that is my two cents :) [0] https://hannibalhuang.github.io/ On Sat, Apr 21, 2018 at 5:26 AM, Doug Hellmann wrote: > [This is meant to be one of (I hope) several conversation-provoking > questions directed at prospective TC members to help the community > understand their positions before considering how to vote in the > ongoing election.] > > 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. > > Without letting the conversation devolve too much into a discussion > of Adjutant's case, please talk a little about how you would evaluate > a project's application in general. What sorts of things do you > consider when deciding whether a project "aligns with the OpenStack > Mission," for example? > > Doug > > [1] https://governance.openstack.org/tc/reference/new-projects- > requirements.html > > __ > 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 > -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Product Line Huawei Technologies Co,. Ltd Email: huangzhip...@huawei.com Office: Huawei Industrial Base, Longgang, Shenzhen (Previous) Research Assistant Mobile Ad-Hoc Network Lab, Calit2 University of California, Irvine Email: zhipe...@uci.edu Office: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado __ 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
[openstack-dev] [tc] campaign question related to new projects
[This is meant to be one of (I hope) several conversation-provoking questions directed at prospective TC members to help the community understand their positions before considering how to vote in the ongoing election.] 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. Without letting the conversation devolve too much into a discussion of Adjutant's case, please talk a little about how you would evaluate a project's application in general. What sorts of things do you consider when deciding whether a project "aligns with the OpenStack Mission," for example? Doug [1] https://governance.openstack.org/tc/reference/new-projects-requirements.html __ 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
