<div dir="auto">Does anyone see space for crowd-sourcing financial support towards development of "unimplemented/unproposed" features? SIGs could provide a vehicle for that...</div><div class="gmail_extra"><br><div class="gmail_quote">On 20 Jul. 2017 12:19, "Thierry Carrez" <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Melvin Hillsman wrote:<br>
> Observation: One typical concern voiced regarding a requirement from a<br>
> working group/team, organization, deployer, end-user, etc is that there<br>
> are no guarantees for requirements to even be considered let alone being<br>
> implemented. Comments regarding this generally center around developers<br>
> will work on what they are paid to work on. This assumes something that<br>
> may be pushing more folks away at times and that is a) we have a paywall<br>
> or pay-to-play model, b) we do not/have not had any folks contributing<br>
> out of the spirit of open-source, and c) if you are a small IT shop you<br>
> have no chance of being heard.<br>
><br>
> Question: What "safeguards" are in place to ensure SIGs are not going to<br>
> go down this same path?<br>
><br>
> Suggestion(s): I have heard a couple of things which may help but<br>
> primarily I wanted to get the conversation started. Here is one, require<br>
> cross-SIG and non-cross-SIG proposals to be prioritized and at least one<br>
> blueprint/proposal be put in a cycle, granted it has gone through<br>
> appropriate vetting, per project?<br>
<br>
My view on this is that SIGs should regroup all the stakeholders that<br>
care about a particular problem space or use case. Ideally those<br>
stakeholders would join the SIG with a mix of operational people (to<br>
describe needs and validate solutions) and development resources (to<br>
implement solutions). It's important that the SIG members agree on<br>
priorities, so that the development resources in that SIG can all<br>
collaborate to go in the same direction.<br>
<br>
In summary, I see the SIG as a way to provide more direct discussions<br>
between ops and devs interested in the same area (ideally blurring the<br>
line between them), but also as a way to come up with common priorities<br>
and pool development resources coming from different organizations (to<br>
get things done as a group).<br>
<br>
If a SIG ends up not including any development resource, the SIG can<br>
still produce documentation about missing features or priorities. But<br>
frankly, I would see that documentation more as a way to encourage<br>
organizations to throw development resources at the described priorities<br>
(and therefore join the SIG, and work upstream in the corresponding<br>
project teams), rather than as something that would magically get<br>
prioritized in some mythical "development team".<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
______________________________<wbr>_________________<br>
Openstack-sigs mailing list<br>
<a href="mailto:Openstack-sigs@lists.openstack.org">Openstack-sigs@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-sigs</a><br>
</blockquote></div></div>