[Openstack-sigs] [meta] How SIG work gets done?
mrhillsman at gmail.com
Thu Jul 20 19:39:43 UTC 2017
Hopefully SIGs address a couple things Jeremy pointed out; getting context
with the established community, removing the need for folks to drop what
they are working on, ensure people are not working in vacuums, require
folks to convince employers they need to shift their work, and find new
employment to work on a community priority. We can look for and discourage
these types of activities that can create unnecessary roadblocks.
Additionally I think Blair your question is relevant and that SIGs will
more than likely, where appropriate, be able to collaborate on
crowd-sourcing resources, financial or otherwise, to shore up development
of "unimplemented/unproposed" features, among other things.
On Thu, Jul 20, 2017 at 12:38 AM, Blair Bethwaite <blair.bethwaite at gmail.com
> 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
> Openstack-sigs mailing list
> Openstack-sigs at lists.openstack.org
mrhillsman at gmail.com
mobile: (832) 264-2646
Learner | Ideation | Belief | Responsibility | Command
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openstack-sigs