<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 21 September 2016 at 22:41, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wed, Sep 21, 2016 at 3:35 PM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
> Chivers, Doug wrote:<br>
>> My concern is with the original wording “The suggested way forward there would be to remove the "Security project team"”.<br>
>><br>
>> This seems like a move to instantly reduce investment in OpenStack security, because the majority of members of the Security Project are corporately funded, which will be significantly impacted by the removal of the security project. I have no knowledge over the difference between a working group and a project, like everyone else on the project we are simply here to contribute to OpenStack security, drive innovation in security, deliver documentation like OSSNs, etc, rather than get involved in the politics of OpenStack.<br>
>><br>
>> In response to the various questions of why no-one from our project noticed that we didn’t have a nomination for the PTL, we assumed that was taken care of. Realistically maybe two or three people on the security project have the availability to be PTL, one being our current PTL, for all the rest of us its simply not a concern until we need to vote.<br>
>><br>
>> On a personal note, reading –dev is unfortunately a lower priority than designing architectures, responding to customers and sales teams, closing tickets, writing decks and on the afternoon or so I can spend each week, working on my upstream projects (this week it was: <a href="https://review.openstack.org/#/c/357978/5" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/357978/5</a> - thanks to the Barbican team for all their work). Possibly this is wrong, but I didn’t sign up as a contributor to spend all my spare time reading mailing lists.<br>
><br>
> So while I still think there is a slight disconnect (like, members of<br>
> the security team are less often involved in other teams) that results<br>
> in the Security team being more likely to miss the very few process<br>
> deadlines that apply to them, I'm not convinced it justifies removing<br>
> the "official" status of the team and make it a workgroup.<br>
><br>
> I privately received information that explains why the PTL was not on<br>
> top of things during election weeks. With ~60 teams around there will<br>
> always be one or two that miss and that we must check on. It /always/ is<br>
> symptomatic of /some/ disconnect. But here I'm not sure it passes the<br>
> bar of "non-alignment with the community" that would make the Security<br>
> team unfit to be an official OpenStack team...<br>
><br>
</span>I agree, and in times like this, it's best to use common sense rather<br>
than trying to have a rule to fit everything into. In this case, Rob<br>
and the security team have put forth an explanation of what happened,<br>
I fail to see how removing them after this does anything other than<br>
foster bad will. I would vote to keep the security team around at this<br>
point.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div><br></div><div>I feel bad quoting policy here... but we do have prior art for this... If we look at resolution, "2014-11-28 Process for Leaderless Programs"[0], we have policy for *exactly* this situation.. which should probably have been the first action rather than considering a new resolution.</div><div><br></div><div>For reference:</div><div><ol class="gmail-arabic gmail-simple" style="color:rgb(62,67,73);font-family:arial,sans-serif;font-size:14.4px"><li style="line-height:1.5em">Programs without a minimum of one eligible candidate are identified to the Technical Committee by the Election Officials, as soon as possible after the nomination period has expired.</li><li style="line-height:1.5em">The Technical Committee can appoint a leader to any programs in this situation, by mutual agreement of the Technical Committee and the proposed appointee.</li><li style="line-height:1.5em">The appointed leader has all the same obligations and responsibilities as a self-nominated elected Program Technical Lead.</li></ol></div><div>[0] <a href="http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html">http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html</a> </div><div><br></div><div>--</div><div>Kind Regards,</div><div>Dave Walker</div></div></div></div>