Mailing-List: contact dev-help@ignite.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.incubator.apache.org
Date: Mon, 10 Aug 2015 13:37:00 -0700
From: Konstantin Boudnik <cos@apache.org>
To: dev@ignite.incubator.apache.org
Subject: Re: Collaboration process at Ignite
Message-ID: <20150810203659.GD27100@boudnik.org>
Mail-Followup-To: dev@ignite.incubator.apache.org
References: 
 <CAKoNANvwWGX4iayBucxUZq79tfqwpQiG6RZuDrWRO1UAi1pWpw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAKoNANvwWGX4iayBucxUZq79tfqwpQiG6RZuDrWRO1UAi1pWpw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

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