Open Stack

On 28 May 2015 at 03:09, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I've heard that other projects come up with actual action lists and
> work assignments. I've heard Nova, Ironic, Oslo do it, and I witnessed
> just that in those Oslo sessions I had a chance to visit. So Neutron
> can be special in this regard and may not reflect the general
> openstack way of doing design sessions.
>
> I won't judge whether it's good or bad though. It may be the case that
> Neutron is actually different (lots of vendors and stakeholders to
> talk to and convince? a project that started as a vendor initiative
> and only now untangles itself from pure vendor matters?)
>
> Note that sessions that did not have clear vendor interest
> (give-me-a-network, nova-network migration, port health checks)
> actually got some kind of resolution and a plan (though often in oral
> form).
>
> While I agree most of decisions are not (yet?) properly documented or
> discussed with broader community, and it would be great to see those
> random etherpad notes structured in email threads. (btw on lots of
> sessions during the summit etherpad was just broken; in those cases
> it's especially important to store the oral knowledge of those who had
> a chance to attend those sessions in some written form, asap).
>
> Ihar
>

I think we all agree that dealing with OpenStack entropy can be
challenging, especially for newcomers :)

I think that Gal's suggestion is somewhat sensible, and it already happens
in one form or another (like specs/bug submissions, ML threads, and/or
IRC). Gathering and defining work items can be a shared effort that takes
place using the tools we have to collaborate. The seasoned folks can
provide guidance to less experienced folks via the typical remote
interaction.

Also bear in mind, that what is discussed at the Summit is only a fraction
of the workload proposed during the cycle.

So, what's the real value of coming up with an action list and task
assignments (quick-to-become stale) via email? Being more prescriptive
about the process would only provide marginal value IMO. Do we really need
yet another rule in place? I fear we are becoming a bureaucratic machine.

Cheers,
Armando


>
> On 05/28/2015 10:12 AM, Gal Sagie wrote:
> > Hello All,
> >
> > I wanted to very briefly share my thoughts and a suggestion
> > regarding the Neutron design summits (maybe only for the next one,
> > but still..)
> >
> > I would first like to say that i was amazed by the number of people
> > that attended the summit, it was really great to see it and it was
> > very nice meeting most of you and linking the person with the IRC
> > nick.
> >
> > Anyone that knows me, or talked with me in the past knows that i
> > wanted to get involved with Open Source for quite some time and i
> > really feel fortunate to be able to contribute and join OpenStack,
> > and hope to continue with this efforts going forward.
> >
> > I have to share that i was expecting the design summits to be
> > completely different then what went on, and although some issues
> > were interesting i feel they were not use full to go forward but
> > rather were just a stage for people to express opinions/ideas
> > without a distinct decision.
> >
> > Since i am new and never been in one of these i don’t want to judge
> > or declare if that’s good or bad :), i do think that its hard to
> > actually achieve something with so many people but i also
> > understand and appreciate the great interest of so many people with
> > Neutron.
> >
> > A small suggestion i think might improve is if the session
> > moderator will write (or any other volunteer) a follow up email
> > with Action Items that needs to be addressed and people actually
> > taking and volunteering to take some of those action items. This
> > can and should be live in the meeting where anyone requesting or
> > making a suggestion would take it on him/her self to push it
> > forward and report status. (I think every point in the agenda must
> > be converted into an action item)
> >
> > We can also do this before the actual summit on the agenda points
> > and hopefully gets a discussion going before the actual session.
> >
> > I also think we should try to re-write the agenda points into a
> > more lower level points before the summit rather then try to tackle
> > the high level stuff (for example trying to discuss the pro's and
> > con's in the mailing lists/IRC before the summit and have a more
> > concrete discussion in the session it self)
> >
> >
> > I do hope that’s the right place to express this, and again that’s
> > only my impression, i could be completely wrong here as i don’t
> > consider my self experienced enough with the Open Source way of
> > doing things. Would love to help in the future with some of the
> > points i raised here.
> >
> > Thanks Gal.
> >
> >
> >
> > ______________________________________________________________________
> ____
> >
> >
> OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVZulhAAoJEC5aWaUY1u57w2AH/0R26YC5Q+sRLYMTEpwJHCKi
> BFlsOJuQY1Sae5wBlJuvaWlWXmv8QzKGd/bFCzVuWwJC1x6V0xp485Uk4IsDrddz
> yMieI7YeakU8Aa/nw3Gxe//tj9yseqbleBVxlCGeKwGNr3ZOurIJZcTUVTb2NVm7
> inkkXqH3KGif8e1R8b9fJZZYocZBkZtU04bICNo0hD5RXsQ9NwtLOCw5yX9OpUmv
> E7ckcYkZAl5lVa2oMqhE6jVtDVAPtx9iqsbuyW2PlagzcArO9jfzezEHoBdsxJFl
> aExT55J6wnZ+rSFHLRPcE3kq9y+oqTgVe4URMSYC/wMYB0xn1I9sorm5cx1Qwg0=
> =T3Yy
> -----END PGP SIGNATURE-----
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150528/fa4cf460/attachment.html>