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 >
