Open Stack

Chris Dent wrote:
> (First, a meta: can we adjust the mailing list configuration so the
> reply-to is the list, so we don't have this thing where responses go
> to the author and the list, or just the author. Very messy.)

Done! I thought that was done by default, but apparently not.

> On Tue, 8 Aug 2017, Thierry Carrez wrote:
> 
>> The workload is the same, since the group would still have the very same
>> scope and expected outputs. The rebranding (and move to a new common
>> communication ML) is signaling that the group is not an upstream or a
>> downstream workgroup, it is just an OpenStack workgroup, and everyone is
>> welcome. People who previously hesitated to join *might* take that step
>> once we remove the artificial barriers to entry.
> 
> Can you define your terms upstream and downstream here? We use them
> in so many different ways, yet I'm never quite sure how they mean
> nor the parties involved.

Upstream is before the commit lands / the software is released.
Corresponds to development activities (writing code, choosing
dependencies, writing doc, etc.). In OpenStack governance, that's the
domain of the Technical Committee.

Downstream is after the commit lands / the software is released.
Corresponds to software consumption activities (deploying, writing apps
against...). In OpenStack governance, that's the domain of the User
Committee.

(Just curious: could you give some examples of the "so many different
ways" we use those terms? I thought they were pretty well defined in the
open source world...)

>> Based on that history, I would say that classifying it as an upstream or
>> downstream workgroup hurt the API WG in the past. The SIG initiative is
>> all about clearly saying that work groups don't have to be on one side
>> or the other, they can just be groups of OpenStack humans wanting to
>> achieve some objective together, without having governance (or
>> mailing-list boundaries) get into the way. There is really nothing more
>> to it :)
> 
> One of the main concerns we expressed when discussing this in the
> last api-wg meeting was whether a move to the os-sig mailing list
> would mean the weekly newsletter loses its audience, or whether
> perhaps we should publish in both places and if we do that, gosh
> isn't that annoying?

I may be wrong, but I see the newsletter as an *output* of the group,
targeted to developers. The openstack-sigs ML is more where internal
discussions between the group members would happen (before that targeted
output is produced). Looking at usage of the api tag on openstack-dev,
you don't seem to use the ML that much for internal group discussions,
but if you did, I would expect *those* internal discussions to move to
the -sigs list.

> The identity of the group and the membership of the group aren't
> really concerns. We want participation from everyone who is
> interested, in any role.

I think being presented as a SIG rather than a upstream workgroup will
help in getting that participation from anyone interested.

> We're most concerned with disrupting the
> habits have been successful so far (having a cheery weekly IRC
> meeting, reaching the developer audience with the newsletter, and
> hearing from the developer audience via [api] tags). None of that
> needs to change but we do want to make sure that we integrate
> whatever new procedures (whatever they might be, what are they?)
> effectively.

I don't think you need to change any of that, frankly. The IRC meeting
should stay the same. If you want to specifically reach a
developer-specific audience (or ask them questions), you should
definitely continue to post to openstack-dev. If you want to
specifically reach an operator-specific audience, you should post to
openstack-operators. But if you want to have a discussion between the
API SIG members, you can use openstack-sigs, avoiding to cross-post
between -devs and -ops in an attempt to reach them all (or worse, pick
one and exclude the others, or even worse, refrain from having group
discussions on the ML because there is no good way to have them there).

-- 
Thierry Carrez (ttx)