You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Frances Perry <fj...@google.com.INVALID> on 2016/03/17 22:19:08 UTC

Draft Contribution Guide

Hi Beamers!

We've started a draft
<https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment>
for the Beam contribution guide. Please take a look and provide feedback.
Once things settle, we'll get this moved over on to the Beam website.

Frances

Re: Draft Contribution Guide

Posted by Maximilian Michels <mx...@apache.org>.
@Ben: Fixing a subtle bug that was introduced and that users are affected
by. Fixing instable builds. Minor cosmetic changes. Changes to JavaDoc.
However, PRs make an excellent tool for code reviews most of the time. I
see that we probably can't stress that enough.

I'd actually think that my paragraph gave more reasons to use pull requests
than the current draft does. I'd be happy if we incorporated some of my
suggestions. I have removed the "Whenever possible" but kept my other
points about communication and follow-up discussions:

"Committers should never commit anything without going through a pull
request, since that would bypass test coverage and potentially cause the
build to fail due to checkstyle, etc. *In addition, pull requests ensure
that changes are communicated properly and potential flaws or improvements
can be spotted*. Always go through the pull request, even if you won’t wait
for the code review. *Even then, comments can be provided in the pull
requests after it has been merged to work on follow-ups.*"

Best,
Max

On Wed, Mar 23, 2016 at 8:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi Max,
>
> I would keep a "stronger statement", something like:
>
> "Committers always provide a pull request. This pull request has to be
> merged cleanly, and doesn't break the build (including test, checkstyle,
> documentation). The pull request has to be reviewed and only pushed on the
> upstream when the reviewer gives the LGTM keyword as comment."
>
> All other situations where the committer doesn't/can't provide a PR should
> be approved on the dev mailing list.
>
> My $0.01
>
> Regards
> JB
>
>
> On 03/23/2016 07:22 PM, Maximilian Michels wrote:
>>
>> I didn't see this paragraph before:
>>
>> "Committers should never commit anything without going through a pull
>> request, since that would bypass test coverage and potentially cause
>> the build to fail due to checkstyle, etc. Always go through the pull
>> request, even if you won’t wait for the code review."
>>
>> How about:
>>
>> "Whenever possible, commits should be reviewed in a pull request. Pull
>> requests ensure that changes can be communicated properly with the
>> community and potential flaws or improvements can be spotted. In
>> addition, pull requests ensure proper test coverage and verification
>> of the build. Whenever possible, go through the pull request, even if
>> you won’t wait for the code review."
>>
>> - Max
>>
>>
>> On Wed, Mar 23, 2016 at 5:33 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>>
>>> +1
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 03/23/2016 05:30 PM, Davor Bonaci wrote:
>>>>
>>>>
>>>> Thanks everyone for commenting!
>>>>
>>>> There were no new comments in the last several days, so we'll start
>>>> moving
>>>> the doc over to the Beam website.
>>>>
>>>> Of course, there's nothing here set in stone -- please reopen the
>>>> discussion about any particular point at any time in the future.
>>>>
>>>> On Fri, Mar 18, 2016 at 4:44 AM, Maximilian Michels <mx...@apache.org>
>>>> wrote:
>>>>
>>>>> Hi Frances,
>>>>>
>>>>> Very nice comprehensive guide. I'll leave some comments in the doc.
>>>>>
>>>>> Cheers,
>>>>> Max
>>>>>
>>>>> On Fri, Mar 18, 2016 at 11:51 AM, Sandeep Deshmukh
>>>>> <sa...@datatorrent.com> wrote:
>>>>>>
>>>>>>
>>>>>> The document captures the process very well and has right amount of
>>>>>
>>>>>
>>>>> details
>>>>>>
>>>>>>
>>>>>> for newbies too.
>>>>>>
>>>>>> Great work!!!
>>>>>>
>>>>>> Regards,
>>>>>> Sandeep
>>>>>>
>>>>>> On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <
>>>>>
>>>>>
>>>>> siva.kalagarla@gmail.com>
>>>>>>
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks Frances,  This document is helpful for newbies like myself.
>>>>>>> Will
>>>>>>> follow these steps over this weekend.
>>>>>>>
>>>>>>> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry
>>>>>>> <fj...@google.com.invalid>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Beamers!
>>>>>>>>
>>>>>>>> We've started a draft
>>>>>>>> <
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> for the Beam contribution guide. Please take a look and provide
>>>>>
>>>>>
>>>>> feedback.
>>>>>>>>
>>>>>>>>
>>>>>>>> Once things settle, we'll get this moved over on to the Beam
>>>>>>>> website.
>>>>>>>>
>>>>>>>> Frances
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Siva Kalagarla
>>>>>>> @SivaKalagarla <https://twitter.com/SivaKalagarla>
>>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Draft Contribution Guide

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Ismael,

Your points are valid. For the CONTRIBUTING.md, it's not a common 
practice in Apache project as github it's not the main repo (we document 
on the website). However, there's no problem to add this file.

For the description, we use it in Spark, it's a good idea.

For the "report issues guide", it's something that we will document 
(like which component for what part of beam, and maybe adding some 
fields on Jira, like target version in addition of fix version).

Regards
JB

On 03/27/2016 10:41 AM, Ismaël Mejía wrote:
> Hello,
>
> I had two small comments about the contribution guide:
>
> 1. It would be better to propose the direct HTTPS url for contributions,
> since
>     there are cases where the direct SSH address is not accesible
>     (firewalls/proxys etc).
>
>     So instead of:
>
>     $ git remote add <GitHub_user> git@github.com
> :<GitHub_user>/incubator-beam.git
>
>     I'd rather put:
>
>     $ git remote add <GitHub_user> https://github.com/
> <GitHub_user>/incubator-beam.git
>
> 2. Since Beam intends to use the github pull-request mechanism it is a good
> idea
>     to use some of the github practices:
>
>     - Have the contributing document, or a slimmer version as a
> CONTRIBUTING.md
>       file in the root of the project. This is good for two reasons, first
>       because is a common place where people look for it, and second because
> the
>       pull-request mechanism can refer to it.
>
>     - Add templates for pull requests (this is a new feature of github)
>
>       https://github.com/blog/2111-issue-and-pull-request-templates
>
>       This can help contributers to provide a better description of their
> changes
>       (filling the template).
>
> Finally, I don't know if it is worth, but naybe it would be good to have a
> small
> guide about how to report issues.
>
> Regards,
> Ismaël Mejía
>
>
>
> On Wed, Mar 23, 2016 at 8:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi Max,
>>
>> I would keep a "stronger statement", something like:
>>
>> "Committers always provide a pull request. This pull request has to be
>> merged cleanly, and doesn't break the build (including test, checkstyle,
>> documentation). The pull request has to be reviewed and only pushed on the
>> upstream when the reviewer gives the LGTM keyword as comment."
>>
>> All other situations where the committer doesn't/can't provide a PR should
>> be approved on the dev mailing list.
>>
>> My $0.01
>>
>> Regards
>> JB
>>
>>
>> On 03/23/2016 07:22 PM, Maximilian Michels wrote:
>>
>>> I didn't see this paragraph before:
>>>
>>> "Committers should never commit anything without going through a pull
>>> request, since that would bypass test coverage and potentially cause
>>> the build to fail due to checkstyle, etc. Always go through the pull
>>> request, even if you won’t wait for the code review."
>>>
>>> How about:
>>>
>>> "Whenever possible, commits should be reviewed in a pull request. Pull
>>> requests ensure that changes can be communicated properly with the
>>> community and potential flaws or improvements can be spotted. In
>>> addition, pull requests ensure proper test coverage and verification
>>> of the build. Whenever possible, go through the pull request, even if
>>> you won’t wait for the code review."
>>>
>>> - Max
>>>
>>>
>>> On Wed, Mar 23, 2016 at 5:33 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 03/23/2016 05:30 PM, Davor Bonaci wrote:
>>>>
>>>>>
>>>>> Thanks everyone for commenting!
>>>>>
>>>>> There were no new comments in the last several days, so we'll start
>>>>> moving
>>>>> the doc over to the Beam website.
>>>>>
>>>>> Of course, there's nothing here set in stone -- please reopen the
>>>>> discussion about any particular point at any time in the future.
>>>>>
>>>>> On Fri, Mar 18, 2016 at 4:44 AM, Maximilian Michels <mx...@apache.org>
>>>>> wrote:
>>>>>
>>>>> Hi Frances,
>>>>>>
>>>>>> Very nice comprehensive guide. I'll leave some comments in the doc.
>>>>>>
>>>>>> Cheers,
>>>>>> Max
>>>>>>
>>>>>> On Fri, Mar 18, 2016 at 11:51 AM, Sandeep Deshmukh
>>>>>> <sa...@datatorrent.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> The document captures the process very well and has right amount of
>>>>>>>
>>>>>>
>>>>>> details
>>>>>>
>>>>>>>
>>>>>>> for newbies too.
>>>>>>>
>>>>>>> Great work!!!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Sandeep
>>>>>>>
>>>>>>> On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <
>>>>>>>
>>>>>>
>>>>>> siva.kalagarla@gmail.com>
>>>>>>
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Thanks Frances,  This document is helpful for newbies like myself.
>>>>>>>> Will
>>>>>>>> follow these steps over this weekend.
>>>>>>>>
>>>>>>>> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry
>>>>>>>> <fj...@google.com.invalid>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Beamers!
>>>>>>>>>
>>>>>>>>> We've started a draft
>>>>>>>>> <
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> for the Beam contribution guide. Please take a look and provide
>>>>>>>>>
>>>>>>>>
>>>>>> feedback.
>>>>>>
>>>>>>>
>>>>>>>>> Once things settle, we'll get this moved over on to the Beam
>>>>>>>>> website.
>>>>>>>>>
>>>>>>>>> Frances
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Siva Kalagarla
>>>>>>>> @SivaKalagarla <https://twitter.com/SivaKalagarla>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Draft Contribution Guide

Posted by Ismaël Mejía <ie...@gmail.com>.
Hello,

I had two small comments about the contribution guide:

1. It would be better to propose the direct HTTPS url for contributions,
since
   there are cases where the direct SSH address is not accesible
   (firewalls/proxys etc).

   So instead of:

   $ git remote add <GitHub_user> git@github.com
:<GitHub_user>/incubator-beam.git

   I'd rather put:

   $ git remote add <GitHub_user> https://github.com/
<GitHub_user>/incubator-beam.git

2. Since Beam intends to use the github pull-request mechanism it is a good
idea
   to use some of the github practices:

   - Have the contributing document, or a slimmer version as a
CONTRIBUTING.md
     file in the root of the project. This is good for two reasons, first
     because is a common place where people look for it, and second because
the
     pull-request mechanism can refer to it.

   - Add templates for pull requests (this is a new feature of github)

     https://github.com/blog/2111-issue-and-pull-request-templates

     This can help contributers to provide a better description of their
changes
     (filling the template).

Finally, I don't know if it is worth, but naybe it would be good to have a
small
guide about how to report issues.

Regards,
Ismaël Mejía



On Wed, Mar 23, 2016 at 8:19 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> Hi Max,
>
> I would keep a "stronger statement", something like:
>
> "Committers always provide a pull request. This pull request has to be
> merged cleanly, and doesn't break the build (including test, checkstyle,
> documentation). The pull request has to be reviewed and only pushed on the
> upstream when the reviewer gives the LGTM keyword as comment."
>
> All other situations where the committer doesn't/can't provide a PR should
> be approved on the dev mailing list.
>
> My $0.01
>
> Regards
> JB
>
>
> On 03/23/2016 07:22 PM, Maximilian Michels wrote:
>
>> I didn't see this paragraph before:
>>
>> "Committers should never commit anything without going through a pull
>> request, since that would bypass test coverage and potentially cause
>> the build to fail due to checkstyle, etc. Always go through the pull
>> request, even if you won’t wait for the code review."
>>
>> How about:
>>
>> "Whenever possible, commits should be reviewed in a pull request. Pull
>> requests ensure that changes can be communicated properly with the
>> community and potential flaws or improvements can be spotted. In
>> addition, pull requests ensure proper test coverage and verification
>> of the build. Whenever possible, go through the pull request, even if
>> you won’t wait for the code review."
>>
>> - Max
>>
>>
>> On Wed, Mar 23, 2016 at 5:33 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>>> +1
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 03/23/2016 05:30 PM, Davor Bonaci wrote:
>>>
>>>>
>>>> Thanks everyone for commenting!
>>>>
>>>> There were no new comments in the last several days, so we'll start
>>>> moving
>>>> the doc over to the Beam website.
>>>>
>>>> Of course, there's nothing here set in stone -- please reopen the
>>>> discussion about any particular point at any time in the future.
>>>>
>>>> On Fri, Mar 18, 2016 at 4:44 AM, Maximilian Michels <mx...@apache.org>
>>>> wrote:
>>>>
>>>> Hi Frances,
>>>>>
>>>>> Very nice comprehensive guide. I'll leave some comments in the doc.
>>>>>
>>>>> Cheers,
>>>>> Max
>>>>>
>>>>> On Fri, Mar 18, 2016 at 11:51 AM, Sandeep Deshmukh
>>>>> <sa...@datatorrent.com> wrote:
>>>>>
>>>>>>
>>>>>> The document captures the process very well and has right amount of
>>>>>>
>>>>>
>>>>> details
>>>>>
>>>>>>
>>>>>> for newbies too.
>>>>>>
>>>>>> Great work!!!
>>>>>>
>>>>>> Regards,
>>>>>> Sandeep
>>>>>>
>>>>>> On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <
>>>>>>
>>>>>
>>>>> siva.kalagarla@gmail.com>
>>>>>
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> Thanks Frances,  This document is helpful for newbies like myself.
>>>>>>> Will
>>>>>>> follow these steps over this weekend.
>>>>>>>
>>>>>>> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry
>>>>>>> <fj...@google.com.invalid>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Beamers!
>>>>>>>>
>>>>>>>> We've started a draft
>>>>>>>> <
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>> for the Beam contribution guide. Please take a look and provide
>>>>>>>>
>>>>>>>
>>>>> feedback.
>>>>>
>>>>>>
>>>>>>>> Once things settle, we'll get this moved over on to the Beam
>>>>>>>> website.
>>>>>>>>
>>>>>>>> Frances
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Siva Kalagarla
>>>>>>> @SivaKalagarla <https://twitter.com/SivaKalagarla>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Draft Contribution Guide

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Max,

I would keep a "stronger statement", something like:

"Committers always provide a pull request. This pull request has to be 
merged cleanly, and doesn't break the build (including test, checkstyle, 
documentation). The pull request has to be reviewed and only pushed on 
the upstream when the reviewer gives the LGTM keyword as comment."

All other situations where the committer doesn't/can't provide a PR 
should be approved on the dev mailing list.

My $0.01

Regards
JB

On 03/23/2016 07:22 PM, Maximilian Michels wrote:
> I didn't see this paragraph before:
>
> "Committers should never commit anything without going through a pull
> request, since that would bypass test coverage and potentially cause
> the build to fail due to checkstyle, etc. Always go through the pull
> request, even if you won’t wait for the code review."
>
> How about:
>
> "Whenever possible, commits should be reviewed in a pull request. Pull
> requests ensure that changes can be communicated properly with the
> community and potential flaws or improvements can be spotted. In
> addition, pull requests ensure proper test coverage and verification
> of the build. Whenever possible, go through the pull request, even if
> you won’t wait for the code review."
>
> - Max
>
>
> On Wed, Mar 23, 2016 at 5:33 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> +1
>>
>> Regards
>> JB
>>
>>
>> On 03/23/2016 05:30 PM, Davor Bonaci wrote:
>>>
>>> Thanks everyone for commenting!
>>>
>>> There were no new comments in the last several days, so we'll start moving
>>> the doc over to the Beam website.
>>>
>>> Of course, there's nothing here set in stone -- please reopen the
>>> discussion about any particular point at any time in the future.
>>>
>>> On Fri, Mar 18, 2016 at 4:44 AM, Maximilian Michels <mx...@apache.org>
>>> wrote:
>>>
>>>> Hi Frances,
>>>>
>>>> Very nice comprehensive guide. I'll leave some comments in the doc.
>>>>
>>>> Cheers,
>>>> Max
>>>>
>>>> On Fri, Mar 18, 2016 at 11:51 AM, Sandeep Deshmukh
>>>> <sa...@datatorrent.com> wrote:
>>>>>
>>>>> The document captures the process very well and has right amount of
>>>>
>>>> details
>>>>>
>>>>> for newbies too.
>>>>>
>>>>> Great work!!!
>>>>>
>>>>> Regards,
>>>>> Sandeep
>>>>>
>>>>> On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <
>>>>
>>>> siva.kalagarla@gmail.com>
>>>>>
>>>>> wrote:
>>>>>
>>>>>> Thanks Frances,  This document is helpful for newbies like myself.
>>>>>> Will
>>>>>> follow these steps over this weekend.
>>>>>>
>>>>>> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry <fj...@google.com.invalid>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Beamers!
>>>>>>>
>>>>>>> We've started a draft
>>>>>>> <
>>>>>>>
>>>>>>
>>>>
>>>> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
>>>>>>>>
>>>>>>>>
>>>>>>> for the Beam contribution guide. Please take a look and provide
>>>>
>>>> feedback.
>>>>>>>
>>>>>>> Once things settle, we'll get this moved over on to the Beam website.
>>>>>>>
>>>>>>> Frances
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Siva Kalagarla
>>>>>> @SivaKalagarla <https://twitter.com/SivaKalagarla>
>>>>>>
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Draft Contribution Guide

Posted by Ben Chambers <bc...@google.com.INVALID>.
My concern with that is we aren't making clear what constitutes "whenever
possible". Could we more concretely define that (eg., "for example, when
Github is down")? Were there specific cases that you had in mind?
Otherwise, I worry about the ambiguity introduced and the possibility for
different people to interpret that very differently.

On Wed, Mar 23, 2016 at 11:23 AM Maximilian Michels <mx...@apache.org> wrote:

> I didn't see this paragraph before:
>
> "Committers should never commit anything without going through a pull
> request, since that would bypass test coverage and potentially cause
> the build to fail due to checkstyle, etc. Always go through the pull
> request, even if you won’t wait for the code review."
>
> How about:
>
> "Whenever possible, commits should be reviewed in a pull request. Pull
> requests ensure that changes can be communicated properly with the
> community and potential flaws or improvements can be spotted. In
> addition, pull requests ensure proper test coverage and verification
> of the build. Whenever possible, go through the pull request, even if
> you won’t wait for the code review."
>
> - Max
>
>
> On Wed, Mar 23, 2016 at 5:33 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> > +1
> >
> > Regards
> > JB
> >
> >
> > On 03/23/2016 05:30 PM, Davor Bonaci wrote:
> >>
> >> Thanks everyone for commenting!
> >>
> >> There were no new comments in the last several days, so we'll start
> moving
> >> the doc over to the Beam website.
> >>
> >> Of course, there's nothing here set in stone -- please reopen the
> >> discussion about any particular point at any time in the future.
> >>
> >> On Fri, Mar 18, 2016 at 4:44 AM, Maximilian Michels <mx...@apache.org>
> >> wrote:
> >>
> >>> Hi Frances,
> >>>
> >>> Very nice comprehensive guide. I'll leave some comments in the doc.
> >>>
> >>> Cheers,
> >>> Max
> >>>
> >>> On Fri, Mar 18, 2016 at 11:51 AM, Sandeep Deshmukh
> >>> <sa...@datatorrent.com> wrote:
> >>>>
> >>>> The document captures the process very well and has right amount of
> >>>
> >>> details
> >>>>
> >>>> for newbies too.
> >>>>
> >>>> Great work!!!
> >>>>
> >>>> Regards,
> >>>> Sandeep
> >>>>
> >>>> On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <
> >>>
> >>> siva.kalagarla@gmail.com>
> >>>>
> >>>> wrote:
> >>>>
> >>>>> Thanks Frances,  This document is helpful for newbies like myself.
> >>>>> Will
> >>>>> follow these steps over this weekend.
> >>>>>
> >>>>> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry
> <fj...@google.com.invalid>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi Beamers!
> >>>>>>
> >>>>>> We've started a draft
> >>>>>> <
> >>>>>>
> >>>>>
> >>>
> >>>
> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
> >>>>>>>
> >>>>>>>
> >>>>>> for the Beam contribution guide. Please take a look and provide
> >>>
> >>> feedback.
> >>>>>>
> >>>>>> Once things settle, we'll get this moved over on to the Beam
> website.
> >>>>>>
> >>>>>> Frances
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>> Siva Kalagarla
> >>>>> @SivaKalagarla <https://twitter.com/SivaKalagarla>
> >>>>>
> >>>
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>

Re: Draft Contribution Guide

Posted by Maximilian Michels <mx...@apache.org>.
I didn't see this paragraph before:

"Committers should never commit anything without going through a pull
request, since that would bypass test coverage and potentially cause
the build to fail due to checkstyle, etc. Always go through the pull
request, even if you won’t wait for the code review."

How about:

"Whenever possible, commits should be reviewed in a pull request. Pull
requests ensure that changes can be communicated properly with the
community and potential flaws or improvements can be spotted. In
addition, pull requests ensure proper test coverage and verification
of the build. Whenever possible, go through the pull request, even if
you won’t wait for the code review."

- Max


On Wed, Mar 23, 2016 at 5:33 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> +1
>
> Regards
> JB
>
>
> On 03/23/2016 05:30 PM, Davor Bonaci wrote:
>>
>> Thanks everyone for commenting!
>>
>> There were no new comments in the last several days, so we'll start moving
>> the doc over to the Beam website.
>>
>> Of course, there's nothing here set in stone -- please reopen the
>> discussion about any particular point at any time in the future.
>>
>> On Fri, Mar 18, 2016 at 4:44 AM, Maximilian Michels <mx...@apache.org>
>> wrote:
>>
>>> Hi Frances,
>>>
>>> Very nice comprehensive guide. I'll leave some comments in the doc.
>>>
>>> Cheers,
>>> Max
>>>
>>> On Fri, Mar 18, 2016 at 11:51 AM, Sandeep Deshmukh
>>> <sa...@datatorrent.com> wrote:
>>>>
>>>> The document captures the process very well and has right amount of
>>>
>>> details
>>>>
>>>> for newbies too.
>>>>
>>>> Great work!!!
>>>>
>>>> Regards,
>>>> Sandeep
>>>>
>>>> On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <
>>>
>>> siva.kalagarla@gmail.com>
>>>>
>>>> wrote:
>>>>
>>>>> Thanks Frances,  This document is helpful for newbies like myself.
>>>>> Will
>>>>> follow these steps over this weekend.
>>>>>
>>>>> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry <fj...@google.com.invalid>
>>>>> wrote:
>>>>>
>>>>>> Hi Beamers!
>>>>>>
>>>>>> We've started a draft
>>>>>> <
>>>>>>
>>>>>
>>>
>>> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
>>>>>>>
>>>>>>>
>>>>>> for the Beam contribution guide. Please take a look and provide
>>>
>>> feedback.
>>>>>>
>>>>>> Once things settle, we'll get this moved over on to the Beam website.
>>>>>>
>>>>>> Frances
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Regards,
>>>>> Siva Kalagarla
>>>>> @SivaKalagarla <https://twitter.com/SivaKalagarla>
>>>>>
>>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: Draft Contribution Guide

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1

Regards
JB

On 03/23/2016 05:30 PM, Davor Bonaci wrote:
> Thanks everyone for commenting!
>
> There were no new comments in the last several days, so we'll start moving
> the doc over to the Beam website.
>
> Of course, there's nothing here set in stone -- please reopen the
> discussion about any particular point at any time in the future.
>
> On Fri, Mar 18, 2016 at 4:44 AM, Maximilian Michels <mx...@apache.org> wrote:
>
>> Hi Frances,
>>
>> Very nice comprehensive guide. I'll leave some comments in the doc.
>>
>> Cheers,
>> Max
>>
>> On Fri, Mar 18, 2016 at 11:51 AM, Sandeep Deshmukh
>> <sa...@datatorrent.com> wrote:
>>> The document captures the process very well and has right amount of
>> details
>>> for newbies too.
>>>
>>> Great work!!!
>>>
>>> Regards,
>>> Sandeep
>>>
>>> On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <
>> siva.kalagarla@gmail.com>
>>> wrote:
>>>
>>>> Thanks Frances,  This document is helpful for newbies like myself.  Will
>>>> follow these steps over this weekend.
>>>>
>>>> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry <fj...@google.com.invalid>
>>>> wrote:
>>>>
>>>>> Hi Beamers!
>>>>>
>>>>> We've started a draft
>>>>> <
>>>>>
>>>>
>> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
>>>>>>
>>>>> for the Beam contribution guide. Please take a look and provide
>> feedback.
>>>>> Once things settle, we'll get this moved over on to the Beam website.
>>>>>
>>>>> Frances
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Regards,
>>>> Siva Kalagarla
>>>> @SivaKalagarla <https://twitter.com/SivaKalagarla>
>>>>
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Draft Contribution Guide

Posted by Davor Bonaci <da...@google.com.INVALID>.
Thanks everyone for commenting!

There were no new comments in the last several days, so we'll start moving
the doc over to the Beam website.

Of course, there's nothing here set in stone -- please reopen the
discussion about any particular point at any time in the future.

On Fri, Mar 18, 2016 at 4:44 AM, Maximilian Michels <mx...@apache.org> wrote:

> Hi Frances,
>
> Very nice comprehensive guide. I'll leave some comments in the doc.
>
> Cheers,
> Max
>
> On Fri, Mar 18, 2016 at 11:51 AM, Sandeep Deshmukh
> <sa...@datatorrent.com> wrote:
> > The document captures the process very well and has right amount of
> details
> > for newbies too.
> >
> > Great work!!!
> >
> > Regards,
> > Sandeep
> >
> > On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <
> siva.kalagarla@gmail.com>
> > wrote:
> >
> >> Thanks Frances,  This document is helpful for newbies like myself.  Will
> >> follow these steps over this weekend.
> >>
> >> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry <fj...@google.com.invalid>
> >> wrote:
> >>
> >> > Hi Beamers!
> >> >
> >> > We've started a draft
> >> > <
> >> >
> >>
> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
> >> > >
> >> > for the Beam contribution guide. Please take a look and provide
> feedback.
> >> > Once things settle, we'll get this moved over on to the Beam website.
> >> >
> >> > Frances
> >> >
> >>
> >>
> >>
> >> --
> >>
> >>
> >> Regards,
> >> Siva Kalagarla
> >> @SivaKalagarla <https://twitter.com/SivaKalagarla>
> >>
>

Re: Draft Contribution Guide

Posted by Maximilian Michels <mx...@apache.org>.
Hi Frances,

Very nice comprehensive guide. I'll leave some comments in the doc.

Cheers,
Max

On Fri, Mar 18, 2016 at 11:51 AM, Sandeep Deshmukh
<sa...@datatorrent.com> wrote:
> The document captures the process very well and has right amount of details
> for newbies too.
>
> Great work!!!
>
> Regards,
> Sandeep
>
> On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <si...@gmail.com>
> wrote:
>
>> Thanks Frances,  This document is helpful for newbies like myself.  Will
>> follow these steps over this weekend.
>>
>> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry <fj...@google.com.invalid>
>> wrote:
>>
>> > Hi Beamers!
>> >
>> > We've started a draft
>> > <
>> >
>> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
>> > >
>> > for the Beam contribution guide. Please take a look and provide feedback.
>> > Once things settle, we'll get this moved over on to the Beam website.
>> >
>> > Frances
>> >
>>
>>
>>
>> --
>>
>>
>> Regards,
>> Siva Kalagarla
>> @SivaKalagarla <https://twitter.com/SivaKalagarla>
>>

Re: Draft Contribution Guide

Posted by Sandeep Deshmukh <sa...@datatorrent.com>.
The document captures the process very well and has right amount of details
for newbies too.

Great work!!!

Regards,
Sandeep

On Fri, Mar 18, 2016 at 10:46 AM, Siva Kalagarla <si...@gmail.com>
wrote:

> Thanks Frances,  This document is helpful for newbies like myself.  Will
> follow these steps over this weekend.
>
> On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry <fj...@google.com.invalid>
> wrote:
>
> > Hi Beamers!
> >
> > We've started a draft
> > <
> >
> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
> > >
> > for the Beam contribution guide. Please take a look and provide feedback.
> > Once things settle, we'll get this moved over on to the Beam website.
> >
> > Frances
> >
>
>
>
> --
>
>
> Regards,
> Siva Kalagarla
> @SivaKalagarla <https://twitter.com/SivaKalagarla>
>

Re: Draft Contribution Guide

Posted by Siva Kalagarla <si...@gmail.com>.
Thanks Frances,  This document is helpful for newbies like myself.  Will
follow these steps over this weekend.

On Thu, Mar 17, 2016 at 2:19 PM, Frances Perry <fj...@google.com.invalid>
wrote:

> Hi Beamers!
>
> We've started a draft
> <
> https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment
> >
> for the Beam contribution guide. Please take a look and provide feedback.
> Once things settle, we'll get this moved over on to the Beam website.
>
> Frances
>



-- 


Regards,
Siva Kalagarla
@SivaKalagarla <https://twitter.com/SivaKalagarla>

Re: Draft Contribution Guide

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Frances,

thanks, it looks good to me (just proposed a minor suggestion). I see 
that James should update the website section. @James, let me know if I 
can help there.

Regards
JB

On 03/17/2016 10:19 PM, Frances Perry wrote:
> Hi Beamers!
>
> We've started a draft
> <https://docs.google.com/document/d/1syFyfqIsGOYDE_Hn3ZkRd8a6ylcc64Kud9YtrGHgU0E/comment>
> for the Beam contribution guide. Please take a look and provide feedback.
> Once things settle, we'll get this moved over on to the Beam website.
>
> Frances
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com