Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2017-08-02 at 09:01 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91196@xxxxxxxxx> writes:
> 
> > On Tue, 2017-08-01 at 10:46 -0700, Stefan Beller wrote:
> > > So maybe we want to cut a lot of workflow related commendatory from
> > > the SubmitingPatches and then encourage to read such man page?
> > > 
> > 
> > That's right. Maybe Documentation/SubmittingPatches needs a revamp to
> > be one-time contributor friendly? Maybe introducing a "gist" for people
> > who do not have the time to read the whole document, might be of help?
> 
> First of all, I do not think lack of one-time contributor is
> something we should consider to be a problem.  Supporting new
> contributors so that they will be involved more in the development
> process is a lot more important issue.
> 
First of all, I would like to clear a little mis-interpretation here.
Though I used the phrase 'one-time contributor', I didn't want a gist
that targets only *those* people. I was thinking, in general, about
people who would like to contribute but find the documentation
overwhelming (an example might be the thread pointed out by Stefan). In
which case, they would want to check if their patch meets the *basic
criterias* and send it to the community hoping it would be accepted
with at least 75% probability.

I'll send a patch that tries to make 'Documentation/SubmittingPatches'
less overwhelming without losing much of it's content, some time soon.

> I think the exchange Stefan cited was an example that we want to
> have more of.  The contributor is indicating that, even though the
> patch could be a drive-by patch by one-timer from whom we will never
> hear again, it is not--the contributor is willing to learn the way
> things are done here, and showing that it is worth _our_ time to
> explain the things so that the future patches will take less effort
> to accept on our side.
> 
I thought a *good* 'gist' would obviate that kind of effort. Let's see
if I could come up with something.

> Because we do not have a group of dedicated volunteers, it is done
> by more experienced people around here but that can be done only
> when they have time.  I view it as a more severe problem than any
> documentation.  An abbreviated version of the documentation to
> invite more new people means that we must be prepared to give more
> high-touch onboarding help to them.
> 
I think an abbrievated documentation whilst inviting new people
*should* obviate the onboarding help, saving everyone's time (win-win).

-- 
Kaartic




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux