All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Stefan Beller <sbeller@google.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged
Date: Mon, 07 Aug 2017 20:03:28 +0530	[thread overview]
Message-ID: <1502116408.3172.3.camel@gmail.com> (raw)
In-Reply-To: <xmqqini6dkmu.fsf@gitster.mtv.corp.google.com>

On Wed, 2017-08-02 at 09:01 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> 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


  parent reply	other threads:[~2017-08-07 14:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-30 11:09 [PATCH 1/2] doc: fix small issues in SubmittingPatches Kaartic Sivaraam
2017-07-30 11:09 ` [PATCH 2/2] doc: add another way to identify if a patch has been merged Kaartic Sivaraam
2017-07-30 14:49 ` [PATCH 1/2] doc: fix small issues in SubmittingPatches Philip Oakley
2017-07-30 16:17   ` Kaartic Sivaraam
2017-07-30 16:18   ` Kaartic Sivaraam
2017-07-31 20:23     ` Stefan Beller
2017-07-31 20:34       ` Junio C Hamano
2017-08-01 15:59       ` Kaartic Sivaraam
2017-08-01 17:38         ` Stefan Beller
2017-08-02 12:22           ` [RFC] The correct and consistent alternative to quote a command ? Kaartic Sivaraam
2017-08-02 15:37             ` Junio C Hamano
2017-08-02 17:32             ` Stefan Beller
2017-08-03 15:35               ` Kaartic Sivaraam
2017-08-01 16:05       ` [PATCH 1/2] doc: fix small issues in SubmittingPatches Kaartic Sivaraam
2017-08-01 16:05         ` [PATCH 2/2] doc: add another way to identify if a patch has been merged Kaartic Sivaraam
2017-08-01 17:46           ` Stefan Beller
2017-08-02 12:32             ` Kaartic Sivaraam
2017-08-02 16:01               ` Junio C Hamano
2017-08-02 16:28                 ` Junio C Hamano
2017-08-02 17:58                   ` Stefan Beller
2017-08-07 14:34                     ` Kaartic Sivaraam
2017-08-07 14:33                 ` Kaartic Sivaraam [this message]
2017-08-01 21:04       ` [PATCH 1/2] doc: fix small issues in SubmittingPatches Philip Oakley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1502116408.3172.3.camel@gmail.com \
    --to=kaarticsivaraam91196@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.