>From a first glance, this looks pretty good! I don't really have anything
else to add to what you've got there. It's succinct, and doesn't seem
overly complicated.

I'd like to mention something like the OPNFV[1] project, which basically
has a mandate to utilize OpenStack as an NFV platform, bringing together
various projects in the NFV space, and essentially building out reference
architectures for various situations.

This might be style as well that would work well and help a lot of
integrators get involved with building out more complicated scenarios while
not having to really be worried about the core development aspects. It
would also provide a nice platform where larger integration projects can be
fused together to help understanding any gaps in functionality, or areas
that could be simplified in a deployment scenario.

Having a focus on working groups within the developer community I think
makes a lot of sense, but perhaps an approach to building reference
architectures in the open where several integrators could work together,
would help steer the project going forward, and permit the community as a
whole to have a better foundation for different styles of deployments. This
would clearly be in addition to the working group concept for the developer

For the meeting aspects, IRC is generally a pretty good venue, and the
OpenStack project uses this quite a bit. There are meetbots[2] that allow
the meetings to be recorded, action items taken, and areas of interest to
be documented. I don't generally favour 'in person' vocal meetings for
these types of situations because of both timezone restrictions, and the
integration of people whose primary language isn't necessary English (or
where accents can cause issues, etc). Plus it's hard to keep a long term
record of the conversations without a secretary.

Good luck!

[1] https://www.opnfv.org/
[2] https://github.com/openstack-infra/meetbot

On Fri, Nov 4, 2016 at 10:07 AM, Matt Fredrickson <cres...@digium.com>

> Hey All,
> I've been thinking a lot about how working groups might work within
> the context of the Asterisk project.  Here are a few guidelines that I
> have come up with governing working groups.  Some of these guidelines
> come from the Node project, as they have a lot of pre-existing
> material on doing this.  I deliberately avoided comprehensively
> importing their structure and guidelines, but pulled from some of
> their more essential core principles.

Leif Madsen
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:

Reply via email to