25/05/2020 20:44, Morten Brørup: > 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. > > 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 fine; > 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. > > Great! I wish that every developer would think and behave this way. > > > > > 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. > > The incorrect Signed-off-by might be the only hard barrier (which we cannot > avoid). But that did not trigger me. > > I was raising the discussion to bring attention to soft barriers for > contributors. What triggered me was the request to split the patch into > multiple patches; a kind of feedback I have seen before. For an experienced > git user, this is probably very easy, but for a git newbie (like myself), it > basically 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 > cookbooks 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 > for common customer issues. (Please note: I am not suggesting adding an AI/ML > 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.
