Re: Off list major development

[Clint Wylie <cl...@imply.io>]

+1 for proposal template.

Do we also need to clarify the process that goes along with the proposals?
(It seems clear to me we've reached consensus in wanting a proposal
process, but less clear if we have a clear picture of or have reached
consensus on the process itself). Things like when voting happens,
appropriate PR timing, voting period, announcements to dev list,
significance of silence (implicit +1 or -1?), etc. Even if just adapting
Kafka's I think it might be a good idea to lay it out in this thread.

Beyond putting reference to this stuff in top level github readme and on
the website, is there anything more we should do to guide people that are
thinking about contributing to use the proposal process?

On Thu, Jan 31, 2019 at 2:47 PM Jonathan Wei <jo...@apache.org> wrote:

> That structure sounds good:
> - expanding rejected alternatives to a broader rationale section sounds
> good
> - I like "operational impact" as suggested by Slim and Gian more than the
> corresponding KIP terminology
> - Future work is a good addition
>
> For test plan, I don't have a very strong opinion on this, but I'm thinking
> it could make sense as an optional section (if someone has one, that's
> cool, if not, that's cool too, but perhaps having it present in the
> template would encourage ppl to think about testing strategies early on if
> they aren't already)
>
>
> On Thu, Jan 31, 2019 at 2:17 PM Jihoon Son <ji...@apache.org> wrote:
>
> > Thanks Gian.
> > The suggested template looks good to me.
> >
> > Jihoon
> >
> > On Thu, Jan 31, 2019 at 9:27 AM Gian Merlino <gi...@apache.org> wrote:
> >
> > > If it's not clear - I am agreeing with Jihoon and Slim that a separate
> > > "Rationale" section makes sense in addition to a couple other suggested
> > > tweaks.
> > >
> > > On Wed, Jan 30, 2019 at 3:46 PM Gian Merlino <gi...@apache.org> wrote:
> > >
> > > > I think it'd also be nice to tweak a couple parts of the KIP template
> > > > (Motivation; Public Interfaces; Proposed Changes; Compatibility,
> > > > Deprecation, and Migration Plan; Test Plan; Rejected Alternatives). A
> > > > couple people have suggested adding a "Rationale" section, how about
> > > adding
> > > > that and removing "Rejected alternatives" -- rolling them in
> together?
> > > And
> > > > dropping "test plan", since IMO that discussion can be deferred to
> the
> > PR
> > > > itself, when there is code ready. Finally, adding "future work",
> > > detailing
> > > > where this change might lead us.
> > > >
> > > > So in particular the template I am suggesting would be something like
> > > this.
> > > >
> > > > 1) Motivation: A description of the problem.
> > > > 2) Proposed changes: Should usually be the longest section. Should
> > > include
> > > > any changes that are proposed to user-facing interfaces
> (configuration
> > > > parameters, JSON query/ingest specs, SQL language, emitted metrics,
> and
> > > so
> > > > on).
> > > > 3) Rationale: A discussion of why this particular solution is the
> best
> > > > one. One good way to approach this is to discuss other alternative
> > > > solutions that you considered and decided against. This should also
> > > include
> > > > a discussion of any specific benefits or drawbacks you are aware of.
> > > > 4) Operational impact: Is anything going to be deprecated or removed
> by
> > > > this change? Is there a migration path that cluster operators need to
> > be
> > > > aware of? Will there be any effect on the ability to do a rolling
> > > upgrade,
> > > > or to do a rolling _downgrade_ if an operator wants to switch back
> to a
> > > > previous version?
> > > > 5) Future work: A discussion of things that you believe are out of
> > scope
> > > > for the particular proposal but would be nice follow-ups. It helps
> show
> > > > where a particular change could be leading us. There isn't any
> > commitment
> > > > that the proposal author will actually work on this stuff. It is okay
> > if
> > > > this section is empty.
> > > >
> > > > On Wed, Jan 30, 2019 at 3:14 PM Jihoon Son <ji...@apache.org>
> > wrote:
> > > >
> > > >> Thanks Eyal and Jon for starting the discussion about making a
> > template!
> > > >>
> > > >> The KIP template looks good, but I would like to add one more.
> > > >> The current template is:
> > > >>
> > > >> - Motivation
> > > >> - Public Interfaces
> > > >> - Proposed Changes
> > > >> - Compatibility, Deprecation, and Migration Plan
> > > >> - Test Plan
> > > >> - Rejected Alternatives
> > > >>
> > > >> It includes almost everything required for proposals, but I think
> it's
> > > >> missing why the author chose the proposed changes.
> > > >> So, I think it would be great if we can add 'Rationale' or 'Expected
> > > >> benefits and drawbacks'.
> > > >> People might include it by themselves in 'Motivation' or 'Proposed
> > > >> Changes', but it would be good if there's an explicit section to
> > > describe
> > > >> it.
> > > >>
> > > >> Best,
> > > >> Jihoon
> > > >>
> > > >
> > >
> >
>

Re: Off list major development

[Jonathan Wei <w3...@gmail.com>]

The proposal template PR is here:
https://github.com/apache/incubator-druid/pull/7062

Thanks,
Jon

On Tue, Feb 12, 2019 at 3:20 PM Jonathan Wei <jo...@apache.org> wrote:

> Cool, I'll go ahead and make a template based on the previous discussion.
>
> Thanks,
> Jon
>
> On Tue, Feb 12, 2019 at 9:16 AM Slim Bouguerra <bs...@apache.org> wrote:
>
>> @Gian All the above looks good to me.
>> I think having a template will tremendously help current devs and new
>> contributors, and will have a tremendous effect on the project !
>> Thanks
>>
>> On Tue, Feb 12, 2019 at 9:00 AM Gian Merlino <gi...@apache.org> wrote:
>>
>> > Does anyone have thoughts on the above suggestions?
>> >
>> > On Fri, Feb 1, 2019 at 2:16 PM Gian Merlino <gi...@apache.org> wrote:
>> >
>> > > I think we should clarify the process too. Might I suggest,
>> > >
>> > > 1) Add a GitHub issue template with proposal headers and some
>> description
>> > > of what each section should be, so people can fill them in easily.
>> > > 2) Suggest that for any change that would need a design review per
>> > > http://druid.io/community/, the author also creates a proposal issue
>> > > following that template. It can be very short if the change is simple.
>> > The
>> > > design discussion should take place on the proposal issue, and the
>> code
>> > > review should take place on the PR. A +1 on either the issue or the PR
>> > > would be considered a +1 for the design, while only a +1 on the PR
>> would
>> > be
>> > > considered a +1 for the code itself.
>> > > 3) Update http://druid.io/community/ and our CONTRIBUTING.md with
>> > > guidance about (2) and encouraging that the proposal issues are
>> created
>> > > early in the dev cycle.
>> > >
>> > > I am thinking of "suggest" rather than "require" in (2) so we can
>> start
>> > > slow and see how we like this process before making it mandatory.
>> > >
>> > > On Fri, Feb 1, 2019 at 2:22 AM Clint Wylie <cl...@imply.io>
>> wrote:
>> > >
>> > >> +1 for proposal template.
>> > >>
>> > >> Do we also need to clarify the process that goes along with the
>> > proposals?
>> > >> (It seems clear to me we've reached consensus in wanting a proposal
>> > >> process, but less clear if we have a clear picture of or have reached
>> > >> consensus on the process itself). Things like when voting happens,
>> > >> appropriate PR timing, voting period, announcements to dev list,
>> > >> significance of silence (implicit +1 or -1?), etc. Even if just
>> adapting
>> > >> Kafka's I think it might be a good idea to lay it out in this thread.
>> > >>
>> > >> Beyond putting reference to this stuff in top level github readme
>> and on
>> > >> the website, is there anything more we should do to guide people that
>> > are
>> > >> thinking about contributing to use the proposal process?
>> > >>
>> > >> On Thu, Jan 31, 2019 at 2:47 PM Jonathan Wei <jo...@apache.org>
>> wrote:
>> > >>
>> > >> > That structure sounds good:
>> > >> > - expanding rejected alternatives to a broader rationale section
>> > sounds
>> > >> > good
>> > >> > - I like "operational impact" as suggested by Slim and Gian more
>> than
>> > >> the
>> > >> > corresponding KIP terminology
>> > >> > - Future work is a good addition
>> > >> >
>> > >> > For test plan, I don't have a very strong opinion on this, but I'm
>> > >> thinking
>> > >> > it could make sense as an optional section (if someone has one,
>> that's
>> > >> > cool, if not, that's cool too, but perhaps having it present in the
>> > >> > template would encourage ppl to think about testing strategies
>> early
>> > on
>> > >> if
>> > >> > they aren't already)
>> > >> >
>> > >> >
>> > >> > On Thu, Jan 31, 2019 at 2:17 PM Jihoon Son <ji...@apache.org>
>> > >> wrote:
>> > >> >
>> > >> > > Thanks Gian.
>> > >> > > The suggested template looks good to me.
>> > >> > >
>> > >> > > Jihoon
>> > >> > >
>> > >> > > On Thu, Jan 31, 2019 at 9:27 AM Gian Merlino <gi...@apache.org>
>> > wrote:
>> > >> > >
>> > >> > > > If it's not clear - I am agreeing with Jihoon and Slim that a
>> > >> separate
>> > >> > > > "Rationale" section makes sense in addition to a couple other
>> > >> suggested
>> > >> > > > tweaks.
>> > >> > > >
>> > >> > > > On Wed, Jan 30, 2019 at 3:46 PM Gian Merlino <gi...@apache.org>
>> > >> wrote:
>> > >> > > >
>> > >> > > > > I think it'd also be nice to tweak a couple parts of the KIP
>> > >> template
>> > >> > > > > (Motivation; Public Interfaces; Proposed Changes;
>> Compatibility,
>> > >> > > > > Deprecation, and Migration Plan; Test Plan; Rejected
>> > >> Alternatives). A
>> > >> > > > > couple people have suggested adding a "Rationale" section,
>> how
>> > >> about
>> > >> > > > adding
>> > >> > > > > that and removing "Rejected alternatives" -- rolling them in
>> > >> > together?
>> > >> > > > And
>> > >> > > > > dropping "test plan", since IMO that discussion can be
>> deferred
>> > to
>> > >> > the
>> > >> > > PR
>> > >> > > > > itself, when there is code ready. Finally, adding "future
>> work",
>> > >> > > > detailing
>> > >> > > > > where this change might lead us.
>> > >> > > > >
>> > >> > > > > So in particular the template I am suggesting would be
>> something
>> > >> like
>> > >> > > > this.
>> > >> > > > >
>> > >> > > > > 1) Motivation: A description of the problem.
>> > >> > > > > 2) Proposed changes: Should usually be the longest section.
>> > Should
>> > >> > > > include
>> > >> > > > > any changes that are proposed to user-facing interfaces
>> > >> > (configuration
>> > >> > > > > parameters, JSON query/ingest specs, SQL language, emitted
>> > >> metrics,
>> > >> > and
>> > >> > > > so
>> > >> > > > > on).
>> > >> > > > > 3) Rationale: A discussion of why this particular solution is
>> > the
>> > >> > best
>> > >> > > > > one. One good way to approach this is to discuss other
>> > alternative
>> > >> > > > > solutions that you considered and decided against. This
>> should
>> > >> also
>> > >> > > > include
>> > >> > > > > a discussion of any specific benefits or drawbacks you are
>> aware
>> > >> of.
>> > >> > > > > 4) Operational impact: Is anything going to be deprecated or
>> > >> removed
>> > >> > by
>> > >> > > > > this change? Is there a migration path that cluster operators
>> > >> need to
>> > >> > > be
>> > >> > > > > aware of? Will there be any effect on the ability to do a
>> > rolling
>> > >> > > > upgrade,
>> > >> > > > > or to do a rolling _downgrade_ if an operator wants to switch
>> > back
>> > >> > to a
>> > >> > > > > previous version?
>> > >> > > > > 5) Future work: A discussion of things that you believe are
>> out
>> > of
>> > >> > > scope
>> > >> > > > > for the particular proposal but would be nice follow-ups. It
>> > helps
>> > >> > show
>> > >> > > > > where a particular change could be leading us. There isn't
>> any
>> > >> > > commitment
>> > >> > > > > that the proposal author will actually work on this stuff.
>> It is
>> > >> okay
>> > >> > > if
>> > >> > > > > this section is empty.
>> > >> > > > >
>> > >> > > > > On Wed, Jan 30, 2019 at 3:14 PM Jihoon Son <
>> > jihoonson@apache.org>
>> > >> > > wrote:
>> > >> > > > >
>> > >> > > > >> Thanks Eyal and Jon for starting the discussion about
>> making a
>> > >> > > template!
>> > >> > > > >>
>> > >> > > > >> The KIP template looks good, but I would like to add one
>> more.
>> > >> > > > >> The current template is:
>> > >> > > > >>
>> > >> > > > >> - Motivation
>> > >> > > > >> - Public Interfaces
>> > >> > > > >> - Proposed Changes
>> > >> > > > >> - Compatibility, Deprecation, and Migration Plan
>> > >> > > > >> - Test Plan
>> > >> > > > >> - Rejected Alternatives
>> > >> > > > >>
>> > >> > > > >> It includes almost everything required for proposals, but I
>> > think
>> > >> > it's
>> > >> > > > >> missing why the author chose the proposed changes.
>> > >> > > > >> So, I think it would be great if we can add 'Rationale' or
>> > >> 'Expected
>> > >> > > > >> benefits and drawbacks'.
>> > >> > > > >> People might include it by themselves in 'Motivation' or
>> > >> 'Proposed
>> > >> > > > >> Changes', but it would be good if there's an explicit
>> section
>> > to
>> > >> > > > describe
>> > >> > > > >> it.
>> > >> > > > >>
>> > >> > > > >> Best,
>> > >> > > > >> Jihoon
>> > >> > > > >>
>> > >> > > > >
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>>
>

Re: Off list major development

[Jonathan Wei <jo...@apache.org>]

Cool, I'll go ahead and make a template based on the previous discussion.

Thanks,
Jon

On Tue, Feb 12, 2019 at 9:16 AM Slim Bouguerra <bs...@apache.org> wrote:

> @Gian All the above looks good to me.
> I think having a template will tremendously help current devs and new
> contributors, and will have a tremendous effect on the project !
> Thanks
>
> On Tue, Feb 12, 2019 at 9:00 AM Gian Merlino <gi...@apache.org> wrote:
>
> > Does anyone have thoughts on the above suggestions?
> >
> > On Fri, Feb 1, 2019 at 2:16 PM Gian Merlino <gi...@apache.org> wrote:
> >
> > > I think we should clarify the process too. Might I suggest,
> > >
> > > 1) Add a GitHub issue template with proposal headers and some
> description
> > > of what each section should be, so people can fill them in easily.
> > > 2) Suggest that for any change that would need a design review per
> > > http://druid.io/community/, the author also creates a proposal issue
> > > following that template. It can be very short if the change is simple.
> > The
> > > design discussion should take place on the proposal issue, and the code
> > > review should take place on the PR. A +1 on either the issue or the PR
> > > would be considered a +1 for the design, while only a +1 on the PR
> would
> > be
> > > considered a +1 for the code itself.
> > > 3) Update http://druid.io/community/ and our CONTRIBUTING.md with
> > > guidance about (2) and encouraging that the proposal issues are created
> > > early in the dev cycle.
> > >
> > > I am thinking of "suggest" rather than "require" in (2) so we can start
> > > slow and see how we like this process before making it mandatory.
> > >
> > > On Fri, Feb 1, 2019 at 2:22 AM Clint Wylie <cl...@imply.io>
> wrote:
> > >
> > >> +1 for proposal template.
> > >>
> > >> Do we also need to clarify the process that goes along with the
> > proposals?
> > >> (It seems clear to me we've reached consensus in wanting a proposal
> > >> process, but less clear if we have a clear picture of or have reached
> > >> consensus on the process itself). Things like when voting happens,
> > >> appropriate PR timing, voting period, announcements to dev list,
> > >> significance of silence (implicit +1 or -1?), etc. Even if just
> adapting
> > >> Kafka's I think it might be a good idea to lay it out in this thread.
> > >>
> > >> Beyond putting reference to this stuff in top level github readme and
> on
> > >> the website, is there anything more we should do to guide people that
> > are
> > >> thinking about contributing to use the proposal process?
> > >>
> > >> On Thu, Jan 31, 2019 at 2:47 PM Jonathan Wei <jo...@apache.org>
> wrote:
> > >>
> > >> > That structure sounds good:
> > >> > - expanding rejected alternatives to a broader rationale section
> > sounds
> > >> > good
> > >> > - I like "operational impact" as suggested by Slim and Gian more
> than
> > >> the
> > >> > corresponding KIP terminology
> > >> > - Future work is a good addition
> > >> >
> > >> > For test plan, I don't have a very strong opinion on this, but I'm
> > >> thinking
> > >> > it could make sense as an optional section (if someone has one,
> that's
> > >> > cool, if not, that's cool too, but perhaps having it present in the
> > >> > template would encourage ppl to think about testing strategies early
> > on
> > >> if
> > >> > they aren't already)
> > >> >
> > >> >
> > >> > On Thu, Jan 31, 2019 at 2:17 PM Jihoon Son <ji...@apache.org>
> > >> wrote:
> > >> >
> > >> > > Thanks Gian.
> > >> > > The suggested template looks good to me.
> > >> > >
> > >> > > Jihoon
> > >> > >
> > >> > > On Thu, Jan 31, 2019 at 9:27 AM Gian Merlino <gi...@apache.org>
> > wrote:
> > >> > >
> > >> > > > If it's not clear - I am agreeing with Jihoon and Slim that a
> > >> separate
> > >> > > > "Rationale" section makes sense in addition to a couple other
> > >> suggested
> > >> > > > tweaks.
> > >> > > >
> > >> > > > On Wed, Jan 30, 2019 at 3:46 PM Gian Merlino <gi...@apache.org>
> > >> wrote:
> > >> > > >
> > >> > > > > I think it'd also be nice to tweak a couple parts of the KIP
> > >> template
> > >> > > > > (Motivation; Public Interfaces; Proposed Changes;
> Compatibility,
> > >> > > > > Deprecation, and Migration Plan; Test Plan; Rejected
> > >> Alternatives). A
> > >> > > > > couple people have suggested adding a "Rationale" section, how
> > >> about
> > >> > > > adding
> > >> > > > > that and removing "Rejected alternatives" -- rolling them in
> > >> > together?
> > >> > > > And
> > >> > > > > dropping "test plan", since IMO that discussion can be
> deferred
> > to
> > >> > the
> > >> > > PR
> > >> > > > > itself, when there is code ready. Finally, adding "future
> work",
> > >> > > > detailing
> > >> > > > > where this change might lead us.
> > >> > > > >
> > >> > > > > So in particular the template I am suggesting would be
> something
> > >> like
> > >> > > > this.
> > >> > > > >
> > >> > > > > 1) Motivation: A description of the problem.
> > >> > > > > 2) Proposed changes: Should usually be the longest section.
> > Should
> > >> > > > include
> > >> > > > > any changes that are proposed to user-facing interfaces
> > >> > (configuration
> > >> > > > > parameters, JSON query/ingest specs, SQL language, emitted
> > >> metrics,
> > >> > and
> > >> > > > so
> > >> > > > > on).
> > >> > > > > 3) Rationale: A discussion of why this particular solution is
> > the
> > >> > best
> > >> > > > > one. One good way to approach this is to discuss other
> > alternative
> > >> > > > > solutions that you considered and decided against. This should
> > >> also
> > >> > > > include
> > >> > > > > a discussion of any specific benefits or drawbacks you are
> aware
> > >> of.
> > >> > > > > 4) Operational impact: Is anything going to be deprecated or
> > >> removed
> > >> > by
> > >> > > > > this change? Is there a migration path that cluster operators
> > >> need to
> > >> > > be
> > >> > > > > aware of? Will there be any effect on the ability to do a
> > rolling
> > >> > > > upgrade,
> > >> > > > > or to do a rolling _downgrade_ if an operator wants to switch
> > back
> > >> > to a
> > >> > > > > previous version?
> > >> > > > > 5) Future work: A discussion of things that you believe are
> out
> > of
> > >> > > scope
> > >> > > > > for the particular proposal but would be nice follow-ups. It
> > helps
> > >> > show
> > >> > > > > where a particular change could be leading us. There isn't any
> > >> > > commitment
> > >> > > > > that the proposal author will actually work on this stuff. It
> is
> > >> okay
> > >> > > if
> > >> > > > > this section is empty.
> > >> > > > >
> > >> > > > > On Wed, Jan 30, 2019 at 3:14 PM Jihoon Son <
> > jihoonson@apache.org>
> > >> > > wrote:
> > >> > > > >
> > >> > > > >> Thanks Eyal and Jon for starting the discussion about making
> a
> > >> > > template!
> > >> > > > >>
> > >> > > > >> The KIP template looks good, but I would like to add one
> more.
> > >> > > > >> The current template is:
> > >> > > > >>
> > >> > > > >> - Motivation
> > >> > > > >> - Public Interfaces
> > >> > > > >> - Proposed Changes
> > >> > > > >> - Compatibility, Deprecation, and Migration Plan
> > >> > > > >> - Test Plan
> > >> > > > >> - Rejected Alternatives
> > >> > > > >>
> > >> > > > >> It includes almost everything required for proposals, but I
> > think
> > >> > it's
> > >> > > > >> missing why the author chose the proposed changes.
> > >> > > > >> So, I think it would be great if we can add 'Rationale' or
> > >> 'Expected
> > >> > > > >> benefits and drawbacks'.
> > >> > > > >> People might include it by themselves in 'Motivation' or
> > >> 'Proposed
> > >> > > > >> Changes', but it would be good if there's an explicit section
> > to
> > >> > > > describe
> > >> > > > >> it.
> > >> > > > >>
> > >> > > > >> Best,
> > >> > > > >> Jihoon
> > >> > > > >>
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

Re: Off list major development

[Slim Bouguerra <bs...@apache.org>]

@Gian All the above looks good to me.
I think having a template will tremendously help current devs and new
contributors, and will have a tremendous effect on the project !
Thanks

On Tue, Feb 12, 2019 at 9:00 AM Gian Merlino <gi...@apache.org> wrote:

> Does anyone have thoughts on the above suggestions?
>
> On Fri, Feb 1, 2019 at 2:16 PM Gian Merlino <gi...@apache.org> wrote:
>
> > I think we should clarify the process too. Might I suggest,
> >
> > 1) Add a GitHub issue template with proposal headers and some description
> > of what each section should be, so people can fill them in easily.
> > 2) Suggest that for any change that would need a design review per
> > http://druid.io/community/, the author also creates a proposal issue
> > following that template. It can be very short if the change is simple.
> The
> > design discussion should take place on the proposal issue, and the code
> > review should take place on the PR. A +1 on either the issue or the PR
> > would be considered a +1 for the design, while only a +1 on the PR would
> be
> > considered a +1 for the code itself.
> > 3) Update http://druid.io/community/ and our CONTRIBUTING.md with
> > guidance about (2) and encouraging that the proposal issues are created
> > early in the dev cycle.
> >
> > I am thinking of "suggest" rather than "require" in (2) so we can start
> > slow and see how we like this process before making it mandatory.
> >
> > On Fri, Feb 1, 2019 at 2:22 AM Clint Wylie <cl...@imply.io> wrote:
> >
> >> +1 for proposal template.
> >>
> >> Do we also need to clarify the process that goes along with the
> proposals?
> >> (It seems clear to me we've reached consensus in wanting a proposal
> >> process, but less clear if we have a clear picture of or have reached
> >> consensus on the process itself). Things like when voting happens,
> >> appropriate PR timing, voting period, announcements to dev list,
> >> significance of silence (implicit +1 or -1?), etc. Even if just adapting
> >> Kafka's I think it might be a good idea to lay it out in this thread.
> >>
> >> Beyond putting reference to this stuff in top level github readme and on
> >> the website, is there anything more we should do to guide people that
> are
> >> thinking about contributing to use the proposal process?
> >>
> >> On Thu, Jan 31, 2019 at 2:47 PM Jonathan Wei <jo...@apache.org> wrote:
> >>
> >> > That structure sounds good:
> >> > - expanding rejected alternatives to a broader rationale section
> sounds
> >> > good
> >> > - I like "operational impact" as suggested by Slim and Gian more than
> >> the
> >> > corresponding KIP terminology
> >> > - Future work is a good addition
> >> >
> >> > For test plan, I don't have a very strong opinion on this, but I'm
> >> thinking
> >> > it could make sense as an optional section (if someone has one, that's
> >> > cool, if not, that's cool too, but perhaps having it present in the
> >> > template would encourage ppl to think about testing strategies early
> on
> >> if
> >> > they aren't already)
> >> >
> >> >
> >> > On Thu, Jan 31, 2019 at 2:17 PM Jihoon Son <ji...@apache.org>
> >> wrote:
> >> >
> >> > > Thanks Gian.
> >> > > The suggested template looks good to me.
> >> > >
> >> > > Jihoon
> >> > >
> >> > > On Thu, Jan 31, 2019 at 9:27 AM Gian Merlino <gi...@apache.org>
> wrote:
> >> > >
> >> > > > If it's not clear - I am agreeing with Jihoon and Slim that a
> >> separate
> >> > > > "Rationale" section makes sense in addition to a couple other
> >> suggested
> >> > > > tweaks.
> >> > > >
> >> > > > On Wed, Jan 30, 2019 at 3:46 PM Gian Merlino <gi...@apache.org>
> >> wrote:
> >> > > >
> >> > > > > I think it'd also be nice to tweak a couple parts of the KIP
> >> template
> >> > > > > (Motivation; Public Interfaces; Proposed Changes; Compatibility,
> >> > > > > Deprecation, and Migration Plan; Test Plan; Rejected
> >> Alternatives). A
> >> > > > > couple people have suggested adding a "Rationale" section, how
> >> about
> >> > > > adding
> >> > > > > that and removing "Rejected alternatives" -- rolling them in
> >> > together?
> >> > > > And
> >> > > > > dropping "test plan", since IMO that discussion can be deferred
> to
> >> > the
> >> > > PR
> >> > > > > itself, when there is code ready. Finally, adding "future work",
> >> > > > detailing
> >> > > > > where this change might lead us.
> >> > > > >
> >> > > > > So in particular the template I am suggesting would be something
> >> like
> >> > > > this.
> >> > > > >
> >> > > > > 1) Motivation: A description of the problem.
> >> > > > > 2) Proposed changes: Should usually be the longest section.
> Should
> >> > > > include
> >> > > > > any changes that are proposed to user-facing interfaces
> >> > (configuration
> >> > > > > parameters, JSON query/ingest specs, SQL language, emitted
> >> metrics,
> >> > and
> >> > > > so
> >> > > > > on).
> >> > > > > 3) Rationale: A discussion of why this particular solution is
> the
> >> > best
> >> > > > > one. One good way to approach this is to discuss other
> alternative
> >> > > > > solutions that you considered and decided against. This should
> >> also
> >> > > > include
> >> > > > > a discussion of any specific benefits or drawbacks you are aware
> >> of.
> >> > > > > 4) Operational impact: Is anything going to be deprecated or
> >> removed
> >> > by
> >> > > > > this change? Is there a migration path that cluster operators
> >> need to
> >> > > be
> >> > > > > aware of? Will there be any effect on the ability to do a
> rolling
> >> > > > upgrade,
> >> > > > > or to do a rolling _downgrade_ if an operator wants to switch
> back
> >> > to a
> >> > > > > previous version?
> >> > > > > 5) Future work: A discussion of things that you believe are out
> of
> >> > > scope
> >> > > > > for the particular proposal but would be nice follow-ups. It
> helps
> >> > show
> >> > > > > where a particular change could be leading us. There isn't any
> >> > > commitment
> >> > > > > that the proposal author will actually work on this stuff. It is
> >> okay
> >> > > if
> >> > > > > this section is empty.
> >> > > > >
> >> > > > > On Wed, Jan 30, 2019 at 3:14 PM Jihoon Son <
> jihoonson@apache.org>
> >> > > wrote:
> >> > > > >
> >> > > > >> Thanks Eyal and Jon for starting the discussion about making a
> >> > > template!
> >> > > > >>
> >> > > > >> The KIP template looks good, but I would like to add one more.
> >> > > > >> The current template is:
> >> > > > >>
> >> > > > >> - Motivation
> >> > > > >> - Public Interfaces
> >> > > > >> - Proposed Changes
> >> > > > >> - Compatibility, Deprecation, and Migration Plan
> >> > > > >> - Test Plan
> >> > > > >> - Rejected Alternatives
> >> > > > >>
> >> > > > >> It includes almost everything required for proposals, but I
> think
> >> > it's
> >> > > > >> missing why the author chose the proposed changes.
> >> > > > >> So, I think it would be great if we can add 'Rationale' or
> >> 'Expected
> >> > > > >> benefits and drawbacks'.
> >> > > > >> People might include it by themselves in 'Motivation' or
> >> 'Proposed
> >> > > > >> Changes', but it would be good if there's an explicit section
> to
> >> > > > describe
> >> > > > >> it.
> >> > > > >>
> >> > > > >> Best,
> >> > > > >> Jihoon
> >> > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

Re: Off list major development

[Gian Merlino <gi...@apache.org>]

Does anyone have thoughts on the above suggestions?

On Fri, Feb 1, 2019 at 2:16 PM Gian Merlino <gi...@apache.org> wrote:

> I think we should clarify the process too. Might I suggest,
>
> 1) Add a GitHub issue template with proposal headers and some description
> of what each section should be, so people can fill them in easily.
> 2) Suggest that for any change that would need a design review per
> http://druid.io/community/, the author also creates a proposal issue
> following that template. It can be very short if the change is simple. The
> design discussion should take place on the proposal issue, and the code
> review should take place on the PR. A +1 on either the issue or the PR
> would be considered a +1 for the design, while only a +1 on the PR would be
> considered a +1 for the code itself.
> 3) Update http://druid.io/community/ and our CONTRIBUTING.md with
> guidance about (2) and encouraging that the proposal issues are created
> early in the dev cycle.
>
> I am thinking of "suggest" rather than "require" in (2) so we can start
> slow and see how we like this process before making it mandatory.
>
> On Fri, Feb 1, 2019 at 2:22 AM Clint Wylie <cl...@imply.io> wrote:
>
>> +1 for proposal template.
>>
>> Do we also need to clarify the process that goes along with the proposals?
>> (It seems clear to me we've reached consensus in wanting a proposal
>> process, but less clear if we have a clear picture of or have reached
>> consensus on the process itself). Things like when voting happens,
>> appropriate PR timing, voting period, announcements to dev list,
>> significance of silence (implicit +1 or -1?), etc. Even if just adapting
>> Kafka's I think it might be a good idea to lay it out in this thread.
>>
>> Beyond putting reference to this stuff in top level github readme and on
>> the website, is there anything more we should do to guide people that are
>> thinking about contributing to use the proposal process?
>>
>> On Thu, Jan 31, 2019 at 2:47 PM Jonathan Wei <jo...@apache.org> wrote:
>>
>> > That structure sounds good:
>> > - expanding rejected alternatives to a broader rationale section sounds
>> > good
>> > - I like "operational impact" as suggested by Slim and Gian more than
>> the
>> > corresponding KIP terminology
>> > - Future work is a good addition
>> >
>> > For test plan, I don't have a very strong opinion on this, but I'm
>> thinking
>> > it could make sense as an optional section (if someone has one, that's
>> > cool, if not, that's cool too, but perhaps having it present in the
>> > template would encourage ppl to think about testing strategies early on
>> if
>> > they aren't already)
>> >
>> >
>> > On Thu, Jan 31, 2019 at 2:17 PM Jihoon Son <ji...@apache.org>
>> wrote:
>> >
>> > > Thanks Gian.
>> > > The suggested template looks good to me.
>> > >
>> > > Jihoon
>> > >
>> > > On Thu, Jan 31, 2019 at 9:27 AM Gian Merlino <gi...@apache.org> wrote:
>> > >
>> > > > If it's not clear - I am agreeing with Jihoon and Slim that a
>> separate
>> > > > "Rationale" section makes sense in addition to a couple other
>> suggested
>> > > > tweaks.
>> > > >
>> > > > On Wed, Jan 30, 2019 at 3:46 PM Gian Merlino <gi...@apache.org>
>> wrote:
>> > > >
>> > > > > I think it'd also be nice to tweak a couple parts of the KIP
>> template
>> > > > > (Motivation; Public Interfaces; Proposed Changes; Compatibility,
>> > > > > Deprecation, and Migration Plan; Test Plan; Rejected
>> Alternatives). A
>> > > > > couple people have suggested adding a "Rationale" section, how
>> about
>> > > > adding
>> > > > > that and removing "Rejected alternatives" -- rolling them in
>> > together?
>> > > > And
>> > > > > dropping "test plan", since IMO that discussion can be deferred to
>> > the
>> > > PR
>> > > > > itself, when there is code ready. Finally, adding "future work",
>> > > > detailing
>> > > > > where this change might lead us.
>> > > > >
>> > > > > So in particular the template I am suggesting would be something
>> like
>> > > > this.
>> > > > >
>> > > > > 1) Motivation: A description of the problem.
>> > > > > 2) Proposed changes: Should usually be the longest section. Should
>> > > > include
>> > > > > any changes that are proposed to user-facing interfaces
>> > (configuration
>> > > > > parameters, JSON query/ingest specs, SQL language, emitted
>> metrics,
>> > and
>> > > > so
>> > > > > on).
>> > > > > 3) Rationale: A discussion of why this particular solution is the
>> > best
>> > > > > one. One good way to approach this is to discuss other alternative
>> > > > > solutions that you considered and decided against. This should
>> also
>> > > > include
>> > > > > a discussion of any specific benefits or drawbacks you are aware
>> of.
>> > > > > 4) Operational impact: Is anything going to be deprecated or
>> removed
>> > by
>> > > > > this change? Is there a migration path that cluster operators
>> need to
>> > > be
>> > > > > aware of? Will there be any effect on the ability to do a rolling
>> > > > upgrade,
>> > > > > or to do a rolling _downgrade_ if an operator wants to switch back
>> > to a
>> > > > > previous version?
>> > > > > 5) Future work: A discussion of things that you believe are out of
>> > > scope
>> > > > > for the particular proposal but would be nice follow-ups. It helps
>> > show
>> > > > > where a particular change could be leading us. There isn't any
>> > > commitment
>> > > > > that the proposal author will actually work on this stuff. It is
>> okay
>> > > if
>> > > > > this section is empty.
>> > > > >
>> > > > > On Wed, Jan 30, 2019 at 3:14 PM Jihoon Son <ji...@apache.org>
>> > > wrote:
>> > > > >
>> > > > >> Thanks Eyal and Jon for starting the discussion about making a
>> > > template!
>> > > > >>
>> > > > >> The KIP template looks good, but I would like to add one more.
>> > > > >> The current template is:
>> > > > >>
>> > > > >> - Motivation
>> > > > >> - Public Interfaces
>> > > > >> - Proposed Changes
>> > > > >> - Compatibility, Deprecation, and Migration Plan
>> > > > >> - Test Plan
>> > > > >> - Rejected Alternatives
>> > > > >>
>> > > > >> It includes almost everything required for proposals, but I think
>> > it's
>> > > > >> missing why the author chose the proposed changes.
>> > > > >> So, I think it would be great if we can add 'Rationale' or
>> 'Expected
>> > > > >> benefits and drawbacks'.
>> > > > >> People might include it by themselves in 'Motivation' or
>> 'Proposed
>> > > > >> Changes', but it would be good if there's an explicit section to
>> > > > describe
>> > > > >> it.
>> > > > >>
>> > > > >> Best,
>> > > > >> Jihoon
>> > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: Off list major development

[Gian Merlino <gi...@apache.org>]

I think we should clarify the process too. Might I suggest,

1) Add a GitHub issue template with proposal headers and some description
of what each section should be, so people can fill them in easily.
2) Suggest that for any change that would need a design review per
http://druid.io/community/, the author also creates a proposal issue
following that template. It can be very short if the change is simple. The
design discussion should take place on the proposal issue, and the code
review should take place on the PR. A +1 on either the issue or the PR
would be considered a +1 for the design, while only a +1 on the PR would be
considered a +1 for the code itself.
3) Update http://druid.io/community/ and our CONTRIBUTING.md with guidance
about (2) and encouraging that the proposal issues are created early in the
dev cycle.

I am thinking of "suggest" rather than "require" in (2) so we can start
slow and see how we like this process before making it mandatory.

On Fri, Feb 1, 2019 at 2:22 AM Clint Wylie <cl...@imply.io> wrote:

> +1 for proposal template.
>
> Do we also need to clarify the process that goes along with the proposals?
> (It seems clear to me we've reached consensus in wanting a proposal
> process, but less clear if we have a clear picture of or have reached
> consensus on the process itself). Things like when voting happens,
> appropriate PR timing, voting period, announcements to dev list,
> significance of silence (implicit +1 or -1?), etc. Even if just adapting
> Kafka's I think it might be a good idea to lay it out in this thread.
>
> Beyond putting reference to this stuff in top level github readme and on
> the website, is there anything more we should do to guide people that are
> thinking about contributing to use the proposal process?
>
> On Thu, Jan 31, 2019 at 2:47 PM Jonathan Wei <jo...@apache.org> wrote:
>
> > That structure sounds good:
> > - expanding rejected alternatives to a broader rationale section sounds
> > good
> > - I like "operational impact" as suggested by Slim and Gian more than the
> > corresponding KIP terminology
> > - Future work is a good addition
> >
> > For test plan, I don't have a very strong opinion on this, but I'm
> thinking
> > it could make sense as an optional section (if someone has one, that's
> > cool, if not, that's cool too, but perhaps having it present in the
> > template would encourage ppl to think about testing strategies early on
> if
> > they aren't already)
> >
> >
> > On Thu, Jan 31, 2019 at 2:17 PM Jihoon Son <ji...@apache.org> wrote:
> >
> > > Thanks Gian.
> > > The suggested template looks good to me.
> > >
> > > Jihoon
> > >
> > > On Thu, Jan 31, 2019 at 9:27 AM Gian Merlino <gi...@apache.org> wrote:
> > >
> > > > If it's not clear - I am agreeing with Jihoon and Slim that a
> separate
> > > > "Rationale" section makes sense in addition to a couple other
> suggested
> > > > tweaks.
> > > >
> > > > On Wed, Jan 30, 2019 at 3:46 PM Gian Merlino <gi...@apache.org>
> wrote:
> > > >
> > > > > I think it'd also be nice to tweak a couple parts of the KIP
> template
> > > > > (Motivation; Public Interfaces; Proposed Changes; Compatibility,
> > > > > Deprecation, and Migration Plan; Test Plan; Rejected
> Alternatives). A
> > > > > couple people have suggested adding a "Rationale" section, how
> about
> > > > adding
> > > > > that and removing "Rejected alternatives" -- rolling them in
> > together?
> > > > And
> > > > > dropping "test plan", since IMO that discussion can be deferred to
> > the
> > > PR
> > > > > itself, when there is code ready. Finally, adding "future work",
> > > > detailing
> > > > > where this change might lead us.
> > > > >
> > > > > So in particular the template I am suggesting would be something
> like
> > > > this.
> > > > >
> > > > > 1) Motivation: A description of the problem.
> > > > > 2) Proposed changes: Should usually be the longest section. Should
> > > > include
> > > > > any changes that are proposed to user-facing interfaces
> > (configuration
> > > > > parameters, JSON query/ingest specs, SQL language, emitted metrics,
> > and
> > > > so
> > > > > on).
> > > > > 3) Rationale: A discussion of why this particular solution is the
> > best
> > > > > one. One good way to approach this is to discuss other alternative
> > > > > solutions that you considered and decided against. This should also
> > > > include
> > > > > a discussion of any specific benefits or drawbacks you are aware
> of.
> > > > > 4) Operational impact: Is anything going to be deprecated or
> removed
> > by
> > > > > this change? Is there a migration path that cluster operators need
> to
> > > be
> > > > > aware of? Will there be any effect on the ability to do a rolling
> > > > upgrade,
> > > > > or to do a rolling _downgrade_ if an operator wants to switch back
> > to a
> > > > > previous version?
> > > > > 5) Future work: A discussion of things that you believe are out of
> > > scope
> > > > > for the particular proposal but would be nice follow-ups. It helps
> > show
> > > > > where a particular change could be leading us. There isn't any
> > > commitment
> > > > > that the proposal author will actually work on this stuff. It is
> okay
> > > if
> > > > > this section is empty.
> > > > >
> > > > > On Wed, Jan 30, 2019 at 3:14 PM Jihoon Son <ji...@apache.org>
> > > wrote:
> > > > >
> > > > >> Thanks Eyal and Jon for starting the discussion about making a
> > > template!
> > > > >>
> > > > >> The KIP template looks good, but I would like to add one more.
> > > > >> The current template is:
> > > > >>
> > > > >> - Motivation
> > > > >> - Public Interfaces
> > > > >> - Proposed Changes
> > > > >> - Compatibility, Deprecation, and Migration Plan
> > > > >> - Test Plan
> > > > >> - Rejected Alternatives
> > > > >>
> > > > >> It includes almost everything required for proposals, but I think
> > it's
> > > > >> missing why the author chose the proposed changes.
> > > > >> So, I think it would be great if we can add 'Rationale' or
> 'Expected
> > > > >> benefits and drawbacks'.
> > > > >> People might include it by themselves in 'Motivation' or 'Proposed
> > > > >> Changes', but it would be good if there's an explicit section to
> > > > describe
> > > > >> it.
> > > > >>
> > > > >> Best,
> > > > >> Jihoon
> > > > >>
> > > > >
> > > >
> > >
> >
>