You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Raul Kripalani <ra...@apache.org> on 2015/08/10 18:58:49 UTC
Collaboration process at Ignite
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
Re: Collaboration process at Ignite
Posted by chandresh pancholi <ch...@gmail.com>.
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 <ra...@apache.org> 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 <ra...@apache.org> 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:chandresh.pancholi@flipkart.com
Contact:08951803660
Re: Collaboration process at Ignite
Posted by Raul Kripalani <ra...@apache.org>.
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 <ra...@apache.org> 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
>
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
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 <ds...@apache.org>
> 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 <ra...@apache.org> 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
> > >
> >
Re: Collaboration process at Ignite
Posted by Nikita Ivanov <ni...@gmail.com>.
Slack [+1]
--
Nikita Ivanov
On Mon, Aug 10, 2015 at 1:53 PM, Dmitriy Setrakyan <ds...@apache.org>
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 <ra...@apache.org> 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
> >
>
Re: Collaboration process at Ignite
Posted by Raul Kripalani <ra...@apache.org>.
On Mon, Aug 10, 2015 at 10:46 PM, Konstantin Boudnik <co...@apache.org> 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
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Aug 10, 2015 at 10:35PM, Raul Kripalani wrote:
> Hey Dmitriy,
>
> On Mon, Aug 10, 2015 at 9:53 PM, Dmitriy Setrakyan <ds...@apache.org>
> 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
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, Aug 11, 2015 at 03:18PM, Pavel Tupitsyn wrote:
> +1 for email instead of chats.
>
> > Yeah, reviewboard sucks badly.
> Does it? I heard that it may be painful to install, but from user point of
> view it worked fine for me before. Certainly a lot better than no review
> tool at all.
Just my personal experience of using it on-n-off in the last 5 years or so.
> On Tue, Aug 11, 2015 at 3:00 PM, Denis Magda <dm...@gridgain.com> wrote:
>
> > I share Sergey's point.
> >
> > I tend to use instant messaging as less as possible turning off or muting
> > messengers.
> > Plus, I won't look over unread messages in chats when I have free time.
> > However I'm fully OK to look into the interesting topics on the dev list
> > while drinking a cup of tea :)
> >
> > --
> > Denis
> >
> >
> > On 8/11/2015 5:07 AM, Dmitriy Setrakyan wrote:
> >
> >> On Mon, Aug 10, 2015 at 6:10 PM, Sergi Vladykin <sergi.vladykin@gmail.com
> >> >
> >> wrote:
> >>
> >> Guys,
> >>>
> >>> I don't think I'm going to hang in these chats anyways.
> >>>
> >>
> >> Hm... that's actually a valid point. I am more than willing to try it, and
> >> think it is not a bad idea for adoption, but it would be nice to find out
> >> if the rest of the community is OK with monitoring the chat room.
> >>
> >> Can others respond here?
> >>
> >> D.
> >>
> >>
> >
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
Re: Collaboration process at Ignite
Posted by Pavel Tupitsyn <pt...@gridgain.com>.
+1 for email instead of chats.
> Yeah, reviewboard sucks badly.
Does it? I heard that it may be painful to install, but from user point of
view it worked fine for me before. Certainly a lot better than no review
tool at all.
On Tue, Aug 11, 2015 at 3:00 PM, Denis Magda <dm...@gridgain.com> wrote:
> I share Sergey's point.
>
> I tend to use instant messaging as less as possible turning off or muting
> messengers.
> Plus, I won't look over unread messages in chats when I have free time.
> However I'm fully OK to look into the interesting topics on the dev list
> while drinking a cup of tea :)
>
> --
> Denis
>
>
> On 8/11/2015 5:07 AM, Dmitriy Setrakyan wrote:
>
>> On Mon, Aug 10, 2015 at 6:10 PM, Sergi Vladykin <sergi.vladykin@gmail.com
>> >
>> wrote:
>>
>> Guys,
>>>
>>> I don't think I'm going to hang in these chats anyways.
>>>
>>
>> Hm... that's actually a valid point. I am more than willing to try it, and
>> think it is not a bad idea for adoption, but it would be nice to find out
>> if the rest of the community is OK with monitoring the chat room.
>>
>> Can others respond here?
>>
>> D.
>>
>>
>
--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com
Re: Collaboration process at Ignite
Posted by Ognen Duzlevski <og...@gmail.com>.
On Tue, Aug 11, 2015 at 7:00 AM, Denis Magda <dm...@gridgain.com> wrote:
> I share Sergey's point.
>
> I tend to use instant messaging as less as possible turning off or muting
> messengers.
> Plus, I won't look over unread messages in chats when I have free time.
> However I'm fully OK to look into the interesting topics on the dev list
> while drinking a cup of tea :)
>
I think it is perfectly OK to have an IRC channel for the developers.
Having one does not obligate anyone to sit on it and "man it" 24/7. I think
one of the things to understand is that Ignite is supposed to move from a
"company run" project to a community run one. That means that there will be
(hopefully) various people sitting on the IRC channel at all sorts of
hours. I am not a Java developer but I have enough development experience
under my belt to one day maybe sit down and pick a JIRA ticket to work on.
It is much easier asking a series of quick questions, sharing some example
code and getting details on various possible approaches (and their up/down
sides) on an IRC channel with a live dev or two than writing up emails.
Just my $.02
Re: Collaboration process at Ignite
Posted by Denis Magda <dm...@gridgain.com>.
I share Sergey's point.
I tend to use instant messaging as less as possible turning off or
muting messengers.
Plus, I won't look over unread messages in chats when I have free time.
However I'm fully OK to look into the interesting topics on the dev list
while drinking a cup of tea :)
--
Denis
On 8/11/2015 5:07 AM, Dmitriy Setrakyan wrote:
> On Mon, Aug 10, 2015 at 6:10 PM, Sergi Vladykin <se...@gmail.com>
> wrote:
>
>> Guys,
>>
>> I don't think I'm going to hang in these chats anyways.
>
> Hm... that's actually a valid point. I am more than willing to try it, and
> think it is not a bad idea for adoption, but it would be nice to find out
> if the rest of the community is OK with monitoring the chat room.
>
> Can others respond here?
>
> D.
>
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Aug 10, 2015 at 09:41PM, Vishal Garg wrote:
> I think chat is more effective as a 1-1 interaction or Limited group
> interaction 2-3) like collaborative design of a solution or code review
>
> Replacing DEV list as chat could be chaos. Another useful tool if we can
> for collaborative design is a code review tool. Nothing reads better than
> the code itself. But doing collaborative code review on JIRA is just not
> scalable.
>
> Last time we looked at something, we could not find a good free tool that suffices that
Yeah, reviewboard sucks badly. IntelliJ Upsource is pretty good, but I'd say
it needs to bake-in for a bit longer.
Cos
> /vishal
>
> Sent from my iPhone
>
> > On Aug 10, 2015, at 9:18 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > I encourage everyone here to reflect on this emails http://bit.ly/1IASLEK from
> > Niclas Hedhman. He's one of the Apache folks who I am listening very
> > closely whenever he says something.
> >
> > That another reason why I avoid noisy chatter-channels like IRC, Skype, or
> > Slack (yes, I am making an effort to stay out of the company's channels, for
> > instance): if ppl need my input - they will email me or IM me. If they don't -
> > I won't waste my time shouting to the wind, as no one will ever scroll up and
> > re-read two days worth of a chat history.
> >
> > Filtering tons of stuff that is highly irrelevant to what you're working on at
> > the moment is incredibly counter-productive. Replacing one's personal
> > communication discipline with a digital channel chain is hardly a solution to
> > grow a community; or perhaps a viable development community.
> >
> > Cos
> >
> >> On Mon, Aug 10, 2015 at 07:46PM, Nikita Ivanov wrote:
> >> Can actually Sergey's point too... Ideally Slack could/should replace dev
> >> lists - but we can't go this route anyways. If community doesn't see a need
> >> for chat solution (in addition to email lists), I'm fine with that too.
> >>
> >> --
> >> Nikita Ivanov
> >>
> >>
> >> On Mon, Aug 10, 2015 at 7:07 PM, Dmitriy Setrakyan <ds...@apache.org>
> >> wrote:
> >>
> >>> On Mon, Aug 10, 2015 at 6:10 PM, Sergi Vladykin <se...@gmail.com>
> >>> wrote:
> >>>
> >>>> Guys,
> >>>>
> >>>> I don't think I'm going to hang in these chats anyways.
> >>>
> >>>
> >>> Hm... that's actually a valid point. I am more than willing to try it, and
> >>> think it is not a bad idea for adoption, but it would be nice to find out
> >>> if the rest of the community is OK with monitoring the chat room.
> >>>
> >>> Can others respond here?
> >>>
> >>> D.
> >>>
Re: Collaboration process at Ignite
Posted by Vishal Garg <ga...@gmail.com>.
I think chat is more effective as a 1-1 interaction or Limited group interaction 2-3) like collaborative design of a solution or code review
Replacing DEV list as chat could be chaos.
Another useful tool if we can for collaborative design is a code review tool. Nothing reads better than the code itself. But doing collaborative code review on JIRA is just not scalable.
Last time we looked at something, we could not find a good free tool that suffices that
/vishal
Sent from my iPhone
> On Aug 10, 2015, at 9:18 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> I encourage everyone here to reflect on this emails http://bit.ly/1IASLEK from
> Niclas Hedhman. He's one of the Apache folks who I am listening very
> closely whenever he says something.
>
> That another reason why I avoid noisy chatter-channels like IRC, Skype, or
> Slack (yes, I am making an effort to stay out of the company's channels, for
> instance): if ppl need my input - they will email me or IM me. If they don't -
> I won't waste my time shouting to the wind, as no one will ever scroll up and
> re-read two days worth of a chat history.
>
> Filtering tons of stuff that is highly irrelevant to what you're working on at
> the moment is incredibly counter-productive. Replacing one's personal
> communication discipline with a digital channel chain is hardly a solution to
> grow a community; or perhaps a viable development community.
>
> Cos
>
>> On Mon, Aug 10, 2015 at 07:46PM, Nikita Ivanov wrote:
>> Can actually Sergey's point too... Ideally Slack could/should replace dev
>> lists - but we can't go this route anyways. If community doesn't see a need
>> for chat solution (in addition to email lists), I'm fine with that too.
>>
>> --
>> Nikita Ivanov
>>
>>
>> On Mon, Aug 10, 2015 at 7:07 PM, Dmitriy Setrakyan <ds...@apache.org>
>> wrote:
>>
>>> On Mon, Aug 10, 2015 at 6:10 PM, Sergi Vladykin <se...@gmail.com>
>>> wrote:
>>>
>>>> Guys,
>>>>
>>>> I don't think I'm going to hang in these chats anyways.
>>>
>>>
>>> Hm... that's actually a valid point. I am more than willing to try it, and
>>> think it is not a bad idea for adoption, but it would be nice to find out
>>> if the rest of the community is OK with monitoring the chat room.
>>>
>>> Can others respond here?
>>>
>>> D.
>>>
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
I encourage everyone here to reflect on this emails http://bit.ly/1IASLEK from
Niclas Hedhman. He's one of the Apache folks who I am listening very
closely whenever he says something.
That another reason why I avoid noisy chatter-channels like IRC, Skype, or
Slack (yes, I am making an effort to stay out of the company's channels, for
instance): if ppl need my input - they will email me or IM me. If they don't -
I won't waste my time shouting to the wind, as no one will ever scroll up and
re-read two days worth of a chat history.
Filtering tons of stuff that is highly irrelevant to what you're working on at
the moment is incredibly counter-productive. Replacing one's personal
communication discipline with a digital channel chain is hardly a solution to
grow a community; or perhaps a viable development community.
Cos
On Mon, Aug 10, 2015 at 07:46PM, Nikita Ivanov wrote:
> Can actually Sergey's point too... Ideally Slack could/should replace dev
> lists - but we can't go this route anyways. If community doesn't see a need
> for chat solution (in addition to email lists), I'm fine with that too.
>
> --
> Nikita Ivanov
>
>
> On Mon, Aug 10, 2015 at 7:07 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > On Mon, Aug 10, 2015 at 6:10 PM, Sergi Vladykin <se...@gmail.com>
> > wrote:
> >
> > > Guys,
> > >
> > > I don't think I'm going to hang in these chats anyways.
> >
> >
> > Hm... that's actually a valid point. I am more than willing to try it, and
> > think it is not a bad idea for adoption, but it would be nice to find out
> > if the rest of the community is OK with monitoring the chat room.
> >
> > Can others respond here?
> >
> > D.
> >
Re: Collaboration process at Ignite
Posted by Nikita Ivanov <ni...@gmail.com>.
Can actually Sergey's point too... Ideally Slack could/should replace dev
lists - but we can't go this route anyways. If community doesn't see a need
for chat solution (in addition to email lists), I'm fine with that too.
--
Nikita Ivanov
On Mon, Aug 10, 2015 at 7:07 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Mon, Aug 10, 2015 at 6:10 PM, Sergi Vladykin <se...@gmail.com>
> wrote:
>
> > Guys,
> >
> > I don't think I'm going to hang in these chats anyways.
>
>
> Hm... that's actually a valid point. I am more than willing to try it, and
> think it is not a bad idea for adoption, but it would be nice to find out
> if the rest of the community is OK with monitoring the chat room.
>
> Can others respond here?
>
> D.
>
Re: Collaboration process at Ignite
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Aug 10, 2015 at 6:10 PM, Sergi Vladykin <se...@gmail.com>
wrote:
> Guys,
>
> I don't think I'm going to hang in these chats anyways.
Hm... that's actually a valid point. I am more than willing to try it, and
think it is not a bad idea for adoption, but it would be nice to find out
if the rest of the community is OK with monitoring the chat room.
Can others respond here?
D.
Re: Collaboration process at Ignite
Posted by Ognen Duzlevski <og...@gmail.com>.
+1 on IRC. I hate slack with passion.
On Mon, Aug 10, 2015 at 8:10 PM, Sergi Vladykin <se...@gmail.com>
wrote:
> 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 <ni...@gmail.com>:
>
> > 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 <ra...@apache.org>
> wrote:
> >
> > > On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org
> > > >
> > > 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
> > >
> >
>
Re: Collaboration process at Ignite
Posted by Sergi Vladykin <se...@gmail.com>.
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 <ni...@gmail.com>:
> 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 <ra...@apache.org> wrote:
>
> > On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org
> > >
> > 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
> >
>
Re: Collaboration process at Ignite
Posted by Nikita Ivanov <ni...@gmail.com>.
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 <ra...@apache.org> wrote:
> On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> 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
>
Re: Collaboration process at Ignite
Posted by Raul Kripalani <ra...@evosent.com>.
Good point, Cos.
If the goal is to back up the chats, Slack offers that feature but it's a
paid one for over 10,000 msgs. I'll ask them if they are willing to offer
the service for free to an ASF project. To my knowledge, the person who
contacted Slack from the community-dev thread didn't ask this question.
Option B is to generate and upload the transcripts to a server, and link
out from the Apache Ignite site. Then use Google Search to make them
searchable.
But in practice this is only helpful to end users who want to check out if
their question has already been asked. Devs will likely never resort to the
transcripts and will expect decisions and big changes to be discussed on
the MLs.
If, on the other hand, the goal is to broadcast the matters of the day for
everyone to stay updated on a daily basis, I agree with Cos. Unnecessary
noise.
Raúl.
On 10 Aug 2015 23:47, "Konstantin Boudnik" <co...@apache.org> wrote:
> On Mon, Aug 10, 2015 at 11:41PM, Raul Kripalani wrote:
> > On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > 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
>
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Aug 10, 2015 at 11:41PM, Raul Kripalani wrote:
> On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <ds...@apache.org>
> 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
Re: Collaboration process at Ignite
Posted by Raul Kripalani <ra...@apache.org>.
On Mon, Aug 10, 2015 at 10:52 PM, Dmitriy Setrakyan <ds...@apache.org>
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
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Aug 10, 2015 at 02:52PM, Dmitriy Setrakyan wrote:
> On Mon, Aug 10, 2015 at 2:35 PM, Raul Kripalani <ra...@apache.org> wrote:
>
> > Hey Dmitriy,
> >
> > On Mon, Aug 10, 2015 at 9:53 PM, Dmitriy Setrakyan <ds...@apache.org>
> > 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
> >
Re: Collaboration process at Ignite
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Mon, Aug 10, 2015 at 2:35 PM, Raul Kripalani <ra...@apache.org> wrote:
> Hey Dmitriy,
>
> On Mon, Aug 10, 2015 at 9:53 PM, Dmitriy Setrakyan <ds...@apache.org>
> 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
>
Re: Collaboration process at Ignite
Posted by Raul Kripalani <ra...@apache.org>.
Hey Dmitriy,
On Mon, Aug 10, 2015 at 9:53 PM, Dmitriy Setrakyan <ds...@apache.org>
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
Re: Collaboration process at Ignite
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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 <ra...@apache.org> 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
>
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Aug 10, 2015 at 11:29PM, Raul Kripalani wrote:
> On Mon, Aug 10, 2015 at 10:41 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> > On Mon, Aug 10, 2015 at 10:20PM, Raul Kripalani wrote:
> > > On Mon, Aug 10, 2015 at 9:37 PM, Konstantin Boudnik <co...@apache.org>
> > 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
> >
Re: Collaboration process at Ignite
Posted by Raul Kripalani <ra...@evosent.com>.
On Mon, Aug 10, 2015 at 10:41 PM, Konstantin Boudnik <co...@apache.org> wrote:
> On Mon, Aug 10, 2015 at 10:20PM, Raul Kripalani wrote:
> > On Mon, Aug 10, 2015 at 9:37 PM, Konstantin Boudnik <co...@apache.org>
> 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
>
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Aug 10, 2015 at 10:20PM, Raul Kripalani wrote:
> On Mon, Aug 10, 2015 at 9:37 PM, Konstantin Boudnik <co...@apache.org> 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
Re: Collaboration process at Ignite
Posted by Raul Kripalani <ra...@apache.org>.
On Mon, Aug 10, 2015 at 9:37 PM, Konstantin Boudnik <co...@apache.org> 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
Re: Collaboration process at Ignite
Posted by Konstantin Boudnik <co...@apache.org>.
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