From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 30F7DA04A4;
	Mon, 25 May 2020 22:34:10 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id 4E00F1D9A0;
	Mon, 25 May 2020 22:34:09 +0200 (CEST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com
 [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 34FED1D962;
 Mon, 25 May 2020 22:34:07 +0200 (CEST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47])
 by mailout.nyi.internal (Postfix) with ESMTP id 6953B5C0221;
 Mon, 25 May 2020 16:34:06 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute7.internal (MEProxy); Mon, 25 May 2020 16:34:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=fm1; bh=
 ooBFdedzUsImXrljoJlB5KBiqshf90B9yHpRdkg33L0=; b=Do7KnNKmQsfiaMBU
 uwSfc3WK0or45fJ4Nal67TGJ9sDnNliIv0xfj7Ddo2M5QYRFgOCBnmPantiH9YLx
 ZseuELYuGDAjnuKi+qviN2AKyyp4+M9MxXtDttNRr8tzT1sbmUoVpPqgSHeGxa7O
 FliFh2G1YmgWsrq3gpgxJhrEu/L+idGwvDI7m2tOkQjari5R3s0Ae6JirkRiUfCK
 ldQwsenrdw4BFbnBPdWg86QDjRM1sqaB4hIakutsYiYGDaVH8nKPtE6N4crREo8C
 W40u/r4WR7TOdiZzvjhctFPfqdlXqd8XC3aiWzm8kyPZPm7qINMTSn8Egod7ZBGJ
 MYe/bg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm2; bh=ooBFdedzUsImXrljoJlB5KBiqshf90B9yHpRdkg33
 L0=; b=Lygm3mpvA5pbOjl+yJbxB8TrvwvOgNplfVc3XJlCE/rO8GNZq0RBScCU4
 3wSrcA2s0R0IbUf87fWfRH9Lb/x3ou5cvGdadr8WqsQZ0ABBDPul888NL31Jzy8D
 3h63LavNnE2dS4DFzb6Sy+MTqjVQt22YYgxh/k1EugBCS6d/Mh+ZMIpJSXrfd3b+
 1BgeIa0GyIBTWrOuf4UusY9KYZZbgA/0nkkznvyfNXnXDafNdy2zaoKC/YRBOee4
 y0HPKd9OEZ3p+bjkk1NMWKQVPBnYS37w6eMqEJCHoOdRptx2TBv4V9Fs781fShJn
 B6NPvQLFTWiiu+BtJhqonvlGZTzEQ==
X-ME-Sender: <xms:vSvMXhw4T0sN4AAxrNKgat9TJ-OUPuIScktDw9m9jGWFuk3ZIM4F1A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvtddgudeglecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm
 rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
 ggtffrrghtthgvrhhnpeefgeffiefhfeettdfhvdfgteekffffudekvedtvedtvdfgveeu
 udevgedvgeegtdenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh
 fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr
 lhhonhdrnhgvth
X-ME-Proxy: <xmx:vSvMXhQo6oZa2uDunrJURB9cxUtwQzSxdh2lmkdhuMXa4Zw5xxVT6g>
 <xmx:vSvMXrVghROOr2b2t-sfRJfo5g7Q5luAzwduM7ff_vo0q91ULk17dg>
 <xmx:vSvMXjg3bIb8eTRz_fR7JaD8rYyN091KAvyRBQSpI89R_Oegvq3B5g>
 <xmx:vivMXqN3Ji46b8GH3pER23QS-4Q-5UEKPM31ETxpsPn6g-4YP0chVw>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id 2BE28306657F;
 Mon, 25 May 2020 16:34:05 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Jerin Jacob <jerinjacobk@gmail.com>, "Burakov,
 Anatoly" <anatoly.burakov@intel.com>,
 Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>, dpdk-dev <dev@dpdk.org>,
 techboard@dpdk.org, "Jim St. Leger" <jim.st.leger@intel.com>
Date: Mon, 25 May 2020 22:34:04 +0200
Message-ID: <1854859.fY831ScpFY@thomas>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60FF5@smartserver.smartshare.dk>
References: <98CBD80474FA8B44BF855DF32C47DC35C60FEA@smartserver.smartshare.dk>
 <11959277.FkLDZFFinP@thomas>
 <98CBD80474FA8B44BF855DF32C47DC35C60FF5@smartserver.smartshare.dk>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Subject: Re: [dpdk-dev] [dpdk-techboard] Consider improving the
	DPDKcontribution processes
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

25/05/2020 20:44, Morten Br=F8rup:
> From: Thomas Monjalon
> > 25/05/2020 18:09, Burakov, Anatoly:
> > > obviously, but i have a suspicion that we'll get more of it if we
> > lower
> > > the barrier for entry (not the barrier for merge!). I think there is
> > a
> > > way to lower the secondary skill level needed to contribute to DPDK
> > > without lowering coding/merge standards with it.
>=20
> That is exactly what I am asking for: Lowering the barrier and increasing=
 the feeling of success for newcomers. (The barrier for merge is probably f=
ine; I'll leave that discussion to the maintainers.)

I understand.


> > About the barrier for entry, maybe it is not obvious because I don't
> > communicate a lot about it, but please be aware that I (and other
> > maintainers I think) are doing a lot of changes in newcomer patches
> > to avoid asking them knowing the whole process from the beginning.
> > Then frequent contributors get educated on the way.
>=20
> Great! I wish that every developer would think and behave this way.
>=20
> >=20
> > I think the only real barrier we have is to sign the patch
> > with a real name and send an email to right list.
> > The ask for SoB real name is probably what started this thread
> > in Morten's mind. And the SoB requirement will *never* change.
>=20
> The incorrect Signed-off-by might be the only hard barrier (which we cann=
ot avoid). But that did not trigger me.
>=20
> I was raising the discussion to bring attention to soft barriers for cont=
ributors. What triggered me was the request to split the patch into multipl=
e patches; a kind of feedback I have seen before. For an experienced git us=
er, this is probably very easy, but for a git newbie (like myself), it basi=
cally means starting all over and trying to figure out the right set of git=
 commands to do this, which can be perceived as a difficult task requiring =
a lot of effort.

Yes I am aware about this difficulty.
It is basically knowing git-reset and git-add -p.
I agree a cookbook for this kind of thing is required.

I would like to do the split for newcomers,
but we need also to validate the explanations of each commit.
A solution in such case is to send the split so the newbie can just
fill what is missing.
This kind of workflow is really what we should look at improving.


> Perhaps we could supplement the Contributor Guidelines with a set of cook=
books for different steps in the contribution process, so reviewers can be =
refer newcomers to the relevant of these as part of the feedback. Just like=
 any professional customer support team has a set of canned answers ready f=
or common customer issues. (Please note: I am not suggesting adding an AI/M=
L chat bot reviewer to the mailing list!)

OK


> The amount of Contributor Guideline documentation is also a balance... it=
 must be long enough to contain the relevant information to get going, but =
short enough for newcomers to bother reading it.

Yes, we need short intros and long explanations when really needed.
It is touching another issue: we lack some documentation love.