From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvtddgudeglecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeefgeffiefhfeettdfhvdfgteekffffudekvedtvedtvdfgveeu udevgedvgeegtdenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth X-ME-Proxy: 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 To: Jerin Jacob , "Burakov, Anatoly" , Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: Maxime Coquelin , dpdk-dev , techboard@dpdk.org, "Jim St. Leger" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.