IMO each one of these could warrant a working group:

TP
TO
TR
TM
TS
Grove
ATS
automation/ci/cd (does cdn-in-a-box fall in this category?)
documentation (or maybe this falls under each component)

Even though you could argue that some working groups might not be very
active, I don't really see the harm in having them.

On Fri, Nov 15, 2019 at 4:53 PM Rawlin Peters <[email protected]> wrote:

> I'm late to the party on this one, but +1 on the working groups idea.
>
> -1 on email lists per component. I don't really think there are enough
> "single-component" email threads that would warrant each component
> having their own mailing list. Those discussions can be had in the
> component's respective slack channel, if they really need to be
> separate, then taken to the mailing list with the results.
>
> - Rawlin
>
> On Thu, Nov 14, 2019 at 9:29 AM David Neuman <[email protected]>
> wrote:
> >
> > Sounds great, I will reach out to all three of you and we can get the
> ball
> > rolling.
> >
> > On Thu, Nov 14, 2019 at 6:58 AM Hoppal, Michael <
> [email protected]>
> > wrote:
> >
> > > I would love to start one for Traffic Ops.
> > >
> > > Michael
> > >
> > > On 11/13/19, 3:26 PM, "Gray, Jonathan" <[email protected]>
> wrote:
> > >
> > >     I'd volunteer for one on
> install/upgrade/lab.infra/automation/ci/cd.
> > >
> > >     Jonathan G
> > >
> > >
> > >     On 11/13/19, 3:07 PM, "Jeremy Mitchell" <[email protected]>
> wrote:
> > >
> > >         I'll bite. I'd like to start one for TP.
> > >
> > >         On Wed, Nov 13, 2019 at 2:50 PM David Neuman <
> > > [email protected]>
> > >         wrote:
> > >
> > >         > @Robert Butts <[email protected]>, there is a
> process to
> > > create
> > >         > more
> > >         > mailing lists, Phil helped me do it to create summits@
> > >         >
> > >         > If someone is interested in starting our first working
> group, I
> > > will be
> > >         > happy to help.
> > >         >
> > >         > On Wed, Nov 13, 2019 at 2:23 PM Robert O Butts <
> [email protected]>
> > > wrote:
> > >         >
> > >         > > +1 on Working Groups, the IETF also works by consensus, and
> > > WGs work very
> > >         > > well there.
> > >         > >
> > >         > > They're particularly good for letting people subscribe to
> > > things they
> > >         > care
> > >         > > about, while ignoring things they don't. It'd be ideal if
> > > Apache will let
> > >         > > us make arbitrary mailing lists. Not sure if that's
> possible?
> > >         > >
> > >         > >
> > >         > > On Wed, Nov 13, 2019 at 2:18 PM Hoppal, Michael <
> > >         > > [email protected]>
> > >         > > wrote:
> > >         > >
> > >         > > > Agreed with Jeremy I would be +1 on both ideas.
> > >         > > >
> > >         > > > On 11/13/19, 2:07 PM, "ocket 8888" <[email protected]>
> > > wrote:
> > >         > > >
> > >         > > >     well, I actually like Dave's suggestion better than
> my
> > > own
> > >         > > >
> > >         > > >     On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <
> > >         > > [email protected]
> > >         > > > >
> > >         > > >     wrote:
> > >         > > >
> > >         > > >     > I like both of those ideas. Either a working group
> and
> > > someone
> > >         > > > volunteers
> > >         > > >     > to setup/lead the working group (ideally a
> committer
> > > or pmc
> > >         > member)
> > >         > > > or an
> > >         > > >     > RM at the component level to help manage issues,
> > > milestones,
> > >         > > > roadmaps, etc.
> > >         > > >     >
> > >         > > >     > Jeremy
> > >         > > >     >
> > >         > > >     > On Wed, Nov 13, 2019 at 12:27 PM Dave Neuman <
> > > [email protected]>
> > >         > > > wrote:
> > >         > > >     >
> > >         > > >     > > I agree with Rob and Jonathan on this one.  I
> don't
> > > see a
> > >         > reason
> > >         > > > that
> > >         > > >     > > committers cannot already gravitate toward a
> > > component, and I
> > >         > > want
> > >         > > > to
> > >         > > >     > avoid
> > >         > > >     > > adding any formal designation to community
> members
> > > outside of
> > >         > the
> > >         > > > defined
> > >         > > >     > > Apache ones (contributor, commiter, and pmc).
> > >         > > >     > > I think I would rather see us head in the
> direction
> > > of working
> > >         > > > groups.
> > >         > > >     > We
> > >         > > >     > > can define working groups for each component
> > > (although I really
> > >         > > > don't
> > >         > > >     > think
> > >         > > >     > > each component needs one) that is open to anyone.
> > > The working
> > >         > > > group can
> > >         > > >     > > meet on a consistent interval and can use that
> time
> > > to complete
> > >         > > the
> > >         > > >     > > managerial tasks outlined above as well as
> discuss
> > > open PRs,
> > >         > have
> > >         > > > design
> > >         > > >     > > conversations, etc.  Of course, any decision
> made in
> > > the
> > >         > working
> > >         > > > group
> > >         > > >     > > meeting would then need to be brought back to the
> > > list.
> > >         > Ideally
> > >         > > > we would
> > >         > > >     > > have a PMC member that takes the initiative to
> setup
> > > the
> > >         > working
> > >         > > > group,
> > >         > > >     > but
> > >         > > >     > > I don't see that as a hard requirement.  I am
> happy
> > > to help
> > >         > > anyone
> > >         > > > who is
> > >         > > >     > > interested get a working group setup.
> > >         > > >     > >
> > >         > > >     > > --Dave
> > >         > > >     > >
> > >         > > >     > > On Wed, Nov 13, 2019 at 11:24 AM <
> > > [email protected]> wrote:
> > >         > > >     > >
> > >         > > >     > > > On Wed, 2019-11-13 at 10:57 -0700, Jeremy
> Mitchell
> > > wrote:
> > >         > > >     > > > > Maybe component lead is not the right term?
> > >         > > >     > > > >> ... hold the position for a defined amount
> of
> > > time ...
> > >         > > >     > > >
> > >         > > >     > > > Since most of the responsibilities seem tied to
> > > releases,
> > >         > maybe
> > >         > > > we just
> > >         > > >     > > > need sub-release-managers for the components?
> The
> > > main RM can
> > >         > > > also fill
> > >         > > >     > > > one of those positions as well as "main RM".
> > >         > > >     > > >
> > >         > > >     > > >
> > >         > > >     > >
> > >         > > >     >
> > >         > > >
> > >         > > >
> > >         > > >
> > >         > >
> > >         >
> > >
> > >
> > >
> > >
> > >
>

Reply via email to