Open Stack

> > 
> > Packaging_Rpm has a late candidate (Dirk Mueller). We always have a few 
> > teams per cycle that miss the election call, that would fall under that.
> > 
+1 for appointing Dirk as PTL.

> > Trove had a volunteer (Dariusz Krol), but that person did not fill the 
> > requirements for candidates. Given that the previous PTL (Zhao Chao) 
> > plans to stay around to help onboarding the new contributors, I'd 
> > support appointing Dariusz.
> > 

I would be fine with this. But I also wonder if it might make sense to move
Trove out of governance while they go through this transition so they have more
leeway to evolve the project how they need to, with the expectation that if
things get to a good and healthy point we can quickly re-accept the project as
official.

> > I suspect Freezer falls in the same bucket as Packaging_Rpm and we 
> > should get a candidate there. I would reach out to caoyuan see if they 
> > would be interested in steeping up.
> > 
> > LOCI is also likely in the same bucket. However, given that it's a 
> > deployment project, if we can't get anyone to step up and guarantee some 
> > level of currentness, we should consider removing it from the "official" 
> > list.
> > 
> > Dragonflow is a bit in the LOCI case. It feels like a miss too, but if 
> > it's not, given that it's an add-on project that runs within Neutron, I 
> > would consider removing it from the "official" list if we can't find 
> > anyone to step up.
> > 

Omer has responded that the deadline was missed and he would like to continue
as PTL. I think that is acceptable. (though unfortunate that it was missed)

> > For Winstackers and Searchlight, those are low-activity teams (18 and 13 
> > commits), which brings the question of PTL workload for feature-complete 
> > projects.
> 
> Even for feature-complete projects we need to know how to reach the
> maintainers, otherwise I feel like we would consider the project
> unmaintained, wouldn't we?
> 

I agree with Doug, I think there needs to be someone designated as the contact
point for issues with the project. We've seen other "stable" things suddenly go
unstable due to library updates or other external factors.

I don't think Thierry was suggesting there not be a PTL for these, but for any
potential PTL candidates they can know that the demands on their time to fill
that role _should_ be pretty light.

> > 
> > Finally, RefStack: I feel like this should be wrapped into an 
> > Interoperability SIG, since that project team is not producing 
> > "OpenStack", but helping fostering OpenStack interoperability. Having 
> > separate groups (Interop WG, RefStack) sounds overkill anyway, and with 
> > the introduction of SIGs we have been recentering project teams on 
> > upstream code production.
> > 
> 

I agree this has gotten to the point where it probably now makes more sense to
be owned by a SIG rather than being a full project team.