Open Stack

Duncan McGreggor <duncan at dreamhost.com> writes:

>> And for "announce": who gets the right to post to it ? Or
>> rather, who gets to moderate the posts to it ? PPB ? PTL/relmgr ? Any
>> volunteer ?

Release announcements, and security updates should go to the announce
list, so it seems reasonable to allow the release and security teams to
moderate it.

> You'll have to work very hard to convince me that an announce list is
> worth the trouble :) 'Tradition' is not a good argument.

Someone pointed out that since the security announcements _haven't_ been
going to the announce list, but the main mailing list instead, that they
are concerned that people may have missed them.  That seems like a very
important and valid concern to me.  I believe that operators,
distributors, and news organizations who aren't 100% focused on
OpenStack but still have an interest would appreciate a low-volume
announcement list.  When I'm responsible for running instances of
several free software projects, I like subscribe to the announce list of
all of them, even if I'm not subscribed to the -users or -dev list.

To punt and say "people will see it on G+ or Twitter or whatever" (as
stated elsewhere in this thread) isn't good enough for a project of this
size.  What user should they follow?  What hashtag should they search
for?  Fundamentally, the same problems will show up -- either search for
"#openstack" and run the risk of having to read every tweet about
someone who "loves #openstack", or follow @openstack and, well, from the
looks of it, have the same problem.  Who gets to post from the
@openstack account?  Is the answer to that any better than what we could
do with the announce list?

Security updates frequently don't fit within 140 characters.

> First of all, it's not clear to me *who* would need to send out
> announcements. Can somebody start from there?

Release team.  Security team.

> I'll start enumerating why I don't think such list is needed by
> community managers:
>
> - more lists, more policies, more complexity for newcomers, things that
> they need to learn.
> - more lists, more policies, more complexity to manage (moderators, spam
> masters, etc)

The announce, user, developer triplicate is widely used and understood.
Very few people need to learn something new, and those that do will be
well served by learning it.

> - the announce list has not been used for over 8 months, nobody noticed

The announce list is not listed here:

  http://wiki.openstack.org/MailingLists

As far as I'm concerned, that means we don't have an announce list.  No
wonder no one knew about it or used it.

We have releases in production now, people have a more pressing need for
seeing these announcements, and we now have a need to make them.  This
is a good time to start using it properly.

> - multiplying contact points for people increases the need for
> cross-posting, more messages

Most decent mail providers have Message-ID based duplicate suppression;
cross-posting isn't the issue it used to be.  Or don't cross-post.  Or
subscribe the user list to the announce list.

Announce lists are low traffic -- no one is going to be upset at the
flood of messages from it.

> - an announce is fundamentally a one-way communication, no need to have
> 'discussions' around it, mailing list is the wrong tool *today* (it made
> sense in the 90s)

An announce list is a great tool for one-way communication.  It's easy
to configure it to discard unsolicited replies.  There's no rule that
says you have to reply to every email you receive.  Email is a useful
way to receive pertinent information.  As long as the rest of the
project uses mailing lists at all, it's not a burden to have an
announcement list.

> - an announce sent to a mailman list is fundamentally shouting in the
> wind: there might be people listening, you'll never know if they heard
> something. A *segmented* (developers, operators, business folks)
> newsletter is the best way to send out announcements.

I disagree with that; people who need to see information of the highest
importance from the project -- releases and security updates -- will
self-select only to subscribe to the announce mailing list, and if we
start using it properly, they will know they are getting the information
they need.

Without that structure in place, the sheer amount of information
(newsletters, twitter feeds, blog posts, G+ posts, general purpose
mailing list) a person who just wants to know when they should upgrade
is quite daunting, and in my mind, much more like "shouting in the
wind".

I believe we should at least have the common set of three mailing lists
(announce, user/operator, dev) and have a web page that lists them.

-Jim