ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <ra...@apache.org>
Subject Collaboration process at Ignite
Date Mon, 10 Aug 2015 16:58:49 GMT
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

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.

[2] https://ignite.incubator.apache.org/community/contribute.html


*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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message