[Openstack-sigs] [meta] How SIG work gets done?
Blair Bethwaite
blair.bethwaite at gmail.com
Thu Jul 20 05:38:10 UTC 2017
Does anyone see space for crowd-sourcing financial support towards
development of "unimplemented/unproposed" features? SIGs could provide a
vehicle for that...
On 20 Jul. 2017 12:19, "Thierry Carrez" <thierry at openstack.org> wrote:
> Melvin Hillsman wrote:
> > Observation: One typical concern voiced regarding a requirement from a
> > working group/team, organization, deployer, end-user, etc is that there
> > are no guarantees for requirements to even be considered let alone being
> > implemented. Comments regarding this generally center around developers
> > will work on what they are paid to work on. This assumes something that
> > may be pushing more folks away at times and that is a) we have a paywall
> > or pay-to-play model, b) we do not/have not had any folks contributing
> > out of the spirit of open-source, and c) if you are a small IT shop you
> > have no chance of being heard.
> >
> > Question: What "safeguards" are in place to ensure SIGs are not going to
> > go down this same path?
> >
> > Suggestion(s): I have heard a couple of things which may help but
> > primarily I wanted to get the conversation started. Here is one, require
> > cross-SIG and non-cross-SIG proposals to be prioritized and at least one
> > blueprint/proposal be put in a cycle, granted it has gone through
> > appropriate vetting, per project?
>
> My view on this is that SIGs should regroup all the stakeholders that
> care about a particular problem space or use case. Ideally those
> stakeholders would join the SIG with a mix of operational people (to
> describe needs and validate solutions) and development resources (to
> implement solutions). It's important that the SIG members agree on
> priorities, so that the development resources in that SIG can all
> collaborate to go in the same direction.
>
> In summary, I see the SIG as a way to provide more direct discussions
> between ops and devs interested in the same area (ideally blurring the
> line between them), but also as a way to come up with common priorities
> and pool development resources coming from different organizations (to
> get things done as a group).
>
> If a SIG ends up not including any development resource, the SIG can
> still produce documentation about missing features or priorities. But
> frankly, I would see that documentation more as a way to encourage
> organizations to throw development resources at the described priorities
> (and therefore join the SIG, and work upstream in the corresponding
> project teams), rather than as something that would magically get
> prioritized in some mythical "development team".
>
> --
> Thierry Carrez (ttx)
>
> _______________________________________________
> Openstack-sigs mailing list
> Openstack-sigs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20170720/682868c1/attachment.html>
More information about the Openstack-sigs
mailing list