You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Jeremy Mitchell <mi...@apache.org> on 2019/11/13 16:58:06 UTC
Component leads
I would like to propose the idea of open source component leads for TP, TO,
TR, TM and TS. I think having a component lead would help with the
following:
- Help the release manager compile comprehensive release notes for that
component
- Help the release manager determine release scope related to that
component (what to not cherry pick to a release)
- Release candidate testing/validation for that component
- Manage issues related to that component (i.e. apply labels (component,
type and severity)) and close old/irrelevant issues.
- Develop a first pass roadmap (maybe a roadmap.md file at the root of the
component?) for that component and potentially create milestones and
facilitate discussion around the roadmap/milestones.
- Clean up old PRs for that component
- Drive standards for that component
IMO these component leads would probably need the following qualifications:
- someone that works with the component on a day-to-day basis and is
obviously very experienced with the component.
- is a committer so they can do things like apply labels, create
milestones, merge PRs, etc.
Ideally these component leads would represent different companies, however,
maybe that is a goal and not a requirement at the moment.
I bring this up because I think having component leads would help the
quality, organization and transparency of the TC project as a whole and
would provide potential contributors with a better vision of where TC is
headed.
Thoughts?
Jeremy
Re: [EXTERNAL] Component leads
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 <ra...@apache.org> 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 <da...@gmail.com>
> 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 <
> Michael_Hoppal@comcast.com>
> > wrote:
> >
> > > I would love to start one for Traffic Ops.
> > >
> > > Michael
> > >
> > > On 11/13/19, 3:26 PM, "Gray, Jonathan" <Jo...@comcast.com>
> 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" <mi...@gmail.com>
> wrote:
> > >
> > > I'll bite. I'd like to start one for TP.
> > >
> > > On Wed, Nov 13, 2019 at 2:50 PM David Neuman <
> > > david.neuman64@gmail.com>
> > > wrote:
> > >
> > > > @Robert Butts <ro...@gmail.com>, 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 <
> rob@apache.org>
> > > 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 <
> > > > > Michael_Hoppal@comcast.com>
> > > > > wrote:
> > > > >
> > > > > > Agreed with Jeremy I would be +1 on both ideas.
> > > > > >
> > > > > > On 11/13/19, 2:07 PM, "ocket 8888" <oc...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > well, I actually like Dave's suggestion better than
> my
> > > own
> > > > > >
> > > > > > On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <
> > > > > mitchell852@gmail.com
> > > > > > >
> > > > > > 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 <
> > > neuman@apache.org>
> > > > > > 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 <
> > > ocket8888@gmail.com> 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".
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > >
>
Re: [EXTERNAL] Component leads
Posted by Rawlin Peters <ra...@apache.org>.
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 <da...@gmail.com> 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 <Mi...@comcast.com>
> wrote:
>
> > I would love to start one for Traffic Ops.
> >
> > Michael
> >
> > On 11/13/19, 3:26 PM, "Gray, Jonathan" <Jo...@comcast.com> 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" <mi...@gmail.com> wrote:
> >
> > I'll bite. I'd like to start one for TP.
> >
> > On Wed, Nov 13, 2019 at 2:50 PM David Neuman <
> > david.neuman64@gmail.com>
> > wrote:
> >
> > > @Robert Butts <ro...@gmail.com>, 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 <ro...@apache.org>
> > 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 <
> > > > Michael_Hoppal@comcast.com>
> > > > wrote:
> > > >
> > > > > Agreed with Jeremy I would be +1 on both ideas.
> > > > >
> > > > > On 11/13/19, 2:07 PM, "ocket 8888" <oc...@gmail.com>
> > wrote:
> > > > >
> > > > > well, I actually like Dave's suggestion better than my
> > own
> > > > >
> > > > > On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <
> > > > mitchell852@gmail.com
> > > > > >
> > > > > 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 <
> > neuman@apache.org>
> > > > > 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 <
> > ocket8888@gmail.com> 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".
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> >
> >
Re: [EXTERNAL] Component leads
Posted by David Neuman <da...@gmail.com>.
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 <Mi...@comcast.com>
wrote:
> I would love to start one for Traffic Ops.
>
> Michael
>
> On 11/13/19, 3:26 PM, "Gray, Jonathan" <Jo...@comcast.com> 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" <mi...@gmail.com> wrote:
>
> I'll bite. I'd like to start one for TP.
>
> On Wed, Nov 13, 2019 at 2:50 PM David Neuman <
> david.neuman64@gmail.com>
> wrote:
>
> > @Robert Butts <ro...@gmail.com>, 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 <ro...@apache.org>
> 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 <
> > > Michael_Hoppal@comcast.com>
> > > wrote:
> > >
> > > > Agreed with Jeremy I would be +1 on both ideas.
> > > >
> > > > On 11/13/19, 2:07 PM, "ocket 8888" <oc...@gmail.com>
> wrote:
> > > >
> > > > well, I actually like Dave's suggestion better than my
> own
> > > >
> > > > On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <
> > > mitchell852@gmail.com
> > > > >
> > > > 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 <
> neuman@apache.org>
> > > > 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 <
> ocket8888@gmail.com> 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".
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> >
>
>
>
>
>
Re: [EXTERNAL] Component leads
Posted by "Hoppal, Michael" <Mi...@comcast.com>.
I would love to start one for Traffic Ops.
Michael
On 11/13/19, 3:26 PM, "Gray, Jonathan" <Jo...@comcast.com> 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" <mi...@gmail.com> wrote:
I'll bite. I'd like to start one for TP.
On Wed, Nov 13, 2019 at 2:50 PM David Neuman <da...@gmail.com>
wrote:
> @Robert Butts <ro...@gmail.com>, 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 <ro...@apache.org> 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 <
> > Michael_Hoppal@comcast.com>
> > wrote:
> >
> > > Agreed with Jeremy I would be +1 on both ideas.
> > >
> > > On 11/13/19, 2:07 PM, "ocket 8888" <oc...@gmail.com> wrote:
> > >
> > > well, I actually like Dave's suggestion better than my own
> > >
> > > On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <
> > mitchell852@gmail.com
> > > >
> > > 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 <ne...@apache.org>
> > > 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 <oc...@gmail.com> 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".
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
>
Re: [EXTERNAL] Component leads
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
I'd volunteer for one on install/upgrade/lab.infra/automation/ci/cd.
Jonathan G
On 11/13/19, 3:07 PM, "Jeremy Mitchell" <mi...@gmail.com> wrote:
I'll bite. I'd like to start one for TP.
On Wed, Nov 13, 2019 at 2:50 PM David Neuman <da...@gmail.com>
wrote:
> @Robert Butts <ro...@gmail.com>, 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 <ro...@apache.org> 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 <
> > Michael_Hoppal@comcast.com>
> > wrote:
> >
> > > Agreed with Jeremy I would be +1 on both ideas.
> > >
> > > On 11/13/19, 2:07 PM, "ocket 8888" <oc...@gmail.com> wrote:
> > >
> > > well, I actually like Dave's suggestion better than my own
> > >
> > > On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <
> > mitchell852@gmail.com
> > > >
> > > 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 <ne...@apache.org>
> > > 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 <oc...@gmail.com> 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".
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
>
Re: [EXTERNAL] Component leads
Posted by Jeremy Mitchell <mi...@gmail.com>.
I'll bite. I'd like to start one for TP.
On Wed, Nov 13, 2019 at 2:50 PM David Neuman <da...@gmail.com>
wrote:
> @Robert Butts <ro...@gmail.com>, 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 <ro...@apache.org> 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 <
> > Michael_Hoppal@comcast.com>
> > wrote:
> >
> > > Agreed with Jeremy I would be +1 on both ideas.
> > >
> > > On 11/13/19, 2:07 PM, "ocket 8888" <oc...@gmail.com> wrote:
> > >
> > > well, I actually like Dave's suggestion better than my own
> > >
> > > On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <
> > mitchell852@gmail.com
> > > >
> > > 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 <ne...@apache.org>
> > > 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 <oc...@gmail.com> 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".
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
>
Re: [EXTERNAL] Component leads
Posted by David Neuman <da...@gmail.com>.
@Robert Butts <ro...@gmail.com>, 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 <ro...@apache.org> 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 <
> Michael_Hoppal@comcast.com>
> wrote:
>
> > Agreed with Jeremy I would be +1 on both ideas.
> >
> > On 11/13/19, 2:07 PM, "ocket 8888" <oc...@gmail.com> wrote:
> >
> > well, I actually like Dave's suggestion better than my own
> >
> > On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <
> mitchell852@gmail.com
> > >
> > 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 <ne...@apache.org>
> > 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 <oc...@gmail.com> 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".
> > > > >
> > > > >
> > > >
> > >
> >
> >
> >
>
Re: [EXTERNAL] Component leads
Posted by Robert O Butts <ro...@apache.org>.
+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 <Mi...@comcast.com>
wrote:
> Agreed with Jeremy I would be +1 on both ideas.
>
> On 11/13/19, 2:07 PM, "ocket 8888" <oc...@gmail.com> wrote:
>
> well, I actually like Dave's suggestion better than my own
>
> On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <mitchell852@gmail.com
> >
> 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 <ne...@apache.org>
> 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 <oc...@gmail.com> 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".
> > > >
> > > >
> > >
> >
>
>
>
Re: [EXTERNAL] Component leads
Posted by "Hoppal, Michael" <Mi...@comcast.com>.
Agreed with Jeremy I would be +1 on both ideas.
On 11/13/19, 2:07 PM, "ocket 8888" <oc...@gmail.com> wrote:
well, I actually like Dave's suggestion better than my own
On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <mi...@gmail.com>
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 <ne...@apache.org> 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 <oc...@gmail.com> 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".
> > >
> > >
> >
>
Re: [EXTERNAL] Component leads
Posted by ocket 8888 <oc...@gmail.com>.
well, I actually like Dave's suggestion better than my own
On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell <mi...@gmail.com>
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 <ne...@apache.org> 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 <oc...@gmail.com> 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".
> > >
> > >
> >
>
Re: [EXTERNAL] Component leads
Posted by Jeremy Mitchell <mi...@gmail.com>.
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 <ne...@apache.org> 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 <oc...@gmail.com> 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".
> >
> >
>
Re: [EXTERNAL] Component leads
Posted by Dave Neuman <ne...@apache.org>.
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 <oc...@gmail.com> 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".
>
>
Re: [EXTERNAL] Component leads
Posted by oc...@gmail.com.
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".
Re: [EXTERNAL] Component leads
Posted by Jeremy Mitchell <mi...@gmail.com>.
Agreed Rob. I didn't mean to imply that these "component leads" would have
more power. Rather that they'd facilitate and lead discussions (on
standards or roadmaps or whatever), be a point of contact for a release
manager, and keep things generally tidy and transparent in regard to that
component. That also means making sure email discussions are resolved and
not left hanging forever.
Any yes, jonathan, there's nothing stopping anyone from doing this today
but I don't see any of these things being done so maybe a different
approach would help. Maybe component lead is not the right term?
On Wed, Nov 13, 2019 at 10:45 AM Robert O Butts <ro...@apache.org> wrote:
> I'm +1 on all of those points, except "Drive standards for that component"
> and possibly "Manage issues related to that component." That is, the
> secretarial things, but not the authority things.
>
> My fear here is that these kind of "authority appointments" will lead to
> reduced consensus and community. Helping release management, issue
> triaging, and other bureaucratic tasks sounds great.
>
> But if this person is given more authority than any other community member
> to make decisions...that seems to go against the Apache Way. We do have
> experts on each product, language, and system; and hopefully members of the
> community generally defer to their expertise. But the Apache Way is to find
> consensus with the whole community, not to dictate or appoint a person to
> have overruling authority.
>
> Even if the "lead" is voted on, that allows a majority to dictate things,
> not to mention all the legitimacy problems of political electoral systems.
> Apache Consensus isn't democracy or majority rule, it's everyone working
> together to find a solution that makes everyone as happy as possible, not
> just one person or 51% of people. And if that dictating isn't going to
> happen, why appoint someone with that power?
>
> I know we have some heated discussions. Consensus can be hard. But I think
> we have a better product for it.
>
> Again, I'm a big +1 on all the managerial stuff. Maybe a more appropriate
> title would be something like "Product Secretary" or "Project Mentor?"
>
>
> On Wed, Nov 13, 2019 at 10:25 AM Gray, Jonathan <Jonathan_Gray@comcast.com
> >
> wrote:
>
> > What does this allow us to do that can't already be done today? The main
> > gain I can think of is helping users find knowledgeable people (which
> could
> > volunteer themselves today as part of a collaborative and inclusive
> > community). There's not anything presently stopping individual
> committers
> > from taking greater responsibilities for sections of code, issues, and
> PRs.
> >
> > Jonathan G
> >
> >
> > On 11/13/19, 9:59 AM, "Jeremy Mitchell" <mi...@apache.org> wrote:
> >
> > I would like to propose the idea of open source component leads for
> > TP, TO,
> > TR, TM and TS. I think having a component lead would help with the
> > following:
> >
> > - Help the release manager compile comprehensive release notes for
> that
> > component
> > - Help the release manager determine release scope related to that
> > component (what to not cherry pick to a release)
> > - Release candidate testing/validation for that component
> > - Manage issues related to that component (i.e. apply labels
> > (component,
> > type and severity)) and close old/irrelevant issues.
> > - Develop a first pass roadmap (maybe a roadmap.md file at the root
> of
> > the
> > component?) for that component and potentially create milestones and
> > facilitate discussion around the roadmap/milestones.
> > - Clean up old PRs for that component
> > - Drive standards for that component
> >
> > IMO these component leads would probably need the following
> > qualifications:
> >
> > - someone that works with the component on a day-to-day basis and is
> > obviously very experienced with the component.
> > - is a committer so they can do things like apply labels, create
> > milestones, merge PRs, etc.
> >
> > Ideally these component leads would represent different companies,
> > however,
> > maybe that is a goal and not a requirement at the moment.
> >
> > I bring this up because I think having component leads would help the
> > quality, organization and transparency of the TC project as a whole
> and
> > would provide potential contributors with a better vision of where TC
> > is
> > headed.
> >
> > Thoughts?
> >
> > Jeremy
> >
> >
> >
>
Re: [EXTERNAL] Component leads
Posted by Robert O Butts <ro...@apache.org>.
I'm +1 on all of those points, except "Drive standards for that component"
and possibly "Manage issues related to that component." That is, the
secretarial things, but not the authority things.
My fear here is that these kind of "authority appointments" will lead to
reduced consensus and community. Helping release management, issue
triaging, and other bureaucratic tasks sounds great.
But if this person is given more authority than any other community member
to make decisions...that seems to go against the Apache Way. We do have
experts on each product, language, and system; and hopefully members of the
community generally defer to their expertise. But the Apache Way is to find
consensus with the whole community, not to dictate or appoint a person to
have overruling authority.
Even if the "lead" is voted on, that allows a majority to dictate things,
not to mention all the legitimacy problems of political electoral systems.
Apache Consensus isn't democracy or majority rule, it's everyone working
together to find a solution that makes everyone as happy as possible, not
just one person or 51% of people. And if that dictating isn't going to
happen, why appoint someone with that power?
I know we have some heated discussions. Consensus can be hard. But I think
we have a better product for it.
Again, I'm a big +1 on all the managerial stuff. Maybe a more appropriate
title would be something like "Product Secretary" or "Project Mentor?"
On Wed, Nov 13, 2019 at 10:25 AM Gray, Jonathan <Jo...@comcast.com>
wrote:
> What does this allow us to do that can't already be done today? The main
> gain I can think of is helping users find knowledgeable people (which could
> volunteer themselves today as part of a collaborative and inclusive
> community). There's not anything presently stopping individual committers
> from taking greater responsibilities for sections of code, issues, and PRs.
>
> Jonathan G
>
>
> On 11/13/19, 9:59 AM, "Jeremy Mitchell" <mi...@apache.org> wrote:
>
> I would like to propose the idea of open source component leads for
> TP, TO,
> TR, TM and TS. I think having a component lead would help with the
> following:
>
> - Help the release manager compile comprehensive release notes for that
> component
> - Help the release manager determine release scope related to that
> component (what to not cherry pick to a release)
> - Release candidate testing/validation for that component
> - Manage issues related to that component (i.e. apply labels
> (component,
> type and severity)) and close old/irrelevant issues.
> - Develop a first pass roadmap (maybe a roadmap.md file at the root of
> the
> component?) for that component and potentially create milestones and
> facilitate discussion around the roadmap/milestones.
> - Clean up old PRs for that component
> - Drive standards for that component
>
> IMO these component leads would probably need the following
> qualifications:
>
> - someone that works with the component on a day-to-day basis and is
> obviously very experienced with the component.
> - is a committer so they can do things like apply labels, create
> milestones, merge PRs, etc.
>
> Ideally these component leads would represent different companies,
> however,
> maybe that is a goal and not a requirement at the moment.
>
> I bring this up because I think having component leads would help the
> quality, organization and transparency of the TC project as a whole and
> would provide potential contributors with a better vision of where TC
> is
> headed.
>
> Thoughts?
>
> Jeremy
>
>
>
Re: [EXTERNAL] Component leads
Posted by "Gray, Jonathan" <Jo...@comcast.com>.
What does this allow us to do that can't already be done today? The main gain I can think of is helping users find knowledgeable people (which could volunteer themselves today as part of a collaborative and inclusive community). There's not anything presently stopping individual committers from taking greater responsibilities for sections of code, issues, and PRs.
Jonathan G
On 11/13/19, 9:59 AM, "Jeremy Mitchell" <mi...@apache.org> wrote:
I would like to propose the idea of open source component leads for TP, TO,
TR, TM and TS. I think having a component lead would help with the
following:
- Help the release manager compile comprehensive release notes for that
component
- Help the release manager determine release scope related to that
component (what to not cherry pick to a release)
- Release candidate testing/validation for that component
- Manage issues related to that component (i.e. apply labels (component,
type and severity)) and close old/irrelevant issues.
- Develop a first pass roadmap (maybe a roadmap.md file at the root of the
component?) for that component and potentially create milestones and
facilitate discussion around the roadmap/milestones.
- Clean up old PRs for that component
- Drive standards for that component
IMO these component leads would probably need the following qualifications:
- someone that works with the component on a day-to-day basis and is
obviously very experienced with the component.
- is a committer so they can do things like apply labels, create
milestones, merge PRs, etc.
Ideally these component leads would represent different companies, however,
maybe that is a goal and not a requirement at the moment.
I bring this up because I think having component leads would help the
quality, organization and transparency of the TC project as a whole and
would provide potential contributors with a better vision of where TC is
headed.
Thoughts?
Jeremy
Re: [EXTERNAL] Component leads
Posted by "Hoppal, Michael" <Mi...@comcast.com>.
I think this is a GREAT idea!
I would very much be +1 on it.
I would add that the open source component leads would be voted on by the community and only hold the position on a defined period of time.
On 11/13/19, 9:58 AM, "Jeremy Mitchell" <mi...@apache.org> wrote:
I would like to propose the idea of open source component leads for TP, TO,
TR, TM and TS. I think having a component lead would help with the
following:
- Help the release manager compile comprehensive release notes for that
component
- Help the release manager determine release scope related to that
component (what to not cherry pick to a release)
- Release candidate testing/validation for that component
- Manage issues related to that component (i.e. apply labels (component,
type and severity)) and close old/irrelevant issues.
- Develop a first pass roadmap (maybe a roadmap.md file at the root of the
component?) for that component and potentially create milestones and
facilitate discussion around the roadmap/milestones.
- Clean up old PRs for that component
- Drive standards for that component
IMO these component leads would probably need the following qualifications:
- someone that works with the component on a day-to-day basis and is
obviously very experienced with the component.
- is a committer so they can do things like apply labels, create
milestones, merge PRs, etc.
Ideally these component leads would represent different companies, however,
maybe that is a goal and not a requirement at the moment.
I bring this up because I think having component leads would help the
quality, organization and transparency of the TC project as a whole and
would provide potential contributors with a better vision of where TC is
headed.
Thoughts?
Jeremy