Open Stack

I will be happy to present at Sydney two things:
1. workflow/process for development proposals/feature gaps and existing repo that allow SIG/WGs to use.
2. a single place to drive feature/requirement proposal for all SIGs/WGs so they are visible to all other SIGs and WGs.

These come from our experience at Product WG and we can use them as starting point of discussion for SIG processes.
Thanks,
Arkady


-----Original Message-----
From: Melvin Hillsman [mailto:mrhillsman at gmail.com] 
Sent: Thursday, September 28, 2017 9:14 AM
To: openstack-sigs at lists.openstack.org
Subject: Re: [Openstack-sigs] [openstack-sigs][meta] requirements process questions

Note: If the tone of this offends anyone, that is not my intent.

We have to be mindful to stop steering conversations toward users vs non-users, devs vs non-devs, contributors vs non-contributors. As has been stated on many occasions, SIGs are so everyone interested in a particular area, no matter what you do or do not “contribute”, can meet, discuss, learn, prioritize, etc. If there was a SIG for folks who were interested in simply watching OpenStack Summit videos with the purpose of categorizing them, and those categories could be any number for any reason, I personally would say yes, great, go for it. Why? Because SIGs are not THE solution for getting un-proposed/un-implemented requirements/fixes/features into OpenStack.

That being said, they are one step in the right direction; we know there are at least two steps at this point (

We could:

1. Create a thread on the SIG ML [meta] bi-weekly for updates from SIGs a. Specific/targeted questions to get details on successful/unsuccessful practices, ideas, etc b. One question could be, have you identified a requirement, has it been implemented, if yes, reach out to the SIG and find out more, if no, reach out to the SIG and find out more ( i. This can lead to some useful data for specific individuals/teams/projects and/or the community at large ii. Here the point should not be to provide or identify a solution but better understand the context 2. Pick one specific un-proposed/un-implemented requirement from the past (Doug has suggested on more than one occasion) and understand it, its context, its start, and its end.
a. I do not have one in particular but surely more senior PWG members have one and a ML thread on it would be great b. Again, this is for context when participating in a SIG, with the overall goal in mind

IMO, once we begin to compile useful data/information we can make better guesses about the why, what, and how of the next step to un-proposed/un-implemented requirements. If I am just blowing hot air, forgive me, it is early and I was up really late for past couple days.

--
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: +1 (832) 264-2646
irc: mrhillsman

On 9/28/17, 8:30 AM, "Thierry Carrez" <thierry at openstack.org> wrote:

    Yih Leong, Sun. wrote:
    > Excerpts from Thierry Carrez's message of 2017-09-26 17:10:43 +0100:
    > 
    >> That sounds like a good idea. That said, one of the goals behind SIGs is
    >> that they are open to developer types as much as operator types, and
    >> therefore can be used as a vehicle to combine developer resources from
    >> like-minded organizations around a given topic. *The SIG can come up with
    >> a common priority list and have all those "internal" development
    >> resources working together in implementing those priorities. *If that's
    >> successful, there might not be as much need for external coordination
    >> and priority exposure.
    > 
    > This is the similar concept in Product WG when it was first established,
    > however, this model doesn't seems to pick up over the past two years
    > especially with the lack of resource/developer commitment from
    > organizations. I am hoping that shifting to SIG model can change the
    > course to drive prioritize implementation. 
    
    I think the model did not pick up because (1) the team working on
    prioritization (PWG) was separate from the teams working on
    implementation, and (2) because there were a lot of different teams
    involved in implementation.
    
    Here the team working on prioritization and the team working on
    implementation are ideally the same, and there is only one team working
    on implementation.
    
    Practical example: In the Public Cloud SIG there are operators of public
    clouds but also developers working for the public cloud operators and
    individual devs interested in improving things in that space. They
    collectively discuss pain points and priorities, and agree to pool all
    the development resources in the SIG to go in the same direction and
    implement the same priorities, across whichever projects are necessary.
    
    If successful, that removes the need for external prioritization, which
    (I agree with you) did not really work.
    
    -- 
    Thierry Carrez (ttx)
    
    _______________________________________________
    openstack-sigs mailing list
    openstack-sigs at lists.openstack.org
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
    



_______________________________________________
openstack-sigs mailing list
openstack-sigs at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs