Open Stack

Here is the link to the session in case you'd like to add it to your
schedule [0].

[0]
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21759/openstack-is-mature-time-to-get-serious-on-maintainers

On 05/17/2018 07:55 PM, Rochelle Grober wrote:
>
> Folks,
>
>  
>
> TL;DR
>
> The last session related to extended releases is: OpenStack is
> "mature" -- time to get serious on Maintainers
> It will be in room 220 at 11:00-11:40
>
> The etherpad for the last session in the series on Extended releases
> is here:
>
> https://etherpad.openstack.org/p/YVR-openstack-maintainers-maint-pt3
>
>  
>
> There are links to info on other communities’ maintainer
> process/role/responsibilities also, as reference material on how other
> have made it work (or not).
>
>  
>
> The nitty gritty details:
>
>  
>
> The upcoming Forum is filled with sessions that are focused on issues
> needed to improve and maintain the sustainability of OpenStack
> projects for the long term.  We have discussion on reducing technical
> debt, extended releases, fast forward installs, bringing Ops and User
> communities closer together, etc.  The community is showing it is now
> invested in activities that are often part of “Sustaining Engineering”
> teams (corporate speak) or “Maintainers (OSS speak).  We are doing
> this; we are thinking about the moving parts to do this; let’s think
> about the contributors who want to do these and bring some clarity to
> their roles and the processes they need to be successful.  I am hoping
> you read this and keep these ideas in mind as you participate in the
> various Forum sessions.  Then you can bring the ideas generated during
> all these discussions to the Maintainers session near the end of the
> Summit to brainstorm how to visualize and define this new(ish)
> component of our technical community.
>
>  
>
> So, who has been doing the maintenance work so far?  Mostly (mostly)
> unsung heroes like the Stable Release team, Release team, Oslo team,
> project liaisons and the community goals champions (yes, moving to py3
> is a sustaining/maintenance type of activity).  And some operators
> (Hi, mnaser!).  We need to lean on their experience and what we think
> the community will need to reduce that technical debt to outline what
> the common tasks of maintainers should be, what else might fall in
> their purview, and how to partner with them to better serve them.
>
>  
>
> With API lower limits, new tool versions, placement, py3, and even
> projects reaching “code complete” or “maintenance mode,” there is a
> lot of work for maintainers to do (I really don’t like that term, but
> is there one that fits OpenStack’s community?).  It would be great if
> we could find a way to share the load such that we can have part time
> contributors here.  We know that operators know how to cherrypick,
> test in there clouds, do bug fixes.  How do we pair with them to get
> fixes upstreamed without requiring them to be full on developers?  We
> have a bunch of alumni who have stopped being “cores” and sometimes
> even developers, but who love our community and might be willing and
> able to put in a few hours a week, maybe reviewing small patches,
> providing help with user/ops submitted patch requests, or whatever. 
> They were trusted with +2 and +W in the past, so we should at least be
> able to trust they know what they know.  We  would need some way to
> identify them to Cores, since they would be sort of 1.5 on the voting
> scale, but……
>
>  
>
> So, burn out is high in other communities for maintainers.  We need to
> find a way to make sustaining the stable parts of OpenStack sustainable.
>
>  
>
> Hope you can make the talk, or add to the etherpad, or both.  The
> etherpad is very musch still a work in progress (trying to organize it
> to make sense).  If you want to jump in now, go for it, otherwise it
> should be in reasonable shape for use at the session.  I hope we get a
> good mix of community and a good collection of those who are already
> doing the job without title.
>
>  
>
> Thanks and see you next week.
>
> --rocky
>
>  
>
>  
>
>  
>
> ------------------------------------------------------------------------
>
> 华为技术有限公司 Huawei Technologies Co., Ltd.
>
> Company_logo
>
> Rochelle Grober
>
> Sr. Staff Architect, Open Source
> Office Phone:408-330-5472
> Email:rochelle.grober at huawei.com
>
> ------------------------------------------------------------------------
>
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed
> above. Any use of the
> information contained herein in any way (including, but not limited
> to, total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error,
> please notify the sender by
> phone or email immediately and delete it!
>
>  
>
>
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180518/bcd98f6b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5474 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180518/bcd98f6b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180518/bcd98f6b/attachment.sig>