Collaboration process at Ignite

[Raul Kripalani]

Hello all,

I started contributing to Ignite a few weeks ago and I would like to raise
a few topics for discussion.

1) This project desperately needs an IRC channel. At this stage of the
project lifecycle open, ephemeral chit-chat is important. Ignite is trying
to get as many people involved in the project as possible and to build
relationships. Email is too heavy a tool for that.

Contributors working on code who would like to shoot across a quick
question/doubt to the core team cannot do that right now. Forums are not a
place to ask questions like: "hey, is it ok to add a notNullOrEmpty method
to the GridArgumentCheck class?".

This is even more relevant given the proportionally large amount of
committers associated to a single company at the moment.

2) At this point the community cannot be very picky with code style in
contributions. I don't want to generalise, but a spirit of gratitude vs.
one of stern demands would be appropriate. See for example this personal
contribution of mine [1]. No "thanks" to be found anywhere, just a "go read
the docs" and "by the way, we don't use this framework".

This is not the ASF way – let alone for a project transitioning to a TLP.

3) The "Development Process" wiki page must be linked to from a notice box
in the Contribute page [2]. I haven't found a link, and if there is one,
it's not catching my attention.

4) You should not expect people to contribute code that adheres to your
specification unless you attach a check into the build. In the Camel
project we have a Maven profile -Pvalidate that runs a checkstyle
expressing our coding style. Contributors run this profile before
submitting a patch to us.

It doesn't make sense to ask a contributor to write code in a style they
don't like, just because someone else prefers it that way. Developers like
to write code in their own style, and then use a tool to adapt it to the
community standards.

That said, I think there is an IntelliJ formatting template somewhere in
the source repo, but remember that not everybody uses IntelliJ. And there
may be a checkstyle file somewhere too, but it is not attached to the
build. Therefore, in practical terms, the community is not enforcing a
style other than by a Wiki page buried somewhere in the community – not
enough.

5) Merging pull requests from Github is not evil. There is no reason why to
impose the submission of a patch attached to a JIRA in my opinion. If you
are worried about regulatory/legal/IP aspects, I think the ASL license
headers at the top and the explicit action that the contributor takes to
send in the pull request is enough to grant authorisation. That's the way
we do it in Camel.

People like working with Github, and it's more convenient for everybody. In
Camel we even have a Github - JIRA integration whereby a bot comments in
the relevant ticket when a PR is submitted.

Let's be embracing, not enforcing. At least at this stage.

[1]
https://github.com/apache/incubator-ignite/pull/11#issuecomment-129505860.
[2] https://ignite.incubator.apache.org/community/contribute.html

Regards,

*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

[Raul Kripalani]

By the way, there's an interesting discussion about Slack going on in
community-dev [1], if you'd like to check it out.

[1]
https://mail-archives.apache.org/mod_mbox/community-dev/201508.mbox/%3C0A45B62D-00FA-4F66-B357-E0240F9E65A1%40gmail.com%3E

*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Mon, Aug 10, 2015 at 5:58 PM, Raul Kripalani <[hidden email]> wrote:

> Hello all,
>
> I started contributing to Ignite a few weeks ago and I would like to raise
> a few topics for discussion.
>
> 1) This project desperately needs an IRC channel. At this stage of the
> project lifecycle open, ephemeral chit-chat is important. Ignite is trying
> to get as many people involved in the project as possible and to build
> relationships. Email is too heavy a tool for that.
>
> Contributors working on code who would like to shoot across a quick
> question/doubt to the core team cannot do that right now. Forums are not a
> place to ask questions like: "hey, is it ok to add a notNullOrEmpty method
> to the GridArgumentCheck class?".
>
> This is even more relevant given the proportionally large amount of
> committers associated to a single company at the moment.
>
> 2) At this point the community cannot be very picky with code style in
> contributions. I don't want to generalise, but a spirit of gratitude vs.
> one of stern demands would be appropriate. See for example this personal
> contribution of mine [1]. No "thanks" to be found anywhere, just a "go read
> the docs" and "by the way, we don't use this framework".
>
> This is not the ASF way – let alone for a project transitioning to a TLP.
>
> 3) The "Development Process" wiki page must be linked to from a notice box
> in the Contribute page [2]. I haven't found a link, and if there is one,
> it's not catching my attention.
>
> 4) You should not expect people to contribute code that adheres to your
> specification unless you attach a check into the build. In the Camel
> project we have a Maven profile -Pvalidate that runs a checkstyle
> expressing our coding style. Contributors run this profile before
> submitting a patch to us.
>
> It doesn't make sense to ask a contributor to write code in a style they
> don't like, just because someone else prefers it that way. Developers like
> to write code in their own style, and then use a tool to adapt it to the
> community standards.
>
> That said, I think there is an IntelliJ formatting template somewhere in
> the source repo, but remember that not everybody uses IntelliJ. And there
> may be a checkstyle file somewhere too, but it is not attached to the
> build. Therefore, in practical terms, the community is not enforcing a
> style other than by a Wiki page buried somewhere in the community – not
> enough.
>
> 5) Merging pull requests from Github is not evil. There is no reason why
> to impose the submission of a patch attached to a JIRA in my opinion. If
> you are worried about regulatory/legal/IP aspects, I think the ASL license
> headers at the top and the explicit action that the contributor takes to
> send in the pull request is enough to grant authorisation. That's the way
> we do it in Camel.
>
> People like working with Github, and it's more convenient for everybody.
> In Camel we even have a Github - JIRA integration whereby a bot comments in
> the relevant ticket when a PR is submitted.
>
> Let's be embracing, not enforcing. At least at this stage.
>
> [1]
> https://github.com/apache/incubator-ignite/pull/11#issuecomment-129505860.
> [2] https://ignite.incubator.apache.org/community/contribute.html
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

[chandresh pancholi]

I am using slack in current organization. i find it pretty useful for quick
responses.
We should have one IRC channel for discussion.

Thanks

On Mon, Aug 10, 2015 at 10:47 PM, Raul Kripalani <[hidden email]> wrote:

> By the way, there's an interesting discussion about Slack going on in
> community-dev [1], if you'd like to check it out.
>
> [1]
>
> https://mail-archives.apache.org/mod_mbox/community-dev/201508.mbox/%3C0A45B62D-00FA-4F66-B357-E0240F9E65A1%40gmail.com%3E
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Mon, Aug 10, 2015 at 5:58 PM, Raul Kripalani <[hidden email]> wrote:
>
> > Hello all,
> >
> > I started contributing to Ignite a few weeks ago and I would like to
> raise
> > a few topics for discussion.
> >
> > 1) This project desperately needs an IRC channel. At this stage of the
> > project lifecycle open, ephemeral chit-chat is important. Ignite is
> trying
> > to get as many people involved in the project as possible and to build
> > relationships. Email is too heavy a tool for that.
> >
> > Contributors working on code who would like to shoot across a quick
> > question/doubt to the core team cannot do that right now. Forums are not
> a
> > place to ask questions like: "hey, is it ok to add a notNullOrEmpty
> method
> > to the GridArgumentCheck class?".
> >
> > This is even more relevant given the proportionally large amount of
> > committers associated to a single company at the moment.
> >
> > 2) At this point the community cannot be very picky with code style in
> > contributions. I don't want to generalise, but a spirit of gratitude vs.
> > one of stern demands would be appropriate. See for example this personal
> > contribution of mine [1]. No "thanks" to be found anywhere, just a "go
> read
> > the docs" and "by the way, we don't use this framework".
> >
> > This is not the ASF way – let alone for a project transitioning to a TLP.
> >
> > 3) The "Development Process" wiki page must be linked to from a notice
> box
> > in the Contribute page [2]. I haven't found a link, and if there is one,
> > it's not catching my attention.
> >
> > 4) You should not expect people to contribute code that adheres to your
> > specification unless you attach a check into the build. In the Camel
> > project we have a Maven profile -Pvalidate that runs a checkstyle
> > expressing our coding style. Contributors run this profile before
> > submitting a patch to us.
> >
> > It doesn't make sense to ask a contributor to write code in a style they
> > don't like, just because someone else prefers it that way. Developers
> like
> > to write code in their own style, and then use a tool to adapt it to the
> > community standards.
> >
> > That said, I think there is an IntelliJ formatting template somewhere in
> > the source repo, but remember that not everybody uses IntelliJ. And there
> > may be a checkstyle file somewhere too, but it is not attached to the
> > build. Therefore, in practical terms, the community is not enforcing a
> > style other than by a Wiki page buried somewhere in the community – not
> > enough.
> >
> > 5) Merging pull requests from Github is not evil. There is no reason why
> > to impose the submission of a patch attached to a JIRA in my opinion. If
> > you are worried about regulatory/legal/IP aspects, I think the ASL
> license
> > headers at the top and the explicit action that the contributor takes to
> > send in the pull request is enough to grant authorisation. That's the way
> > we do it in Camel.
> >
> > People like working with Github, and it's more convenient for everybody.
> > In Camel we even have a Github - JIRA integration whereby a bot comments
> in
> > the relevant ticket when a PR is submitted.
> >
> > Let's be embracing, not enforcing. At least at this stage.
> >
> > [1]
> >
> https://github.com/apache/incubator-ignite/pull/11#issuecomment-129505860.
> > [2] https://ignite.incubator.apache.org/community/contribute.html
> >
> > Regards,
> >
> > *Raúl Kripalani*
> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > Integration specialist
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
>

--
Chandresh Pancholi
Senior Software Engineer
Flipkart.com
Email-id:[hidden email]
Contact:08951803660

[Konstantin Boudnik-2]

On Mon, Aug 10, 2015 at 05:58PM, Raul Kripalani wrote:
> Hello all,
>
> I started contributing to Ignite a few weeks ago and I would like to raise
> a few topics for discussion.
>
> 1) This project desperately needs an IRC channel. At this stage of the
> project lifecycle open, ephemeral chit-chat is important. Ignite is trying
> to get as many people involved in the project as possible and to build
> relationships. Email is too heavy a tool for that.

That's a good idea. However, decisions made on the chat _have_ to be recorded
in the email.

> Contributors working on code who would like to shoot across a quick
> question/doubt to the core team cannot do that right now. Forums are not a
> place to ask questions like: "hey, is it ok to add a notNullOrEmpty method
> to the GridArgumentCheck class?".
>
> This is even more relevant given the proportionally large amount of
> committers associated to a single company at the moment.
>
> 2) At this point the community cannot be very picky with code style in
> contributions. I don't want to generalise, but a spirit of gratitude vs.
> one of stern demands would be appropriate. See for example this personal
> contribution of mine [1]. No "thanks" to be found anywhere, just a "go read
> the docs" and "by the way, we don't use this framework".
>
> This is not the ASF way – let alone for a project transitioning to a TLP.

The ASF way is that of do-ocracy: if you feel there's something you can do to
complement project and advance it: do it. Perhaps communication style differs
from a person to person; email comm is a special case and could be surely
improved in many ways. Besides you should take into the account the cultural
backgrounds of people constituting the communities.

> 3) The "Development Process" wiki page must be linked to from a notice box
> in the Contribute page [2]. I haven't found a link, and if there is one,
> it's not catching my attention.

Great catch. Perhaps should be easy to fix, right?

> 4) You should not expect people to contribute code that adheres to your
> specification unless you attach a check into the build. In the Camel
> project we have a Maven profile -Pvalidate that runs a checkstyle
> expressing our coding style. Contributors run this profile before
> submitting a patch to us.
>
> It doesn't make sense to ask a contributor to write code in a style they
> don't like, just because someone else prefers it that way. Developers like
> to write code in their own style, and then use a tool to adapt it to the
> community standards.

This isn't a fact nor requirement: style is the must in the code. It has been
recognized a long time ago, that having consistent code-style decreases the
cognitive load. Any of the projects I worked with or contributed to at Apache
or elsewhere has the style guidelines and it is viciously followed.

> That said, I think there is an IntelliJ formatting template somewhere in
> the source repo, but remember that not everybody uses IntelliJ. And there
> may be a checkstyle file somewhere too, but it is not attached to the
> build. Therefore, in practical terms, the community is not enforcing a
> style other than by a Wiki page buried somewhere in the community – not
> enough.

Good point. Could you please open JIRA for it? Automatic style checking would
be great, if doable.

> 5) Merging pull requests from Github is not evil. There is no reason why to
> impose the submission of a patch attached to a JIRA in my opinion. If you
> are worried about regulatory/legal/IP aspects, I think the ASL license
> headers at the top and the explicit action that the contributor takes to
> send in the pull request is enough to grant authorisation. That's the way
> we do it in Camel.
>
> People like working with Github, and it's more convenient for everybody. In
> Camel we even have a Github - JIRA integration whereby a bot comments in
> the relevant ticket when a PR is submitted.

Some ppl like Github, some don't. Besides, the way the CI is set for this
project is to use the Apache JIRA as the source of the patches to validate.
That's the main reason.

Cos

> Let's be embracing, not enforcing. At least at this stage.
>
> [1]
> https://github.com/apache/incubator-ignite/pull/11#issuecomment-129505860.
> [2] https://ignite.incubator.apache.org/community/contribute.html
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk

[dsetrakyan]

Thanks for the comments, Raul. I generally agree with all the points you
have made. Additional comments are inline.

On Mon, Aug 10, 2015 at 9:58 AM, Raul Kripalani <[hidden email]> wrote:

> Hello all,
>
> I started contributing to Ignite a few weeks ago and I would like to raise
> a few topics for discussion.
>
> 1) This project desperately needs an IRC channel. At this stage of the
> project lifecycle open, ephemeral chit-chat is important. Ignite is trying
> to get as many people involved in the project as possible and to build
> relationships. Email is too heavy a tool for that.
>

I agree. I think the email has its obvious shortcomings and having a chat
channel will definitely make it easier for everyone to communicate.

Let's decide on Slack vs. IRC. Any preferences?

> Contributors working on code who would like to shoot across a quick
> question/doubt to the core team cannot do that right now. Forums are not
> a place to ask questions like: "hey, is it ok to add a notNullOrEmpty method
> to the GridArgumentCheck class?".
>
> This is even more relevant given the proportionally large amount of
> committers associated to a single company at the moment.
>
> 2) At this point the community cannot be very picky with code style in
> contributions. I don't want to generalise, but a spirit of gratitude vs.
> one of stern demands would be appropriate. See for example this personal
> contribution of mine [1]. No "thanks" to be found anywhere, just a "go read
> the docs" and "by the way, we don't use this framework".
>
>

Absolutely agree. I don't think this is a general trend within the
community, but we should all be more courteous with our communication,
especially when it comes to the new contributions.



> This is not the ASF way – let alone for a project transitioning to a TLP.
>
> 3) The "Development Process" wiki page must be linked to from a notice
> box in the Contribute page [2]. I haven't found a link, and if there is one,
> it's not catching my attention.
>

Will add the links.


> 4) You should not expect people to contribute code that adheres to your
> specification unless you attach a check into the build. In the Camel
> project we have a Maven profile -Pvalidate that runs a checkstyle
> expressing our coding style. Contributors run this profile before
> submitting a patch to us.
>

I think we should look into adding something similar to Ignite.

> It doesn't make sense to ask a contributor to write code in a style they
> don't like, just because someone else prefers it that way. Developers like
> to write code in their own style, and then use a tool to adapt it to the
> community standards.
>
> That said, I think there is an IntelliJ formatting template somewhere in
> the source repo, but remember that not everybody uses IntelliJ. And there
> may be a checkstyle file somewhere too, but it is not attached to the
> build. Therefore, in practical terms, the community is not enforcing a
> style other than by a Wiki page buried somewhere in the community – not
> enough.
>

We should be enforcing it with the build, but I also like having the
IntelliJ formatting in the project as well. We should add something similar
for Eclipse (I don't think there is one yet).


> 5) Merging pull requests from Github is not evil. There is no reason why to
> impose the submission of a patch attached to a JIRA in my opinion. If you
> are worried about regulatory/legal/IP aspects, I think the ASL license
> headers at the top and the explicit action that the contributor takes to
> send in the pull request is enough to grant authorisation. That's the way
> we do it in Camel.
>

The main issue here is public TC builds. Whenever you attach a patch to the
ticket, TC build gets automatically triggered. To my knowledge, there is
work being done on having the same with pull requests:

https://issues.apache.org/jira/browse/IGNITE-1217

> People like working with Github, and it's more convenient for everybody. In
> Camel we even have a Github - JIRA integration whereby a bot comments
> in the relevant ticket when a PR is submitted.
>
> Let's be embracing, not enforcing. At least at this stage.
>
> [1]
> https://github.com/apache/incubator-ignite/pull/11#issuecomment-129505860.
> [2] https://ignite.incubator.apache.org/community/contribute.html
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

[nivanov]

Slack [+1]

--
Nikita Ivanov


On Mon, Aug 10, 2015 at 1:53 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> Thanks for the comments, Raul. I generally agree with all the points you
> have made. Additional comments are inline.
>
> On Mon, Aug 10, 2015 at 9:58 AM, Raul Kripalani <[hidden email]> wrote:
>
> > Hello all,
> >
> > I started contributing to Ignite a few weeks ago and I would like to
> raise
> > a few topics for discussion.
> >
> > 1) This project desperately needs an IRC channel. At this stage of the
> > project lifecycle open, ephemeral chit-chat is important. Ignite is
> trying
> > to get as many people involved in the project as possible and to build
> > relationships. Email is too heavy a tool for that.
> >
>
> I agree. I think the email has its obvious shortcomings and having a chat
> channel will definitely make it easier for everyone to communicate.
>
> Let's decide on Slack vs. IRC. Any preferences?
>
>
> > Contributors working on code who would like to shoot across a quick
> > question/doubt to the core team cannot do that right now. Forums are not
> > a place to ask questions like: "hey, is it ok to add a notNullOrEmpty
> method
> > to the GridArgumentCheck class?".
> >
> > This is even more relevant given the proportionally large amount of
> > committers associated to a single company at the moment.
> >
> > 2) At this point the community cannot be very picky with code style in
> > contributions. I don't want to generalise, but a spirit of gratitude vs.
> > one of stern demands would be appropriate. See for example this personal
> > contribution of mine [1]. No "thanks" to be found anywhere, just a "go
> read
> > the docs" and "by the way, we don't use this framework".
> >
> >
> Absolutely agree. I don't think this is a general trend within the
> community, but we should all be more courteous with our communication,
> especially when it comes to the new contributions.
>
>
>
> > This is not the ASF way – let alone for a project transitioning to a TLP.
> >
> > 3) The "Development Process" wiki page must be linked to from a notice
> > box in the Contribute page [2]. I haven't found a link, and if there is
> one,
> > it's not catching my attention.
> >
>
> Will add the links.
>
>
> > 4) You should not expect people to contribute code that adheres to your
> > specification unless you attach a check into the build. In the Camel
> > project we have a Maven profile -Pvalidate that runs a checkstyle
> > expressing our coding style. Contributors run this profile before
> > submitting a patch to us.
> >
>
> I think we should look into adding something similar to Ignite.
>
>
> > It doesn't make sense to ask a contributor to write code in a style they
> > don't like, just because someone else prefers it that way. Developers
> like
> > to write code in their own style, and then use a tool to adapt it to the
> > community standards.
> >
> > That said, I think there is an IntelliJ formatting template somewhere in
> > the source repo, but remember that not everybody uses IntelliJ. And there
> > may be a checkstyle file somewhere too, but it is not attached to the
> > build. Therefore, in practical terms, the community is not enforcing a
> > style other than by a Wiki page buried somewhere in the community – not
> > enough.
> >
>
> We should be enforcing it with the build, but I also like having the
> IntelliJ formatting in the project as well. We should add something similar
> for Eclipse (I don't think there is one yet).
>
>
> > 5) Merging pull requests from Github is not evil. There is no reason why
> to
> > impose the submission of a patch attached to a JIRA in my opinion. If you
> > are worried about regulatory/legal/IP aspects, I think the ASL license
> > headers at the top and the explicit action that the contributor takes to
> > send in the pull request is enough to grant authorisation. That's the way
> > we do it in Camel.
> >
>
> The main issue here is public TC builds. Whenever you attach a patch to the
> ticket, TC build gets automatically triggered. To my knowledge, there is
> work being done on having the same with pull requests:
>
> https://issues.apache.org/jira/browse/IGNITE-1217
>
>
> > People like working with Github, and it's more convenient for everybody.
> In
> > Camel we even have a Github - JIRA integration whereby a bot comments
> > in the relevant ticket when a PR is submitted.
> >
> > Let's be embracing, not enforcing. At least at this stage.
> >
> > [1]
> >
> https://github.com/apache/incubator-ignite/pull/11#issuecomment-129505860.
> > [2] https://ignite.incubator.apache.org/community/contribute.html
> >
> > Regards,
> >
> > *Raúl Kripalani*
> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > Integration specialist
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
>

[Raul Kripalani]

On Mon, Aug 10, 2015 at 9:37 PM, Konstantin Boudnik <[hidden email]> wrote:

> That's a good idea. However, decisions made on the chat _have_ to be
> recorded
> in the email.
>

Actually, I'd like to drill into that.

It's not a matter of *recording* a decision taken in a chat, but recording
the *content* of the discussion, along with possible options to move
forward. Discussions can start spontaneously in a chat, regardless of who's
actually present. It would be unfair for decisions to be taken in absence
of others who simply weren't around at the time.

The decision itself should be taken in the mailing list – thus giving the
entire community to voice out their opinion. If the changes are if the
changes are substantial, structural or of significant impact, a VOTE is
recommended by The Apache Way [1], and it's useful for the poster to
indicate if lazy consensus applies. For smaller things, it suffices to open
a JIRA task and explain what was done and why.

Sorry to be a PITA; but I'm sharing what has worked in other projects I'm
involved in for the benefit and evolution of Ignite.

[1] https://www.apache.org/foundation/voting.html

Regards,

*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

[Raul Kripalani]

Hey Dmitriy,

On Mon, Aug 10, 2015 at 9:53 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> Let's decide on Slack vs. IRC. Any preferences?


Could you start a separate [VOTE] thread for this?

My concern with Slack is the concept of public channels does not exist,
unlike IRC where anybody can join a channel anytime without providing an
identity. Although there are solutions like slackin [1] used by other
non-ASF projects like neo4j, sockets.io, etc. On the other hand, it is
easier to start using. I guess I would vote for Slack (non-binding) just to
try it out.

[1] http://rauchg.com/slackin/

Regards,

*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

[Konstantin Boudnik-2]

On Mon, Aug 10, 2015 at 10:20PM, Raul Kripalani wrote:

> On Mon, Aug 10, 2015 at 9:37 PM, Konstantin Boudnik <[hidden email]> wrote:
>
> > That's a good idea. However, decisions made on the chat _have_ to be
> > recorded in the email.
>
> Actually, I'd like to drill into that.
>
> It's not a matter of *recording* a decision taken in a chat, but recording
> the *content* of the discussion, along with possible options to move
> forward. Discussions can start spontaneously in a chat, regardless of who's
> actually present. It would be unfair for decisions to be taken in absence
> of others who simply weren't around at the time.

I am not arguing with this. And I am not saying that a decisions from a chat
should be followed by anyone if the consensus weren't reached. The point I am
making is that off-line discussions have to be recorded (either as email or
JIRA, depends on how the project operates) for future reference, if they have
_any_ impact on the project.

> The decision itself should be taken in the mailing list – thus giving the
> entire community to voice out their opinion. If the changes are if the
> changes are substantial, structural or of significant impact, a VOTE is
> recommended by The Apache Way [1], and it's useful for the poster to
> indicate if lazy consensus applies. For smaller things, it suffices to open
> a JIRA task and explain what was done and why.

While your reference is certainly correct, the Apache Way isn't based on
voting. Apache Way is based on an explicit or an implicit consensus.
Voting-based system is a democracy; fortunately Apache isn't one. But let's
not go in this direction - it has been covered multiple times elsewhere.

Cos

> Sorry to be a PITA; but I'm sharing what has worked in other projects I'm
> involved in for the benefit and evolution of Ignite.
>
> [1] https://www.apache.org/foundation/voting.html
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk

[Konstantin Boudnik-2]

On Mon, Aug 10, 2015 at 01:59PM, Nikita Ivanov wrote:
> Slack [+1]

Both IRC and, esp. slack are tends to be a huge nuisance and
I don't have time for either. So I don't care one way or another.

>
> --
> Nikita Ivanov
>
>
> On Mon, Aug 10, 2015 at 1:53 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> > Thanks for the comments, Raul. I generally agree with all the points you
> > have made. Additional comments are inline.
> >
> > On Mon, Aug 10, 2015 at 9:58 AM, Raul Kripalani <[hidden email]> wrote:
> >
> > > Hello all,
> > >
> > > I started contributing to Ignite a few weeks ago and I would like to
> > raise
> > > a few topics for discussion.
> > >
> > > 1) This project desperately needs an IRC channel. At this stage of the
> > > project lifecycle open, ephemeral chit-chat is important. Ignite is
> > trying
> > > to get as many people involved in the project as possible and to build
> > > relationships. Email is too heavy a tool for that.
> > >
> >
> > I agree. I think the email has its obvious shortcomings and having a chat
> > channel will definitely make it easier for everyone to communicate.
> >
> > Let's decide on Slack vs. IRC. Any preferences?
> >
> >
> > > Contributors working on code who would like to shoot across a quick
> > > question/doubt to the core team cannot do that right now. Forums are not
> > > a place to ask questions like: "hey, is it ok to add a notNullOrEmpty
> > method
> > > to the GridArgumentCheck class?".
> > >
> > > This is even more relevant given the proportionally large amount of
> > > committers associated to a single company at the moment.
> > >
> > > 2) At this point the community cannot be very picky with code style in
> > > contributions. I don't want to generalise, but a spirit of gratitude vs.
> > > one of stern demands would be appropriate. See for example this personal
> > > contribution of mine [1]. No "thanks" to be found anywhere, just a "go
> > read
> > > the docs" and "by the way, we don't use this framework".
> > >
> > >
> > Absolutely agree. I don't think this is a general trend within the
> > community, but we should all be more courteous with our communication,
> > especially when it comes to the new contributions.
> >
> >
> >
> > > This is not the ASF way – let alone for a project transitioning to a TLP.
> > >
> > > 3) The "Development Process" wiki page must be linked to from a notice
> > > box in the Contribute page [2]. I haven't found a link, and if there is
> > one,
> > > it's not catching my attention.
> > >
> >
> > Will add the links.
> >
> >
> > > 4) You should not expect people to contribute code that adheres to your
> > > specification unless you attach a check into the build. In the Camel
> > > project we have a Maven profile -Pvalidate that runs a checkstyle
> > > expressing our coding style. Contributors run this profile before
> > > submitting a patch to us.
> > >
> >
> > I think we should look into adding something similar to Ignite.
> >
> >
> > > It doesn't make sense to ask a contributor to write code in a style they
> > > don't like, just because someone else prefers it that way. Developers
> > like
> > > to write code in their own style, and then use a tool to adapt it to the
> > > community standards.
> > >
> > > That said, I think there is an IntelliJ formatting template somewhere in
> > > the source repo, but remember that not everybody uses IntelliJ. And there
> > > may be a checkstyle file somewhere too, but it is not attached to the
> > > build. Therefore, in practical terms, the community is not enforcing a
> > > style other than by a Wiki page buried somewhere in the community – not
> > > enough.
> > >
> >
> > We should be enforcing it with the build, but I also like having the
> > IntelliJ formatting in the project as well. We should add something similar
> > for Eclipse (I don't think there is one yet).
> >
> >
> > > 5) Merging pull requests from Github is not evil. There is no reason why
> > to
> > > impose the submission of a patch attached to a JIRA in my opinion. If you
> > > are worried about regulatory/legal/IP aspects, I think the ASL license
> > > headers at the top and the explicit action that the contributor takes to
> > > send in the pull request is enough to grant authorisation. That's the way
> > > we do it in Camel.
> > >
> >
> > The main issue here is public TC builds. Whenever you attach a patch to the
> > ticket, TC build gets automatically triggered. To my knowledge, there is
> > work being done on having the same with pull requests:
> >
> > https://issues.apache.org/jira/browse/IGNITE-1217
> >
> >
> > > People like working with Github, and it's more convenient for everybody.
> > In
> > > Camel we even have a Github - JIRA integration whereby a bot comments
> > > in the relevant ticket when a PR is submitted.
> > >
> > > Let's be embracing, not enforcing. At least at this stage.
> > >
> > > [1]
> > >
> > https://github.com/apache/incubator-ignite/pull/11#issuecomment-129505860.
> > > [2] https://ignite.incubator.apache.org/community/contribute.html
> > >
> > > Regards,
> > >
> > > *Raúl Kripalani*
> > > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > > Integration specialist
> > > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> > >
> >

[Konstantin Boudnik-2]

On Mon, Aug 10, 2015 at 10:35PM, Raul Kripalani wrote:
> Hey Dmitriy,
>
> On Mon, Aug 10, 2015 at 9:53 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> > Let's decide on Slack vs. IRC. Any preferences?
>
> Could you start a separate [VOTE] thread for this?

Please don't - see my other email: the consensus in Apache isn't built on voting.
If a discuss-thread can not bring the closure to an issue the vote will always
be a horrible instrument for it. Some ppl will be in minority and you're going
to have a badly-broken democracy all over again.

The mentors of this podling have spent too much cycles already explaining what
Apache Way means. We don't want to repeat it all over again.

Cos

> My concern with Slack is the concept of public channels does not exist,
> unlike IRC where anybody can join a channel anytime without providing an
> identity. Although there are solutions like slackin [1] used by other
> non-ASF projects like neo4j, sockets.io, etc. On the other hand, it is
> easier to start using. I guess I would vote for Slack (non-binding) just to
> try it out.
>
> [1] http://rauchg.com/slackin/
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk

[dsetrakyan]

On Mon, Aug 10, 2015 at 2:35 PM, Raul Kripalani <[hidden email]> wrote:

> Hey Dmitriy,
>
> On Mon, Aug 10, 2015 at 9:53 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> > Let's decide on Slack vs. IRC. Any preferences?
>
>
> Could you start a separate [VOTE] thread for this?
>
> My concern with Slack is the concept of public channels does not exist,
> unlike IRC where anybody can join a channel anytime without providing an
> identity. Although there are solutions like slackin [1] used by other
> non-ASF projects like neo4j, sockets.io, etc. On the other hand, it is
> easier to start using. I guess I would vote for Slack (non-binding) just to
> try it out.
>
>

I am of an opinion that we should try it. I am sensitive to Cos' concerns
and agree that it is not a substitute for the dev list, but at the same
time, I believe that it could be a great tool for quick Q&A. Would be ideal
if Slack chats could be sent to the dev list on a daily basis as a safety
net.

Does anyone else have a preference here?

> [1] http://rauchg.com/slackin/
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

[Konstantin Boudnik-2]

On Mon, Aug 10, 2015 at 02:52PM, Dmitriy Setrakyan wrote:

> On Mon, Aug 10, 2015 at 2:35 PM, Raul Kripalani <[hidden email]> wrote:
>
> > Hey Dmitriy,
> >
> > On Mon, Aug 10, 2015 at 9:53 PM, Dmitriy Setrakyan <[hidden email]>
> > wrote:
> >
> > > Let's decide on Slack vs. IRC. Any preferences?
> >
> >
> > Could you start a separate [VOTE] thread for this?
> >
> > My concern with Slack is the concept of public channels does not exist,
> > unlike IRC where anybody can join a channel anytime without providing an
> > identity. Although there are solutions like slackin [1] used by other
> > non-ASF projects like neo4j, sockets.io, etc. On the other hand, it is
> > easier to start using. I guess I would vote for Slack (non-binding) just to
> > try it out.
> >
> >
> I am of an opinion that we should try it. I am sensitive to Cos' concerns
> and agree that it is not a substitute for the dev list, but at the same
> time, I believe that it could be a great tool for quick Q&A. Would be ideal
> if Slack chats could be sent to the dev list on a daily basis as a safety
> net.

I am not concerned about Slack or IRC or hipchat or another solution per se.
I want to be certain that the significant communications happening on those
channels will be reflected in the Apache media ie dev@ or JIRA

> Does anyone else have a preference here?
>
>
> > [1] http://rauchg.com/slackin/
> >
> > Regards,
> >
> > *Raúl Kripalani*
> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > Integration specialist
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >

[Raul Kripalani-2]

On Mon, Aug 10, 2015 at 10:41 PM, Konstantin Boudnik <[hidden email]> wrote:

> On Mon, Aug 10, 2015 at 10:20PM, Raul Kripalani wrote:
> > On Mon, Aug 10, 2015 at 9:37 PM, Konstantin Boudnik <[hidden email]>
> wrote:
> >
> > > That's a good idea. However, decisions made on the chat _have_ to be
> > > recorded in the email.
> >
> > Actually, I'd like to drill into that.
> >
> > It's not a matter of *recording* a decision taken in a chat, but
> recording
> > the *content* of the discussion, along with possible options to move
> > forward. Discussions can start spontaneously in a chat, regardless of
> who's
> > actually present. It would be unfair for decisions to be taken in absence
> > of others who simply weren't around at the time.
>
> I am not arguing with this. And I am not saying that a decisions from a
> chat
> should be followed by anyone if the consensus weren't reached. The point I
> am
> making is that off-line discussions have to be recorded (either as email or
> JIRA, depends on how the project operates) for future reference, if they
> have
> _any_ impact on the project.
>

You initially said that *decisions* have to be recorded in Apache media,
and that's what I was objecting to. You then changed your terminology and I
agree with this last stance of yours.

In my view, decisions of significance should *not* be taken in chat, and
then reported to the mailing lists. That's already too late. Decisions
should be taken *in the mailing lists* with exposure to the entire
community. In other words, a discussion in chat developing into a
significant change should be moved over to the mailing list *before* a
decision is taken.

> > The decision itself should be taken in the mailing list – thus giving the
> > entire community to voice out their opinion. If the changes are if the
> > changes are substantial, structural or of significant impact, a VOTE is
> > recommended by The Apache Way [1], and it's useful for the poster to
> > indicate if lazy consensus applies. For smaller things, it suffices to
> open
> > a JIRA task and explain what was done and why.
>
> While your reference is certainly correct, the Apache Way isn't based on
> voting. Apache Way is based on an explicit or an implicit consensus.
> Voting-based system is a democracy; fortunately Apache isn't one. But let's
> not go in this direction - it has been covered multiple times elsewhere.
>

I never said that the Apache Way was based on voting. How you arrived to
that conclusion, I don't understand. All I said is that changes that are
substantial, structural or of significant impact should be voted. That's
what the The Apache Way advocates. In practice, those will be only a
handful.

> Cos
>
> > Sorry to be a PITA; but I'm sharing what has worked in other projects I'm
> > involved in for the benefit and evolution of Ignite.
> >
> > [1] https://www.apache.org/foundation/voting.html
> >
> > Regards,
> >
> > *Raúl Kripalani*
> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > Integration specialist
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
>

[Konstantin Boudnik-2]

On Mon, Aug 10, 2015 at 11:29PM, Raul Kripalani wrote:

> On Mon, Aug 10, 2015 at 10:41 PM, Konstantin Boudnik <[hidden email]> wrote:
>
> > On Mon, Aug 10, 2015 at 10:20PM, Raul Kripalani wrote:
> > > On Mon, Aug 10, 2015 at 9:37 PM, Konstantin Boudnik <[hidden email]>
> > wrote:
> > >
> > > > That's a good idea. However, decisions made on the chat _have_ to be
> > > > recorded in the email.
> > >
> > > Actually, I'd like to drill into that.
> > >
> > > It's not a matter of *recording* a decision taken in a chat, but
> > recording
> > > the *content* of the discussion, along with possible options to move
> > > forward. Discussions can start spontaneously in a chat, regardless of
> > who's
> > > actually present. It would be unfair for decisions to be taken in absence
> > > of others who simply weren't around at the time.
> >
> > I am not arguing with this. And I am not saying that a decisions from a
> > chat
> > should be followed by anyone if the consensus weren't reached. The point I
> > am
> > making is that off-line discussions have to be recorded (either as email or
> > JIRA, depends on how the project operates) for future reference, if they
> > have
> > _any_ impact on the project.
> >
>
> You initially said that *decisions* have to be recorded in Apache media,
> and that's what I was objecting to. You then changed your terminology and I
> agree with this last stance of yours.

Yeah, I guess I wasn't very precise, was I? Appreciate the clarification.

> In my view, decisions of significance should *not* be taken in chat, and
> then reported to the mailing lists. That's already too late. Decisions
> should be taken *in the mailing lists* with exposure to the entire
> community. In other words, a discussion in chat developing into a
> significant change should be moved over to the mailing list *before* a
> decision is taken.

Semi-agree: let's consider a decision which is made on the chat by a
significant part of the community and then got recorder on the list or JIRA.
At this point the rest of community, not exposed to the chat discussion, has
the change to chime and object or correct it. That where the consensus focal
point is. So, I guess we are talking about the same semantics but in a
somewhat different form.

Cos

> > > The decision itself should be taken in the mailing list – thus giving the
> > > entire community to voice out their opinion. If the changes are if the
> > > changes are substantial, structural or of significant impact, a VOTE is
> > > recommended by The Apache Way [1], and it's useful for the poster to
> > > indicate if lazy consensus applies. For smaller things, it suffices to
> > open
> > > a JIRA task and explain what was done and why.
> >
> > While your reference is certainly correct, the Apache Way isn't based on
> > voting. Apache Way is based on an explicit or an implicit consensus.
> > Voting-based system is a democracy; fortunately Apache isn't one. But let's
> > not go in this direction - it has been covered multiple times elsewhere.
> >
>
> I never said that the Apache Way was based on voting. How you arrived to
> that conclusion, I don't understand. All I said is that changes that are
> substantial, structural or of significant impact should be voted. That's
> what the The Apache Way advocates. In practice, those will be only a
> handful.
>
>
> > Cos
> >
> > > Sorry to be a PITA; but I'm sharing what has worked in other projects I'm
> > > involved in for the benefit and evolution of Ignite.
> > >
> > > [1] https://www.apache.org/foundation/voting.html
> > >
> > > Regards,
> > >
> > > *Raúl Kripalani*
> > > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > > Integration specialist
> > > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > > http://blog.raulkr.net | twitter: @raulvk
> >

[Raul Kripalani]

On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> Would be ideal
> if Slack chats could be sent to the dev list on a daily basis as a safety
> net.
>

That would be great. There's Slack Digest [1] we can try. There are
integrations also with Zapier [2] and IFTTT [3], although I think none
offers daily digest emails. Worse comes to worst, we can build something
directly against the Slack channels.history API [4]. A little Camel
integration, off the top of my head ;-)

[1] http://slackdigest.com/digest.html
[2] https://zapier.com/zapbook/slack/
[3] https://ifttt.com/slack
[4] https://api.slack.com/methods/channels.history

*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

[Konstantin Boudnik-2]

On Mon, Aug 10, 2015 at 11:41PM, Raul Kripalani wrote:
> On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> > Would be ideal
> > if Slack chats could be sent to the dev list on a daily basis as a safety
> > net.

I imagine that it will just raise a noise level on the dev@ list and most ppl
will have to filter it out. If you feel like having these chats recorded -
consider creating a separate list for all. But really I think even that is
excessive.

> That would be great. There's Slack Digest [1] we can try. There are
> integrations also with Zapier [2] and IFTTT [3], although I think none
> offers daily digest emails. Worse comes to worst, we can build something
> directly against the Slack channels.history API [4]. A little Camel
> integration, off the top of my head ;-)
>
> [1] http://slackdigest.com/digest.html
> [2] https://zapier.com/zapbook/slack/
> [3] https://ifttt.com/slack
> [4] https://api.slack.com/methods/channels.history
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk

[Raul Kripalani]

On Mon, Aug 10, 2015 at 10:46 PM, Konstantin Boudnik <[hidden email]> wrote:

> Please don't - see my other email: the consensus in Apache isn't built on
> voting.
> If a discuss-thread can not bring the closure to an issue the vote will
> always
> be a horrible instrument for it. Some ppl will be in minority and you're
> going
> to have a badly-broken democracy all over again.
>

Yeah, agree. Voting isn't an instrument to use continuously and it seems
this won't be a conflictive point anyway.

I was actually concerned that this decision is being taken 2 nesting levels
into an email thread that touches on 4 other points. I would prefer a top
level thread: whether a DISCUSS or a VOTE thread, I don't actually care.
The important thing is to announce that this discussion/decision is taking
place and not keep it buried inside a wider thread.

In fact, the choice of Slack vs. IRC is actually an important topic. Other
non-ASF projects have reported higher user engagement since they migrated
from IRC to Slack. That's why I think it's a milestone and it should
receive due exposure.

Anyway, I'm happy if you guys are happy like this ;-)

Regards,

*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

[nivanov]

Zapier +1 from me. We can have pretty automated digest posted to the dev
list, if we want.

--
Nikita Ivanov


On Mon, Aug 10, 2015 at 3:41 PM, Raul Kripalani <[hidden email]> wrote:

> On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <[hidden email]
> >
> wrote:
>
> > Would be ideal
> > if Slack chats could be sent to the dev list on a daily basis as a safety
> > net.
> >
>
> That would be great. There's Slack Digest [1] we can try. There are
> integrations also with Zapier [2] and IFTTT [3], although I think none
> offers daily digest emails. Worse comes to worst, we can build something
> directly against the Slack channels.history API [4]. A little Camel
> integration, off the top of my head ;-)
>
> [1] http://slackdigest.com/digest.html
> [2] https://zapier.com/zapbook/slack/
> [3] https://ifttt.com/slack
> [4] https://api.slack.com/methods/channels.history
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

[Sergi]

Guys,

I don't think I'm going to hang in these chats anyways. Reading digests of
chats seems to me pointless waste of time as well.
Probably I'll filter them out as Cos suggested :) Devlist is enough, I
don't understand the roots of this discussion.

Sergi

2015-08-11 2:02 GMT+03:00 Nikita Ivanov <[hidden email]>:

> Zapier +1 from me. We can have pretty automated digest posted to the dev
> list, if we want.
>
> --
> Nikita Ivanov
>
>
> On Mon, Aug 10, 2015 at 3:41 PM, Raul Kripalani <[hidden email]> wrote:
>
> > On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <
> [hidden email]
> > >
> > wrote:
> >
> > > Would be ideal
> > > if Slack chats could be sent to the dev list on a daily basis as a
> safety
> > > net.
> > >
> >
> > That would be great. There's Slack Digest [1] we can try. There are
> > integrations also with Zapier [2] and IFTTT [3], although I think none
> > offers daily digest emails. Worse comes to worst, we can build something
> > directly against the Slack channels.history API [4]. A little Camel
> > integration, off the top of my head ;-)
> >
> > [1] http://slackdigest.com/digest.html
> > [2] https://zapier.com/zapbook/slack/
> > [3] https://ifttt.com/slack
> > [4] https://api.slack.com/methods/channels.history
> >
> > *Raúl Kripalani*
> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> > Integration specialist
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
>