[tc][election] campaign question: team approval criteria
One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2].
What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams?
What other changes, if any, would you propose to the official team approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet?
How would you apply those rule changes to existing teams?
[1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html
On Wed, Feb 20, 2019 at 7:00 PM Doug Hellmann doug@doughellmann.com wrote:
One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2].
Yup, I was a subscriber of the -tc ML so I noted this draft from ttx's email in December. TBH, I haven't forged any clear opinion yet until you asked about it, so I'll try to give an answer that'll probably evolve over the course of my thinkings.
What parts, if any, of the OIP approval criteria do you think should
apply to OpenStack teams?
I think the set of criterias necessarly has to be a bit divergent for one reason : the OIP approval has to be driven by the Board (which includes other criterias which can not necessarly be purely technical) while our criterias are managed by the OpenStack *Technical* Committee, meaning that those criterias are necessarly measured by technical key points.
For example, discussing about strategic focus is totally understandable from a Board point of view but is debatable from a technical point of view. The other difference is about user adoption. As we follow a technical guidance, we don't challenge it. We rather just care of the development ecosystem but we even don't take it as a requirement, since we accept a maintenance mode. Probably worth thinking, but maybe we could investigate the idea to have user-defined tags (thanks to the UC) that would help giving a better view of the user adoptation of each project.
That being said, most of the criterias I'm seeing on the OIP etherpad look similar to the ones we have for the OpenStack TC : - the project has to follow the 4 Opens. - it has to communicate well with other Foundation projects - it somehow shares same technical best practices
The last item is interesting, because the OIP draft at the moment shows more technical requirements than the Foundation ones. For example, VMT is - at the moment I'm writing those lines - quoted as a common best practice, which is something we don't ask for our projects. That's actually a good food for thoughts : security is crucial and shouldn't be just a tag [3]. OpenStack is mature and it's our responsibility to care about CVEs.
What other changes, if any, would you propose to the official team
approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet?
We have minimum requirements that are expressed with [2] but there are also tags that are expressed by [4] One tag I feel is missing is about scalability: we had tenets in the past [5] but I don't see them transcribed into tags. That was one of my three items I mentioned in my candidacy email, but I'd love to see us be better on challenging projects on their scalability model.
How would you apply those rule changes to existing teams?
I'm more in a favor of an iterative approach with tags first, so that we are able to capture the current problems, and then tackle the problems thru common goals that are well accepted and discussed by all the project teams.
-Sylvain
[1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html -- Doug
[3] https://governance.openstack.org/tc/reference/tags/index.html#vulnerability-... [4] https://governance.openstack.org/tc/reference/tags/index.html [5] https://wiki.openstack.org/wiki/BasicDesignTenets
On 2019-02-20 19:36:28 +0100 (+0100), Sylvain Bauza wrote: [...]
The last item is interesting, because the OIP draft at the moment shows more technical requirements than the Foundation ones. For example, VMT is - at the moment I'm writing those lines - quoted as a common best practice, which is something we don't ask for our projects. That's actually a good food for thoughts : security is crucial and shouldn't be just a tag [3]. OpenStack is mature and it's our responsibility to care about CVEs.
[...]
Leaving aside the assertion that "caring about CVEs" is the same thing as caring about security, it's worth mentioning that the centralized OpenStack VMT doesn't (and can't) easily scale. It publishes a set of guidelines, process documents and templates which any team can follow to achieve similar results, but the governance tag we have right now serves mostly to set the scope of the centralized VMT (and in turn expresses some fairly strict criteria for expanding that scope to indicate direct oversight of more deliverables).
I'm open to suggestions for how the OpenStack TC can better promote good security practices within teams. I have some thoughts as well, though it probably warrants a separate thread at a later date when I have more time to assemble words on the subject.
Le lun. 25 févr. 2019 à 20:58, Jeremy Stanley fungi@yuggoth.org a écrit :
On 2019-02-20 19:36:28 +0100 (+0100), Sylvain Bauza wrote: [...]
The last item is interesting, because the OIP draft at the moment shows more technical requirements than the Foundation ones. For example, VMT is - at the moment I'm writing those lines - quoted as a common best practice, which is something we don't ask for our projects. That's actually a good food for thoughts : security is crucial and shouldn't be just a tag [3]. OpenStack is mature and it's our responsibility to care about CVEs.
[...]
Leaving aside the assertion that "caring about CVEs" is the same thing as caring about security, it's worth mentioning that the centralized OpenStack VMT doesn't (and can't) easily scale. It publishes a set of guidelines, process documents and templates which any team can follow to achieve similar results, but the governance tag we have right now serves mostly to set the scope of the centralized VMT (and in turn expresses some fairly strict criteria for expanding that scope to indicate direct oversight of more deliverables).
Yup and I know that :-( When I said the above, I was about saying that all the projects should have at least one liaison (at least the PTL) and a way to have some security discussions if needed.
I'm open to suggestions for how the OpenStack TC can better promote good security practices within teams. I have some thoughts as well, though it probably warrants a separate thread at a later date when I have more time to assemble words on the subject.
Yeah agreed. Maybe in the next Forum because we need to have a discussion with the operators for this I think.
Sylvain
Thanks Doug :) see responses inline below.
On 20/02/2019 17:58, Doug Hellmann wrote:
One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2].
To be open and honest, I have mostly been a bystander during this change.
What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams?
I want to start by saying I agree with Sylvain, he noted that this set of criteria has primarily been driven by the board, but it has also been driven by community members, Foundation staff, the TC, and the UC who have all been long-term members of the open source community and OpenStack. I would also like to note that your question does not specify whether or not you are talking about pre-existing OpenStack teams or new teams. Since we are talking about the future TC, I am going to assume "new" projects for my answer. But if I am wrong, Doug, could you please clarify and I will happily review my answer if there are changes to be made.
The requirements for new projects [2] has continuously been iterated on over the years, and it ultimately reflects the beginning of the community and what we believed was an important criteria set. The development process and the writing of the OIP approval criteria is seasoned with experts from the key use cases. We have had experience writing this type of thing before, and therefore it is a more formal set of Confirmation Guidelines.
That being said, to answer your question truthfully (IMHO): The guidelines for introducing a new OpenStack team is not as relevant as they once were. A quick search (and it is not covering all bases, just the majority) returned a list [3] indicating that in the last 18 months we have accepted more removals of projects, more integration of sub-projects than new projects to the OpenStack ecosystem. I am making my comparisons to 2015 - 2017 where we saw a surge of new projects throwing their hat into the ring. It was very important during that point in time to govern those projects ensuring they met OpenStack community guidelines. At this point in the OpenStack product lifecycle, I see this as a better opportunity for the new phase (OIP) to learn from us, rather than the other way around.
This is not to say that we can not continue to iterate on what it means to be a successful OpenStack project and apply great changes. But I believe we should be looking forwards.The new OSF Guidelines for OIP clearly has similar criteria to the requirements for new OpenStack projects. As already noted, those are:
- 4 opens - Communication
TL;DR - What we have is good. We can learn from the experience's OIP will encounter, but we must stop looking behind us to fix what isn't broken.
What other changes, if any, would you propose to the official team approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet?
I actually do not have anything to add to this. I think our official team approval process and criteria for what it is worth - is good. We have just begun the work to fully integrate OIP into our ecosystem, let's focus on the future.
[1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html
[3] https://review.openstack.org/#/q/project:+openstack/governance+file:+project...)
On 20/02/2019 17:58, Doug Hellmann wrote:
One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2].
What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams?
There was a line in the orignal draft of the OIP guidelines that I liked
Project does not significantly harm another existing confirmed project.
This has since been removed, but I would have liked to see this as:
Project does not harm another existing confirmed project.
and adopting that to our rules.
What other changes, if any, would you propose to the official team approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet?
I think the rules we have now are good, and now that we are becoming a more stable project, most of our applications are nearly formalities.
For the more complex applications, I am not sure that adding any extra rules will make it any better, as the TC will still have to take to evaluate it.
How would you apply those rule changes to existing teams?
[1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html
Doug Hellmann doug@doughellmann.com writes:
One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2].
What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams?
What other changes, if any, would you propose to the official team approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet?
How would you apply those rule changes to existing teams?
[1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html -- Doug
One of the criteria that caught my eye as especially interesting was that a project must complete at least one release before being accepted. We've debated that rule in the past, and always come down on the side encouraging new projects by accepting them early. I wonder if it's time to reconsider that, and perhaps to start thinking hard about projects that don't release after they are approved.
Thoughts?
On Mon, Feb 25, 2019 at 3:13 PM Doug Hellmann doug@doughellmann.com wrote:
Doug Hellmann doug@doughellmann.com writes:
One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2].
What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams?
What other changes, if any, would you propose to the official team approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet?
How would you apply those rule changes to existing teams?
[1]
http://lists.openstack.org/pipermail/foundation/2019-February/002708.html
[2]
https://governance.openstack.org/tc/reference/new-projects-requirements.html
-- Doug
One of the criteria that caught my eye as especially interesting was that a project must complete at least one release before being accepted. We've debated that rule in the past, and always come down on the side encouraging new projects by accepting them early. I wonder if it's time to reconsider that, and perhaps to start thinking hard about projects that don't release after they are approved.
Thoughts?
My personal opinion on that is that releasing a 1.0 version is just procedural. Or, said differently, political. It's just a signal saying "we think we are ready for production". The problem with that is that it's subjective. No real key metrics to attribute the meaning of "production-ready" (I'm even not talking of production-grade), just a feeling that the contributors team ideally, or just the "PTL" (given the project isn't official yet), considers it ready. As a consequence, there can be a big gap in between the contributors's expectations and the reality. That's what I called it "the reality wall". When you hit it, it's a pain.
I'm more in favor of objective metrics to define the health of a project in order to be production ready : does this project allow upgrades ? is this project distributed enough to grow atomically ? can we easily provide bugfixes thanks to a stable policy ?
Hope that clarifies your concern, -Sylvain
On Mon, Feb 25, 2019 at 3:19 PM Sylvain Bauza sbauza@redhat.com wrote:
On Mon, Feb 25, 2019 at 3:13 PM Doug Hellmann doug@doughellmann.com wrote:
Doug Hellmann doug@doughellmann.com writes:
One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2].
What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams?
What other changes, if any, would you propose to the official team approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet?
How would you apply those rule changes to existing teams?
[1]
http://lists.openstack.org/pipermail/foundation/2019-February/002708.html
[2]
https://governance.openstack.org/tc/reference/new-projects-requirements.html
-- Doug
One of the criteria that caught my eye as especially interesting was that a project must complete at least one release before being accepted. We've debated that rule in the past, and always come down on the side encouraging new projects by accepting them early. I wonder if it's time to reconsider that, and perhaps to start thinking hard about projects that don't release after they are approved.
Thoughts?
My personal opinion on that is that releasing a 1.0 version is just procedural. Or, said differently, political. It's just a signal saying "we think we are ready for production". The problem with that is that it's subjective. No real key metrics to attribute the meaning of "production-ready" (I'm even not talking of production-grade), just a feeling that the contributors team ideally, or just the "PTL" (given the project isn't official yet), considers it ready. As a consequence, there can be a big gap in between the contributors's expectations and the reality. That's what I called it "the reality wall". When you hit it, it's a pain.
I'm more in favor of objective metrics to define the health of a project in order to be production ready : does this project allow upgrades ? is this project distributed enough to grow atomically ? can we easily provide bugfixes thanks to a stable policy ?
Hope that clarifies your concern, -Sylvain
Looking again at your question, I think I haven't answered the main question. Should we accept a project even if it's not yet ready (and doesn't match the points I said above) ? Well, I surely understand the big interest in getting approved as an official project. Keep in mind I was a Climate/Blazar contributor in 2013 ;-) By that time, the project wasn't official (it was pre-Tent so the approval process was a bit different) so we faced the same visibility issue than most of the small projects face I guess. That said, even knowing how much is a pain to attract new contributors, getting approved doesn't get you those resources magically. In order to get some contributors, you first need to find some companies that are willing to dedicare some of their own resources into your project. That's not a matter of being ready or not, it's more a matter of seeing a business case behind the project.
For that precise reason, I don't really think it helps our projects to be approved very early as official projects. We should rather promote some incubation approach (and we did that with Stackforge and it was great for a small project like we were in 2013) and maybe have the TC members to shepherd those candidates in order to give them some light and visibility so that corporate sponsors could know of their existence, but the main step would still remain.
HTH, -Sylvain
On 25/02/2019 14:09, Doug Hellmann wrote:
Doug Hellmann doug@doughellmann.com writes:
One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2].
What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams?
What other changes, if any, would you propose to the official team approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet?
How would you apply those rule changes to existing teams?
[1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html -- Doug
One of the criteria that caught my eye as especially interesting was that a project must complete at least one release before being accepted. We've debated that rule in the past, and always come down on the side encouraging new projects by accepting them early. I wonder if it's time to reconsider that, and perhaps to start thinking hard about projects that don't release after they are approved.
Thoughts?
My response to your initial email was that we should focus more on going forward. I stand by that. This is an interesting addition to the OIP acceptance criteria, especially considering that we also considered it originally and for multiple reasons we reconsidered this option.
I don't think it would be a bad idea to implement this, maybe it would genuinely be a good idea - it should at least be discussed. It would reflect the maturation of the preexisting projects and their integration with each other.
On 2019-02-25 09:09:59 -0500 (-0500), Doug Hellmann wrote: [...]
One of the criteria that caught my eye as especially interesting was that a project must complete at least one release before being accepted. We've debated that rule in the past, and always come down on the side encouraging new projects by accepting them early. I wonder if it's time to reconsider that, and perhaps to start thinking hard about projects that don't release after they are approved.
Thoughts?
For me, the key difference is that OpenStack already has clear release processes outlined which teams are expected to follow for their deliverables. For confirming a new OIP it's seen as important that they've worked out what their release process *is* and proven that they can follow it (this is, perhaps, similar to why the OIP confirmation criteria mentions other things we don't for new OpenStack project team acceptance, like vulnerability management and governance).
Jeremy Stanley wrote:
On 2019-02-25 09:09:59 -0500 (-0500), Doug Hellmann wrote: [...]
One of the criteria that caught my eye as especially interesting was that a project must complete at least one release before being accepted. We've debated that rule in the past, and always come down on the side encouraging new projects by accepting them early. I wonder if it's time to reconsider that, and perhaps to start thinking hard about projects that don't release after they are approved.
Thoughts?
For me, the key difference is that OpenStack already has clear release processes outlined which teams are expected to follow for their deliverables. For confirming a new OIP it's seen as important that they've worked out what their release process *is* and proven that they can follow it (this is, perhaps, similar to why the OIP confirmation criteria mentions other things we don't for new OpenStack project team acceptance, like vulnerability management and governance).
Yes, that was the main idea behind that "one release" criteria, and I think our automated release processes take care of that for our openstack project teams. Furthermore, some OIPs are formed by merging source code or ideas from multiple parties (the canonical example being Kata containers being merged from Hyper and Intel) -- the task of making it a clear single project (rather than a WIP merge activity) should be long completed by confirmation time.
On 20/02/19 12:58 PM, Doug Hellmann wrote:
One of the key responsibilities of the Technical Committee is still evaluating projects and teams that want to become official OpenStack projects. The Foundation Open Infrastructure Project approval process has recently produced a different set of criteria for the Board to use for approving projects [1] than the TC uses for approving teams [2].
This is an apples-to-oranges comparison, because if the OIP criteria were to be applied to OpenStack, they'd be applied to it as a whole.
There's actually not that much difference though, except for the last point about a diversified developer base with active engagement from users &c. The OpenStack project as a whole has that but we don't require individual (sub)projects to do that to become official.
What parts, if any, of the OIP approval criteria do you think should apply to OpenStack teams?
At the moment, only the parts that already apply (like e.g. requiring open development).
What other changes, if any, would you propose to the official team approval process or criteria? Are we asking the right questions and setting the minimum requirements high enough? Are there any criteria that are too hard to meet?
So there's always a chicken-and-egg tradeoff where ideally we'd only take projects with lots of people working on them, but lots of people only want to work on projects that are official. At the moment, we've decided to err on the side of letting projects in. There may be a time when that's no longer appropriate, but for now it seems fine.
I am pleased that we now have the Vision for OpenStack Clouds document to refer to when dealing with applications. The idea behind that is not only that it gives us better guidance on how to vote, but also that it telegraphs where there might be gaps in the offering in which we would welcome new projects, and encourages prospective projects that might be outside of the vision to engage with us earlier. We will see over the next little while how that plays out in practice.
cheers, Zane.
How would you apply those rule changes to existing teams?
[1] http://lists.openstack.org/pipermail/foundation/2019-February/002708.html [2] https://governance.openstack.org/tc/reference/new-projects-requirements.html
participants (7)
-
Alexandra Settle
-
Doug Hellmann
-
Graham Hayes
-
Jeremy Stanley
-
Sylvain Bauza
-
Thierry Carrez
-
Zane Bitter