git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Kaartic Sivaraam <kaarticsivaraam91196@gmail.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: Wed, 2 Aug 2017 10:58:18 -0700	[thread overview]
Message-ID: <CAGZ79kYArf6R-vx1-Lm4X_ANLMrXc3VNd2aCQMnqq3J6y-s31Q@mail.gmail.com> (raw)
In-Reply-To: <xmqq60e6djcu.fsf@gitster.mtv.corp.google.com>

On Wed, Aug 2, 2017 at 9:28 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.

The example I cited contains two important parts that I considered.

> I tried to follow as best I could, here's my attempt (please advise).

    ok, I can help out as that conversation is very likely
    to deliver some impact.

> I'm a bit overwhelmed by the documentation for submitting a patch!

    That may be either a contributors problem (lacking time or
    motivation to go through a long document) or a problem with
    the community.

Here are my thoughts on the "problem with the community":

    We are using Git ourselves as a mere (content-)version-control-system
    What we really need is a community oriented workflow tool:
    Instead of writing a long-winded document on what you can
    do wrong in each contribution, we should have technical solutions
    that just present the single issue that needs addressing.

    For example when a contributor forgets to sign-off a patch,
    git-send-email could warn about the missing sign-off and
    present the rationale why our community needs sign-offs.

    As this is specific to our community, such that it cannot be
    baked into git-send-email, but rather we'd need a distributed
    configuration that is respected by various git commands.

We had the discussion on shipping a project config which is
respected by git commands lately when discussing the
.gitorder file that I proposed, and IIRC such a thing "doesn't
quite fit into the broad picture of a version control system",
so maybe we need another tooling in our community?

    Another example would be to show a hint/advice when
    commits with no or very short commit message are created.
    (also this is project specific, other communities do not expect
    commit messages as we do. So they would not want to utilize
    such an advice given).

>>
>> 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.
>
> Just to make sure there is no misunderstanding, I am not saying "do
> not update the doc to have an abbreviated version, because we will
> get more clueless newbies".  I am saying that it is not a good idea
> to add an abbreviated version _before_ we are prepared to handle
> more patches from new people that require high-touch help.
>
> If you are volunteering to coordinate and form the onboarding
> helpers group, that would be great.

I would not want to explain the same thing over and over again,
but rather have a technical solution that explains the problem and
solution once it is detected.

Coming up with a technical solution for each little quirk
is not the hard part (e.g. grep for the sign off string, count lines of
the commit message), but rather to put it in place. (How can I make
sure that contributors run these small checker scripts?
Currently I cannot.)

Thanks.

  reply	other threads:[~2017-08-02 17:58 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 [this message]
2017-08-07 14:34                     ` Kaartic Sivaraam
2017-08-07 14:33                 ` Kaartic Sivaraam
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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=CAGZ79kYArf6R-vx1-Lm4X_ANLMrXc3VNd2aCQMnqq3J6y-s31Q@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kaarticsivaraam91196@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).