Tim Bell wrote:
On 26/02/16 18:08, "Thierry Carrez" <thie...@openstack.org> wrote:
2. Community split
There is fear that the contributor-specific event will separate the
community into two groups, with developers skipping the main event and
non-developers not providing any feedback to the contributor-specific
event.
For those two objections, it's worth noting that there will still be a
lot of strategic discussions at the main event. That is where we look at
the N-1 release and start drawing plans and cross-project themes for the
N+1 release. We don't need every developer there, but we still need a
significant chunk of them, with every team represented, so that we can
have those strategic and cross-project discussions.
Therefore I'd expect someone who wants to keep touch with development
could still make only one trip, and I wouldn't expect the communities to
be split. We'd still all be represented in the main event.
Is the assumption that the users would be at the summit rather than the
contributor-specific sessions ? As there is a lot of sharing going on in the
current summit format (it is not just talks on products), I think the cloud
consumers/deployers would tend towards the summit.
I think this is my biggest worry that we get to a scenario where we lose the
chance for user (be it consumer of clouds or operators) technical discussion
with the projects. It certainly does not need all developers to be present but
project presentation at a high level is needed to understand the requirements,
explain the reasons for design decisions and debate the appropriate
improvements.
I think your worry is due to a misconception. We don't move the "design
summit" to a separate event and remove the users from the equation. We
*split* the design summit into two steps: strategic and tactical. Let's
take the Q cycle as an example (you can refer back to the picture I
attached to the original post).
It starts at the US Summit in May, 2017. We have everyone there: users,
product managers, but also a significant share of devs: PTLs, TC members
and other cross-project liaisons and drivers. The Ocata release has been
out for a few months and operators have started deploying and upgrading
to it. In the Strategic planning sessions, users can give feedback to
devs about that Ocata release and how the upgrade goes. We can start
drawing overarching themes for the Q cycle to address the pain points.
We can start prioritizing features and discuss their requirements and
initial design points. We can discuss user-facing policies like API
deprecation rules, stable branch maintenance, vulnerability
management... We make the most of the presence at the main summit event
to get all the community together.
In August, 2017 we have the Q contributor-oriented event. By that date
we have the feedback, we have the requirements, we have the priorities.
The problem is in getting things done. Teams gather and make sure they
have assignees for everything, and that all gaps are covered. They
discuss how to get a specific feature into the code, bootstrap the work,
and solve potential conflicts. They decide on meeting frequency, patch
review days, cross-project liaisons. We need *all* the regular
developers there so that everyone agrees on the plan to execute and
follow. Users are still welcome, but this is not a space for discussion
and influencing the priorities: it's a space to get things done and get
tactical alignment on how to achieve it in the next 3 months.
In November, 2017 we have the next summit, probably in APAC. Some
specific priority feature in a given project is not getting implemented
fast enough and is at risk. That project team decides to take advantage
of the summit space to hold a one-day hackathon to get this feature back
on track.
Early March, 2018 the Q release cycle is completed.
With the offset of the two event, has an option to locate the operators
mid-cycle meetup at the contributor-specific event ?
That was considered... and I would not necessarily be against it, but I
would like to understand what the benefit would be. Tom advocated for
keeping it as a separate event (or a set of regional separated events)
that would be ops-branded, making it easier for ops to justify travel to
it. If the goal is to co-locate so that users can more easily
participate to the contributor-oriented event, I think that would be
counter-productive for most operators: as I said earlier those are
project team meetings for project team members to work together -- you
should only join a room if you consider yourself part of the team that
will do the work. We won't be rediscussing requirements or gathering
feedback there, those will have been discussed at the strategic planning
sessions at the summit already.
--
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
