You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@training.apache.org by Sönke Liebau <so...@opencore.com.INVALID> on 2020/01/24 11:09:06 UTC

Review our Review process

Hi everybody,

as mentioned in our current board report I feel like we should revisit the
commit and review guidelines [1] that we currently have in place.

I have heard that in at least one instance individuals decided to stop
contributing to this project because doing so was overly complicated and
regulated - which personally I take as a serious red flag.

What do people think, should we move to a commit then review model, for
everything, just for content contributions, treat code separately,  ...

Personally I'd like to at least see some sort of check in place that only
content that was actually reviewed makes it into a release.
Personally, I feel that commit then review will lead to a large amount of
unreviewed content, but if I am the only one that thinks so I am willing to
adapt and try something else :)

Best regards,
Sönke


[1]
https://training.apache.org/developers/contributing.html#_toc_review_process1

Re: Review our Review process

Posted by Austin Bennett <wh...@gmail.com>.
If tagged on PR, esp. for content, happy to review (believe I have
sufficient bandwidth to assist there).  Ideally with guidelines on
what would make content not acceptable.

On Fri, Jan 24, 2020 at 6:43 AM Sönke Liebau
<so...@opencore.com.invalid> wrote:
>
> Lets wait a little for some more people to chime in and then start a vote
> thread tomorrow if there are no strong objections.
>
> On Fri, 24 Jan 2020 at 13:32, Lars Francke <la...@gmail.com> wrote:
>
> > Hi,
> >
> > But, as I said, while I have concerns I am personally willing to try
> > > something else - so won't stand in the way of commit then review.
> > >
> >
> > the same is true for me. We briefly discussed this a few months ago.
> > I'd love to have the time to review everything but I have to admit to
> > myself that I don't so in order to make more progress we should try
> > something different.
> >
> > I'd be happy to vote +1 for any other proposal.
> >
> > Cheers,
> > Lars
> >
> >
> > > Best regards,
> > > Sönke
> > >
> > >
> > > On Fri, 24 Jan 2020 at 12:55, Christofer Dutz <christofer.dutz@c-ware.de
> > >
> > > wrote:
> > >
> > > > Hi Sönke,
> > > >
> > > > thanks for bringing this up ... Yes ... don't know if you were
> > referring
> > > > to me, but I did really stop contributing, because I thought the
> > process
> > > > was getting in the way of getting stuff done.
> > > >
> > > > I would suggest to definitely go to "commit then review" for content.
> > We
> > > > could consider staying at "review then commit" for the tooling and main
> > > > theme stuff, as this would affect others more than content does. But I
> > > > would also opt for going to the simper process in general and perhaps
> > > > change things if things go south.
> > > >
> > > > I think my unreviewed PR that lay dormant for months is a great
> > > > demonstration of the "review then commit" not working.
> > > >
> > > > Chris
> > > >
> > > >
> > > >
> > > > Am 24.01.20, 12:09 schrieb "Sönke Liebau" <soenke.liebau@opencore.com
> > > > .INVALID>:
> > > >
> > > >     Hi everybody,
> > > >
> > > >     as mentioned in our current board report I feel like we should
> > > revisit
> > > > the
> > > >     commit and review guidelines [1] that we currently have in place.
> > > >
> > > >     I have heard that in at least one instance individuals decided to
> > > stop
> > > >     contributing to this project because doing so was overly
> > complicated
> > > > and
> > > >     regulated - which personally I take as a serious red flag.
> > > >
> > > >     What do people think, should we move to a commit then review model,
> > > for
> > > >     everything, just for content contributions, treat code separately,
> > > ...
> > > >
> > > >     Personally I'd like to at least see some sort of check in place
> > that
> > > > only
> > > >     content that was actually reviewed makes it into a release.
> > > >     Personally, I feel that commit then review will lead to a large
> > > amount
> > > > of
> > > >     unreviewed content, but if I am the only one that thinks so I am
> > > > willing to
> > > >     adapt and try something else :)
> > > >
> > > >     Best regards,
> > > >     Sönke
> > > >
> > > >
> > > >     [1]
> > > >
> > > >
> > >
> > https://training.apache.org/developers/contributing.html#_toc_review_process1
> > > >
> > > >
> > > >
> > >
> > > --
> > > Sönke Liebau
> > > Partner
> > > Tel. +49 179 7940878
> > > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
> > >
> >
>
>
> --
> Sönke Liebau
> Partner
> Tel. +49 179 7940878
> OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany

Re: Review our Review process

Posted by Sönke Liebau <so...@opencore.com.INVALID>.
Lets wait a little for some more people to chime in and then start a vote
thread tomorrow if there are no strong objections.

On Fri, 24 Jan 2020 at 13:32, Lars Francke <la...@gmail.com> wrote:

> Hi,
>
> But, as I said, while I have concerns I am personally willing to try
> > something else - so won't stand in the way of commit then review.
> >
>
> the same is true for me. We briefly discussed this a few months ago.
> I'd love to have the time to review everything but I have to admit to
> myself that I don't so in order to make more progress we should try
> something different.
>
> I'd be happy to vote +1 for any other proposal.
>
> Cheers,
> Lars
>
>
> > Best regards,
> > Sönke
> >
> >
> > On Fri, 24 Jan 2020 at 12:55, Christofer Dutz <christofer.dutz@c-ware.de
> >
> > wrote:
> >
> > > Hi Sönke,
> > >
> > > thanks for bringing this up ... Yes ... don't know if you were
> referring
> > > to me, but I did really stop contributing, because I thought the
> process
> > > was getting in the way of getting stuff done.
> > >
> > > I would suggest to definitely go to "commit then review" for content.
> We
> > > could consider staying at "review then commit" for the tooling and main
> > > theme stuff, as this would affect others more than content does. But I
> > > would also opt for going to the simper process in general and perhaps
> > > change things if things go south.
> > >
> > > I think my unreviewed PR that lay dormant for months is a great
> > > demonstration of the "review then commit" not working.
> > >
> > > Chris
> > >
> > >
> > >
> > > Am 24.01.20, 12:09 schrieb "Sönke Liebau" <soenke.liebau@opencore.com
> > > .INVALID>:
> > >
> > >     Hi everybody,
> > >
> > >     as mentioned in our current board report I feel like we should
> > revisit
> > > the
> > >     commit and review guidelines [1] that we currently have in place.
> > >
> > >     I have heard that in at least one instance individuals decided to
> > stop
> > >     contributing to this project because doing so was overly
> complicated
> > > and
> > >     regulated - which personally I take as a serious red flag.
> > >
> > >     What do people think, should we move to a commit then review model,
> > for
> > >     everything, just for content contributions, treat code separately,
> > ...
> > >
> > >     Personally I'd like to at least see some sort of check in place
> that
> > > only
> > >     content that was actually reviewed makes it into a release.
> > >     Personally, I feel that commit then review will lead to a large
> > amount
> > > of
> > >     unreviewed content, but if I am the only one that thinks so I am
> > > willing to
> > >     adapt and try something else :)
> > >
> > >     Best regards,
> > >     Sönke
> > >
> > >
> > >     [1]
> > >
> > >
> >
> https://training.apache.org/developers/contributing.html#_toc_review_process1
> > >
> > >
> > >
> >
> > --
> > Sönke Liebau
> > Partner
> > Tel. +49 179 7940878
> > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
> >
>


-- 
Sönke Liebau
Partner
Tel. +49 179 7940878
OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany

Re: Review our Review process

Posted by Lars Francke <la...@gmail.com>.
Hi,

But, as I said, while I have concerns I am personally willing to try
> something else - so won't stand in the way of commit then review.
>

the same is true for me. We briefly discussed this a few months ago.
I'd love to have the time to review everything but I have to admit to
myself that I don't so in order to make more progress we should try
something different.

I'd be happy to vote +1 for any other proposal.

Cheers,
Lars


> Best regards,
> Sönke
>
>
> On Fri, 24 Jan 2020 at 12:55, Christofer Dutz <ch...@c-ware.de>
> wrote:
>
> > Hi Sönke,
> >
> > thanks for bringing this up ... Yes ... don't know if you were referring
> > to me, but I did really stop contributing, because I thought the process
> > was getting in the way of getting stuff done.
> >
> > I would suggest to definitely go to "commit then review" for content. We
> > could consider staying at "review then commit" for the tooling and main
> > theme stuff, as this would affect others more than content does. But I
> > would also opt for going to the simper process in general and perhaps
> > change things if things go south.
> >
> > I think my unreviewed PR that lay dormant for months is a great
> > demonstration of the "review then commit" not working.
> >
> > Chris
> >
> >
> >
> > Am 24.01.20, 12:09 schrieb "Sönke Liebau" <soenke.liebau@opencore.com
> > .INVALID>:
> >
> >     Hi everybody,
> >
> >     as mentioned in our current board report I feel like we should
> revisit
> > the
> >     commit and review guidelines [1] that we currently have in place.
> >
> >     I have heard that in at least one instance individuals decided to
> stop
> >     contributing to this project because doing so was overly complicated
> > and
> >     regulated - which personally I take as a serious red flag.
> >
> >     What do people think, should we move to a commit then review model,
> for
> >     everything, just for content contributions, treat code separately,
> ...
> >
> >     Personally I'd like to at least see some sort of check in place that
> > only
> >     content that was actually reviewed makes it into a release.
> >     Personally, I feel that commit then review will lead to a large
> amount
> > of
> >     unreviewed content, but if I am the only one that thinks so I am
> > willing to
> >     adapt and try something else :)
> >
> >     Best regards,
> >     Sönke
> >
> >
> >     [1]
> >
> >
> https://training.apache.org/developers/contributing.html#_toc_review_process1
> >
> >
> >
>
> --
> Sönke Liebau
> Partner
> Tel. +49 179 7940878
> OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
>

Re: Review our Review process

Posted by Sönke Liebau <so...@opencore.com.INVALID>.
Hi Chris,

I wasn't directly referring to you, as I do not even know who I was talking
about, I just heard about "someone" :)

Looking at it the other way, your PR also perfectly demonstrates my
concerns, as this way at least we knew that it wasn't reviewed. If it had
just been committed, I'm fairly certain that knowledge might have
slipped through the cracks and it just taken as "done" by now - without
anybody ever giving it a second look.

But, as I said, while I have concerns I am personally willing to try
something else - so won't stand in the way of commit then review.

Best regards,
Sönke


On Fri, 24 Jan 2020 at 12:55, Christofer Dutz <ch...@c-ware.de>
wrote:

> Hi Sönke,
>
> thanks for bringing this up ... Yes ... don't know if you were referring
> to me, but I did really stop contributing, because I thought the process
> was getting in the way of getting stuff done.
>
> I would suggest to definitely go to "commit then review" for content. We
> could consider staying at "review then commit" for the tooling and main
> theme stuff, as this would affect others more than content does. But I
> would also opt for going to the simper process in general and perhaps
> change things if things go south.
>
> I think my unreviewed PR that lay dormant for months is a great
> demonstration of the "review then commit" not working.
>
> Chris
>
>
>
> Am 24.01.20, 12:09 schrieb "Sönke Liebau" <soenke.liebau@opencore.com
> .INVALID>:
>
>     Hi everybody,
>
>     as mentioned in our current board report I feel like we should revisit
> the
>     commit and review guidelines [1] that we currently have in place.
>
>     I have heard that in at least one instance individuals decided to stop
>     contributing to this project because doing so was overly complicated
> and
>     regulated - which personally I take as a serious red flag.
>
>     What do people think, should we move to a commit then review model, for
>     everything, just for content contributions, treat code separately,  ...
>
>     Personally I'd like to at least see some sort of check in place that
> only
>     content that was actually reviewed makes it into a release.
>     Personally, I feel that commit then review will lead to a large amount
> of
>     unreviewed content, but if I am the only one that thinks so I am
> willing to
>     adapt and try something else :)
>
>     Best regards,
>     Sönke
>
>
>     [1]
>
> https://training.apache.org/developers/contributing.html#_toc_review_process1
>
>
>

-- 
Sönke Liebau
Partner
Tel. +49 179 7940878
OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany

Re: Review our Review process

Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Sönke,

thanks for bringing this up ... Yes ... don't know if you were referring to me, but I did really stop contributing, because I thought the process was getting in the way of getting stuff done.

I would suggest to definitely go to "commit then review" for content. We could consider staying at "review then commit" for the tooling and main theme stuff, as this would affect others more than content does. But I would also opt for going to the simper process in general and perhaps change things if things go south. 

I think my unreviewed PR that lay dormant for months is a great demonstration of the "review then commit" not working.

Chris



Am 24.01.20, 12:09 schrieb "Sönke Liebau" <so...@opencore.com.INVALID>:

    Hi everybody,
    
    as mentioned in our current board report I feel like we should revisit the
    commit and review guidelines [1] that we currently have in place.
    
    I have heard that in at least one instance individuals decided to stop
    contributing to this project because doing so was overly complicated and
    regulated - which personally I take as a serious red flag.
    
    What do people think, should we move to a commit then review model, for
    everything, just for content contributions, treat code separately,  ...
    
    Personally I'd like to at least see some sort of check in place that only
    content that was actually reviewed makes it into a release.
    Personally, I feel that commit then review will lead to a large amount of
    unreviewed content, but if I am the only one that thinks so I am willing to
    adapt and try something else :)
    
    Best regards,
    Sönke
    
    
    [1]
    https://training.apache.org/developers/contributing.html#_toc_review_process1
    


Re: Review our Review process

Posted by Christofer Dutz <ch...@c-ware.de>.
I Chris'd also be in favour of different repos.

Chris
________________________________
Von: Sönke Liebau <so...@opencore.com.INVALID>
Gesendet: Samstag, 25. Januar 2020 20:53
An: dev@training.apache.org <de...@training.apache.org>
Betreff: Re: Review our Review process

Hi Mirko,

thanks for your mail! I'm not sure that I am on board with the idea of
keeping tooling and content in separate branches to be honest. To me that
always seems a bit like bending git to something it wasn't intended for. If
we want to keep these things separate, I think a separate repository is the
way to go. I am happy to try a strategy like "anything touching this path
needs a review first" or similar.. or go commit the review for the whole
thing as an experiment..

Best regards,
Sönke


On Fri, 24 Jan 2020 at 21:33, Mirko Kämpf <mi...@gmail.com> wrote:

> Hi everyone,
>
> I am happy to see this discussion going forward.
>
> I also think: Contribution of content should be handled differently than
> tooling contributions.
> What do you think about branches with a certain review policy?
>
> E.g., content branches vs. tooling-feature branches?
>
> Sounds complicated, but following your comments I think it would help the
> project to move forward.
>
> Cheers,
> Mirko
>
>
> Am Fr., 24. Jan. 2020 um 12:09 Uhr schrieb Sönke Liebau
> <so...@opencore.com.invalid>:
>
> > Hi everybody,
> >
> > as mentioned in our current board report I feel like we should revisit
> the
> > commit and review guidelines [1] that we currently have in place.
> >
> > I have heard that in at least one instance individuals decided to stop
> > contributing to this project because doing so was overly complicated and
> > regulated - which personally I take as a serious red flag.
> >
> > What do people think, should we move to a commit then review model, for
> > everything, just for content contributions, treat code separately,  ...
> >
> > Personally I'd like to at least see some sort of check in place that only
> > content that was actually reviewed makes it into a release.
> > Personally, I feel that commit then review will lead to a large amount of
> > unreviewed content, but if I am the only one that thinks so I am willing
> to
> > adapt and try something else :)
> >
> > Best regards,
> > Sönke
> >
> >
> > [1]
> >
> >
> https://training.apache.org/developers/contributing.html#_toc_review_process1
> >
>


--
Sönke Liebau
Partner
Tel. +49 179 7940878
OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany

Re: Review our Review process

Posted by Sönke Liebau <so...@opencore.com.INVALID>.
Hi Mirko,

thanks for your mail! I'm not sure that I am on board with the idea of
keeping tooling and content in separate branches to be honest. To me that
always seems a bit like bending git to something it wasn't intended for. If
we want to keep these things separate, I think a separate repository is the
way to go. I am happy to try a strategy like "anything touching this path
needs a review first" or similar.. or go commit the review for the whole
thing as an experiment..

Best regards,
Sönke


On Fri, 24 Jan 2020 at 21:33, Mirko Kämpf <mi...@gmail.com> wrote:

> Hi everyone,
>
> I am happy to see this discussion going forward.
>
> I also think: Contribution of content should be handled differently than
> tooling contributions.
> What do you think about branches with a certain review policy?
>
> E.g., content branches vs. tooling-feature branches?
>
> Sounds complicated, but following your comments I think it would help the
> project to move forward.
>
> Cheers,
> Mirko
>
>
> Am Fr., 24. Jan. 2020 um 12:09 Uhr schrieb Sönke Liebau
> <so...@opencore.com.invalid>:
>
> > Hi everybody,
> >
> > as mentioned in our current board report I feel like we should revisit
> the
> > commit and review guidelines [1] that we currently have in place.
> >
> > I have heard that in at least one instance individuals decided to stop
> > contributing to this project because doing so was overly complicated and
> > regulated - which personally I take as a serious red flag.
> >
> > What do people think, should we move to a commit then review model, for
> > everything, just for content contributions, treat code separately,  ...
> >
> > Personally I'd like to at least see some sort of check in place that only
> > content that was actually reviewed makes it into a release.
> > Personally, I feel that commit then review will lead to a large amount of
> > unreviewed content, but if I am the only one that thinks so I am willing
> to
> > adapt and try something else :)
> >
> > Best regards,
> > Sönke
> >
> >
> > [1]
> >
> >
> https://training.apache.org/developers/contributing.html#_toc_review_process1
> >
>


-- 
Sönke Liebau
Partner
Tel. +49 179 7940878
OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany

Re: Review our Review process

Posted by Mirko Kämpf <mi...@gmail.com>.
Hi everyone,

I am happy to see this discussion going forward.

I also think: Contribution of content should be handled differently than
tooling contributions.
What do you think about branches with a certain review policy?

E.g., content branches vs. tooling-feature branches?

Sounds complicated, but following your comments I think it would help the
project to move forward.

Cheers,
Mirko


Am Fr., 24. Jan. 2020 um 12:09 Uhr schrieb Sönke Liebau
<so...@opencore.com.invalid>:

> Hi everybody,
>
> as mentioned in our current board report I feel like we should revisit the
> commit and review guidelines [1] that we currently have in place.
>
> I have heard that in at least one instance individuals decided to stop
> contributing to this project because doing so was overly complicated and
> regulated - which personally I take as a serious red flag.
>
> What do people think, should we move to a commit then review model, for
> everything, just for content contributions, treat code separately,  ...
>
> Personally I'd like to at least see some sort of check in place that only
> content that was actually reviewed makes it into a release.
> Personally, I feel that commit then review will lead to a large amount of
> unreviewed content, but if I am the only one that thinks so I am willing to
> adapt and try something else :)
>
> Best regards,
> Sönke
>
>
> [1]
>
> https://training.apache.org/developers/contributing.html#_toc_review_process1
>