Open Stack

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)