You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Kaxil Naik <ka...@gmail.com> on 2020/09/06 10:56:24 UTC
PR Descriptions
Hi all,
I have brought this topic on multiple occasions earlier too on the mailing
list. I sincerely request all the contributors and Committers (including
myself) that we add PR descriptions.
This helps the community understand what the PRs do and abides by the ASF
motto about "Community above Code", many users lands to the PR after
checking change log and having to look at the code to understand the PR is
not ideal. Adding descriptions of "most" of the PRs literally does not take
more than a minute.
We previously had automation around it but we removed because of small
exceptions where the PR title can be self explanatory.
We should not ignore rules (I am talking about PR template that says " ^
Add meaningful description above ". Again it is fine if the PR title is
self explanatory but not otherwise.
Regards,
Kaxil
Re: PR Descriptions
Posted by Ash Berlin-Taylor <as...@apache.org>.
We know the context _right_ now, but future us in 3 months will have
forgotten it all, so things we can do to help us remember what a PR
introduced the better.
(I also personally favour having the "PR description" in the commit
message, not just the PR, that way it's viewable even should we ever
decide to move away from GitHub.)
On Sep 10 2020, at 4:06 pm, Tomasz Urbaszek
<to...@polidea.com> wrote:
> I agree with Jarek - as long as we cannot enforce it we as reviewers
> should do our best to have the description in place.
>
> On a general note, we should always remember that even if we know each
> other and communicate through different channels (slack, calls, etc)
> other people won't know the context of the change if there's no
> description.
>
> Tomek
>
>
> On Thu, Sep 10, 2020 at 4:50 PM Jarek Potiuk
> <Ja...@polidea.com> wrote:
>>
>> I am afraid people won't read it anyway. the PR template should be as
>> short as possible. I think this one is really something that should
>> be on reviewers. It's one of those things that is hard to automate or
>> delegate.
>>
>> If the reviewer does not understand what the PR from the description,
>> it should be the first point to say "please provider context, I am not
>> sure what the change does" even before looking at the code IMHO. If we
>> all do that - this will be much more effective than writing it in the
>> template.
>>
>> J
>>
>> On Thu, Sep 10, 2020 at 3:14 PM Ry Walker <ry...@rywalker.com> wrote:
>> >
>> > Maybe modify the template to include some copy from your email in
>> it :)
>> >
>> > On Sun, Sep 6, 2020 at 6:56 AM Kaxil Naik <ka...@gmail.com> wrote:
>> >
>> > > Hi all,
>> > >
>> > > I have brought this topic on multiple occasions earlier too on
>> the mailing
>> > > list. I sincerely request all the contributors and Committers (including
>> > > myself) that we add PR descriptions.
>> > >
>> > > This helps the community understand what the PRs do and abides by
>> the ASF
>> > > motto about "Community above Code", many users lands to the PR after
>> > > checking change log and having to look at the code to understand
>> the PR is
>> > > not ideal. Adding descriptions of "most" of the PRs literally
>> does not take
>> > > more than a minute.
>> > >
>> > > We previously had automation around it but we removed because of small
>> > > exceptions where the PR title can be self explanatory.
>> > >
>> > > We should not ignore rules (I am talking about PR template that
>> says " ^
>> > > Add meaningful description above ". Again it is fine if the PR
>> title is
>> > > self explanatory but not otherwise.
>> > >
>> > > Regards,
>> > > Kaxil
>> > >
>>
>>
>>
>> --
>>
>> Jarek Potiuk
>> Polidea | Principal Software Engineer
>>
>> M: +48 660 796 129
>
>
>
> --
>
> Tomasz Urbaszek
> Polidea | Software Engineer
>
> M: +48 505 628 493
> E: tomasz.urbaszek@polidea.com
>
> Unique Tech
> Check out our projects!
>
Re: PR Descriptions
Posted by Kaxil Naik <ka...@gmail.com>.
I agree we just need to take care of it as reviewers to inform the PR
authors.
On Thu, Sep 10, 2020 at 4:30 PM Ash Berlin-Taylor <as...@apache.org> wrote:
> Yeah, that's what I do (or try to. No one is perfect.)
>
> I'm sure it's written down _somewhere_ but I've long since forgotten
> where I picked up that habit from. It's almost an extention to point 5
> in https://chris.beams.io/posts/git-commit/#imperative (which we already
> point to).
>
> -a
>
> On Sep 10 2020, at 4:24 pm, Jarek Potiuk <Ja...@polidea.com> wrote:
>
> > Also on that, As far as I remember the "unwritten" rule that Ash
> mentioned
> > some time ago as far as I remember the "subject" of the commit is best if
> > it completes the sentence:
> >
> > "This commit when merged ...." ("fixes this and that" for example).
> >
> > And then the context on why we are doing it should follow. For some
> > time I
> > try to follow this quite rigorously with some of the heavier changes :)
> >
> > Do I remember it well Ash?
> >
> > J,
> >
> >
> > On Thu, Sep 10, 2020 at 5:07 PM Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com>
> > wrote:
> >
> >> I agree with Jarek - as long as we cannot enforce it we as reviewers
> >> should do our best to have the description in place.
> >>
> >> On a general note, we should always remember that even if we know each
> >> other and communicate through different channels (slack, calls, etc)
> >> other people won't know the context of the change if there's no
> >> description.
> >>
> >> Tomek
> >>
> >>
> >> On Thu, Sep 10, 2020 at 4:50 PM Jarek Potiuk <Ja...@polidea.com>
> >> wrote:
> >> >
> >> > I am afraid people won't read it anyway. the PR template should be as
> >> > short as possible. I think this one is really something that should
> >> > be on reviewers. It's one of those things that is hard to automate or
> >> > delegate.
> >> >
> >> > If the reviewer does not understand what the PR from the description,
> >> > it should be the first point to say "please provider context, I am not
> >> > sure what the change does" even before looking at the code IMHO. If we
> >> > all do that - this will be much more effective than writing it in the
> >> > template.
> >> >
> >> > J
> >> >
> >> > On Thu, Sep 10, 2020 at 3:14 PM Ry Walker <ry...@rywalker.com> wrote:
> >> > >
> >> > > Maybe modify the template to include some copy from your email in
> >> it :)
> >> > >
> >> > > On Sun, Sep 6, 2020 at 6:56 AM Kaxil Naik <ka...@gmail.com>
> wrote:
> >> > >
> >> > > > Hi all,
> >> > > >
> >> > > > I have brought this topic on multiple occasions earlier too on the
> >> mailing
> >> > > > list. I sincerely request all the contributors and Committers
> >> (including
> >> > > > myself) that we add PR descriptions.
> >> > > >
> >> > > > This helps the community understand what the PRs do and abides by
> >> the ASF
> >> > > > motto about "Community above Code", many users lands to the PR
> after
> >> > > > checking change log and having to look at the code to
> >> understand the
> >> PR is
> >> > > > not ideal. Adding descriptions of "most" of the PRs literally does
> >> not take
> >> > > > more than a minute.
> >> > > >
> >> > > > We previously had automation around it but we removed because of
> >> small
> >> > > > exceptions where the PR title can be self explanatory.
> >> > > >
> >> > > > We should not ignore rules (I am talking about PR template that
> says
> >> " ^
> >> > > > Add meaningful description above ". Again it is fine if the PR
> title
> >> is
> >> > > > self explanatory but not otherwise.
> >> > > >
> >> > > > Regards,
> >> > > > Kaxil
> >> > > >
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > Jarek Potiuk
> >> > Polidea | Principal Software Engineer
> >> >
> >> > M: +48 660 796 129
> >>
> >>
> >>
> >> --
> >>
> >> Tomasz Urbaszek
> >> Polidea | Software Engineer
> >>
> >> M: +48 505 628 493
> >> E: tomasz.urbaszek@polidea.com
> >>
> >> Unique Tech
> >> Check out our projects!
> >>
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
>
Re: PR Descriptions
Posted by Jarek Potiuk <Ja...@polidea.com>.
I definitely prefer the "This commit when merged ..." rule than the
"imperative" one. It's so simple to remember ;).
And yeah - I mostly write the commit messages for the future self :).
And it's best if you describe the context the first time you push the
commit and make a draft PR - then the commit description lands
automatically in the PR description - which is nice. And then - even if
your PR is not yet ready, the context rarely changes - no matter how many
fixup you have on the PR.
Actually now, when I think of it - this is the best sign of a good commit
message: If you did not have to change it when you first pushed the draft
till the moment you merged it, this is a very good commit message.
J.
On Thu, Sep 10, 2020 at 5:30 PM Ash Berlin-Taylor <as...@apache.org> wrote:
> Yeah, that's what I do (or try to. No one is perfect.)
>
> I'm sure it's written down _somewhere_ but I've long since forgotten
> where I picked up that habit from. It's almost an extention to point 5
> in https://chris.beams.io/posts/git-commit/#imperative (which we already
> point to).
>
> -a
>
> On Sep 10 2020, at 4:24 pm, Jarek Potiuk <Ja...@polidea.com> wrote:
>
> > Also on that, As far as I remember the "unwritten" rule that Ash
> mentioned
> > some time ago as far as I remember the "subject" of the commit is best if
> > it completes the sentence:
> >
> > "This commit when merged ...." ("fixes this and that" for example).
> >
> > And then the context on why we are doing it should follow. For some
> > time I
> > try to follow this quite rigorously with some of the heavier changes :)
> >
> > Do I remember it well Ash?
> >
> > J,
> >
> >
> > On Thu, Sep 10, 2020 at 5:07 PM Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com>
> > wrote:
> >
> >> I agree with Jarek - as long as we cannot enforce it we as reviewers
> >> should do our best to have the description in place.
> >>
> >> On a general note, we should always remember that even if we know each
> >> other and communicate through different channels (slack, calls, etc)
> >> other people won't know the context of the change if there's no
> >> description.
> >>
> >> Tomek
> >>
> >>
> >> On Thu, Sep 10, 2020 at 4:50 PM Jarek Potiuk <Ja...@polidea.com>
> >> wrote:
> >> >
> >> > I am afraid people won't read it anyway. the PR template should be as
> >> > short as possible. I think this one is really something that should
> >> > be on reviewers. It's one of those things that is hard to automate or
> >> > delegate.
> >> >
> >> > If the reviewer does not understand what the PR from the description,
> >> > it should be the first point to say "please provider context, I am not
> >> > sure what the change does" even before looking at the code IMHO. If we
> >> > all do that - this will be much more effective than writing it in the
> >> > template.
> >> >
> >> > J
> >> >
> >> > On Thu, Sep 10, 2020 at 3:14 PM Ry Walker <ry...@rywalker.com> wrote:
> >> > >
> >> > > Maybe modify the template to include some copy from your email in
> >> it :)
> >> > >
> >> > > On Sun, Sep 6, 2020 at 6:56 AM Kaxil Naik <ka...@gmail.com>
> wrote:
> >> > >
> >> > > > Hi all,
> >> > > >
> >> > > > I have brought this topic on multiple occasions earlier too on the
> >> mailing
> >> > > > list. I sincerely request all the contributors and Committers
> >> (including
> >> > > > myself) that we add PR descriptions.
> >> > > >
> >> > > > This helps the community understand what the PRs do and abides by
> >> the ASF
> >> > > > motto about "Community above Code", many users lands to the PR
> after
> >> > > > checking change log and having to look at the code to
> >> understand the
> >> PR is
> >> > > > not ideal. Adding descriptions of "most" of the PRs literally does
> >> not take
> >> > > > more than a minute.
> >> > > >
> >> > > > We previously had automation around it but we removed because of
> >> small
> >> > > > exceptions where the PR title can be self explanatory.
> >> > > >
> >> > > > We should not ignore rules (I am talking about PR template that
> says
> >> " ^
> >> > > > Add meaningful description above ". Again it is fine if the PR
> title
> >> is
> >> > > > self explanatory but not otherwise.
> >> > > >
> >> > > > Regards,
> >> > > > Kaxil
> >> > > >
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > Jarek Potiuk
> >> > Polidea | Principal Software Engineer
> >> >
> >> > M: +48 660 796 129
> >>
> >>
> >>
> >> --
> >>
> >> Tomasz Urbaszek
> >> Polidea | Software Engineer
> >>
> >> M: +48 505 628 493
> >> E: tomasz.urbaszek@polidea.com
> >>
> >> Unique Tech
> >> Check out our projects!
> >>
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
>
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
Re: PR Descriptions
Posted by Ash Berlin-Taylor <as...@apache.org>.
Yeah, that's what I do (or try to. No one is perfect.)
I'm sure it's written down _somewhere_ but I've long since forgotten
where I picked up that habit from. It's almost an extention to point 5
in https://chris.beams.io/posts/git-commit/#imperative (which we already
point to).
-a
On Sep 10 2020, at 4:24 pm, Jarek Potiuk <Ja...@polidea.com> wrote:
> Also on that, As far as I remember the "unwritten" rule that Ash mentioned
> some time ago as far as I remember the "subject" of the commit is best if
> it completes the sentence:
>
> "This commit when merged ...." ("fixes this and that" for example).
>
> And then the context on why we are doing it should follow. For some
> time I
> try to follow this quite rigorously with some of the heavier changes :)
>
> Do I remember it well Ash?
>
> J,
>
>
> On Thu, Sep 10, 2020 at 5:07 PM Tomasz Urbaszek <to...@polidea.com>
> wrote:
>
>> I agree with Jarek - as long as we cannot enforce it we as reviewers
>> should do our best to have the description in place.
>>
>> On a general note, we should always remember that even if we know each
>> other and communicate through different channels (slack, calls, etc)
>> other people won't know the context of the change if there's no
>> description.
>>
>> Tomek
>>
>>
>> On Thu, Sep 10, 2020 at 4:50 PM Jarek Potiuk <Ja...@polidea.com>
>> wrote:
>> >
>> > I am afraid people won't read it anyway. the PR template should be as
>> > short as possible. I think this one is really something that should
>> > be on reviewers. It's one of those things that is hard to automate or
>> > delegate.
>> >
>> > If the reviewer does not understand what the PR from the description,
>> > it should be the first point to say "please provider context, I am not
>> > sure what the change does" even before looking at the code IMHO. If we
>> > all do that - this will be much more effective than writing it in the
>> > template.
>> >
>> > J
>> >
>> > On Thu, Sep 10, 2020 at 3:14 PM Ry Walker <ry...@rywalker.com> wrote:
>> > >
>> > > Maybe modify the template to include some copy from your email in
>> it :)
>> > >
>> > > On Sun, Sep 6, 2020 at 6:56 AM Kaxil Naik <ka...@gmail.com> wrote:
>> > >
>> > > > Hi all,
>> > > >
>> > > > I have brought this topic on multiple occasions earlier too on the
>> mailing
>> > > > list. I sincerely request all the contributors and Committers
>> (including
>> > > > myself) that we add PR descriptions.
>> > > >
>> > > > This helps the community understand what the PRs do and abides by
>> the ASF
>> > > > motto about "Community above Code", many users lands to the PR after
>> > > > checking change log and having to look at the code to
>> understand the
>> PR is
>> > > > not ideal. Adding descriptions of "most" of the PRs literally does
>> not take
>> > > > more than a minute.
>> > > >
>> > > > We previously had automation around it but we removed because of
>> small
>> > > > exceptions where the PR title can be self explanatory.
>> > > >
>> > > > We should not ignore rules (I am talking about PR template that says
>> " ^
>> > > > Add meaningful description above ". Again it is fine if the PR title
>> is
>> > > > self explanatory but not otherwise.
>> > > >
>> > > > Regards,
>> > > > Kaxil
>> > > >
>> >
>> >
>> >
>> > --
>> >
>> > Jarek Potiuk
>> > Polidea | Principal Software Engineer
>> >
>> > M: +48 660 796 129
>>
>>
>>
>> --
>>
>> Tomasz Urbaszek
>> Polidea | Software Engineer
>>
>> M: +48 505 628 493
>> E: tomasz.urbaszek@polidea.com
>>
>> Unique Tech
>> Check out our projects!
>>
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>
Re: PR Descriptions
Posted by Jarek Potiuk <Ja...@polidea.com>.
Also on that, As far as I remember the "unwritten" rule that Ash mentioned
some time ago as far as I remember the "subject" of the commit is best if
it completes the sentence:
"This commit when merged ...." ("fixes this and that" for example).
And then the context on why we are doing it should follow. For some time I
try to follow this quite rigorously with some of the heavier changes :)
Do I remember it well Ash?
J,
On Thu, Sep 10, 2020 at 5:07 PM Tomasz Urbaszek <to...@polidea.com>
wrote:
> I agree with Jarek - as long as we cannot enforce it we as reviewers
> should do our best to have the description in place.
>
> On a general note, we should always remember that even if we know each
> other and communicate through different channels (slack, calls, etc)
> other people won't know the context of the change if there's no
> description.
>
> Tomek
>
>
> On Thu, Sep 10, 2020 at 4:50 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
> >
> > I am afraid people won't read it anyway. the PR template should be as
> > short as possible. I think this one is really something that should
> > be on reviewers. It's one of those things that is hard to automate or
> > delegate.
> >
> > If the reviewer does not understand what the PR from the description,
> > it should be the first point to say "please provider context, I am not
> > sure what the change does" even before looking at the code IMHO. If we
> > all do that - this will be much more effective than writing it in the
> > template.
> >
> > J
> >
> > On Thu, Sep 10, 2020 at 3:14 PM Ry Walker <ry...@rywalker.com> wrote:
> > >
> > > Maybe modify the template to include some copy from your email in it :)
> > >
> > > On Sun, Sep 6, 2020 at 6:56 AM Kaxil Naik <ka...@gmail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I have brought this topic on multiple occasions earlier too on the
> mailing
> > > > list. I sincerely request all the contributors and Committers
> (including
> > > > myself) that we add PR descriptions.
> > > >
> > > > This helps the community understand what the PRs do and abides by
> the ASF
> > > > motto about "Community above Code", many users lands to the PR after
> > > > checking change log and having to look at the code to understand the
> PR is
> > > > not ideal. Adding descriptions of "most" of the PRs literally does
> not take
> > > > more than a minute.
> > > >
> > > > We previously had automation around it but we removed because of
> small
> > > > exceptions where the PR title can be self explanatory.
> > > >
> > > > We should not ignore rules (I am talking about PR template that says
> " ^
> > > > Add meaningful description above ". Again it is fine if the PR title
> is
> > > > self explanatory but not otherwise.
> > > >
> > > > Regards,
> > > > Kaxil
> > > >
> >
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea | Principal Software Engineer
> >
> > M: +48 660 796 129
>
>
>
> --
>
> Tomasz Urbaszek
> Polidea | Software Engineer
>
> M: +48 505 628 493
> E: tomasz.urbaszek@polidea.com
>
> Unique Tech
> Check out our projects!
>
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
Re: PR Descriptions
Posted by Tomasz Urbaszek <to...@polidea.com>.
I agree with Jarek - as long as we cannot enforce it we as reviewers
should do our best to have the description in place.
On a general note, we should always remember that even if we know each
other and communicate through different channels (slack, calls, etc)
other people won't know the context of the change if there's no
description.
Tomek
On Thu, Sep 10, 2020 at 4:50 PM Jarek Potiuk <Ja...@polidea.com> wrote:
>
> I am afraid people won't read it anyway. the PR template should be as
> short as possible. I think this one is really something that should
> be on reviewers. It's one of those things that is hard to automate or
> delegate.
>
> If the reviewer does not understand what the PR from the description,
> it should be the first point to say "please provider context, I am not
> sure what the change does" even before looking at the code IMHO. If we
> all do that - this will be much more effective than writing it in the
> template.
>
> J
>
> On Thu, Sep 10, 2020 at 3:14 PM Ry Walker <ry...@rywalker.com> wrote:
> >
> > Maybe modify the template to include some copy from your email in it :)
> >
> > On Sun, Sep 6, 2020 at 6:56 AM Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > I have brought this topic on multiple occasions earlier too on the mailing
> > > list. I sincerely request all the contributors and Committers (including
> > > myself) that we add PR descriptions.
> > >
> > > This helps the community understand what the PRs do and abides by the ASF
> > > motto about "Community above Code", many users lands to the PR after
> > > checking change log and having to look at the code to understand the PR is
> > > not ideal. Adding descriptions of "most" of the PRs literally does not take
> > > more than a minute.
> > >
> > > We previously had automation around it but we removed because of small
> > > exceptions where the PR title can be self explanatory.
> > >
> > > We should not ignore rules (I am talking about PR template that says " ^
> > > Add meaningful description above ". Again it is fine if the PR title is
> > > self explanatory but not otherwise.
> > >
> > > Regards,
> > > Kaxil
> > >
>
>
>
> --
>
> Jarek Potiuk
> Polidea | Principal Software Engineer
>
> M: +48 660 796 129
--
Tomasz Urbaszek
Polidea | Software Engineer
M: +48 505 628 493
E: tomasz.urbaszek@polidea.com
Unique Tech
Check out our projects!
Re: PR Descriptions
Posted by Jarek Potiuk <Ja...@polidea.com>.
I am afraid people won't read it anyway. the PR template should be as
short as possible. I think this one is really something that should
be on reviewers. It's one of those things that is hard to automate or
delegate.
If the reviewer does not understand what the PR from the description,
it should be the first point to say "please provider context, I am not
sure what the change does" even before looking at the code IMHO. If we
all do that - this will be much more effective than writing it in the
template.
J
On Thu, Sep 10, 2020 at 3:14 PM Ry Walker <ry...@rywalker.com> wrote:
>
> Maybe modify the template to include some copy from your email in it :)
>
> On Sun, Sep 6, 2020 at 6:56 AM Kaxil Naik <ka...@gmail.com> wrote:
>
> > Hi all,
> >
> > I have brought this topic on multiple occasions earlier too on the mailing
> > list. I sincerely request all the contributors and Committers (including
> > myself) that we add PR descriptions.
> >
> > This helps the community understand what the PRs do and abides by the ASF
> > motto about "Community above Code", many users lands to the PR after
> > checking change log and having to look at the code to understand the PR is
> > not ideal. Adding descriptions of "most" of the PRs literally does not take
> > more than a minute.
> >
> > We previously had automation around it but we removed because of small
> > exceptions where the PR title can be self explanatory.
> >
> > We should not ignore rules (I am talking about PR template that says " ^
> > Add meaningful description above ". Again it is fine if the PR title is
> > self explanatory but not otherwise.
> >
> > Regards,
> > Kaxil
> >
--
Jarek Potiuk
Polidea | Principal Software Engineer
M: +48 660 796 129
Re: PR Descriptions
Posted by Ry Walker <ry...@rywalker.com>.
Maybe modify the template to include some copy from your email in it :)
On Sun, Sep 6, 2020 at 6:56 AM Kaxil Naik <ka...@gmail.com> wrote:
> Hi all,
>
> I have brought this topic on multiple occasions earlier too on the mailing
> list. I sincerely request all the contributors and Committers (including
> myself) that we add PR descriptions.
>
> This helps the community understand what the PRs do and abides by the ASF
> motto about "Community above Code", many users lands to the PR after
> checking change log and having to look at the code to understand the PR is
> not ideal. Adding descriptions of "most" of the PRs literally does not take
> more than a minute.
>
> We previously had automation around it but we removed because of small
> exceptions where the PR title can be self explanatory.
>
> We should not ignore rules (I am talking about PR template that says " ^
> Add meaningful description above ". Again it is fine if the PR title is
> self explanatory but not otherwise.
>
> Regards,
> Kaxil
>
Re: PR Descriptions
Posted by Jarek Potiuk <Ja...@polidea.com>.
+10
On Sun, Sep 6, 2020 at 12:56 PM Kaxil Naik <ka...@gmail.com> wrote:
>
> Hi all,
>
> I have brought this topic on multiple occasions earlier too on the mailing
> list. I sincerely request all the contributors and Committers (including
> myself) that we add PR descriptions.
>
> This helps the community understand what the PRs do and abides by the ASF
> motto about "Community above Code", many users lands to the PR after
> checking change log and having to look at the code to understand the PR is
> not ideal. Adding descriptions of "most" of the PRs literally does not take
> more than a minute.
>
> We previously had automation around it but we removed because of small
> exceptions where the PR title can be self explanatory.
>
> We should not ignore rules (I am talking about PR template that says " ^
> Add meaningful description above ". Again it is fine if the PR title is
> self explanatory but not otherwise.
>
> Regards,
> Kaxil
--
Jarek Potiuk
Polidea | Principal Software Engineer
M: +48 660 796 129