git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Date
Aug 7, 2017, 14:33 UTC
Message-ID
<1502116408.3172.3.camel@gmail.com>
In-Reply-To
<xmqqini6dkmu.fsf@gitster.mtv.corp.google.com>
On Wed, 2017-08-02 at 09:01 -0700, Junio C Hamano wrote:
Show 16 quoted lines
> 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.

Show 8 quoted lines
> 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.

Show 7 quoted lines
> 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
Previous: Kaartic SivaraamNext: Philip Oakley
Message 22 of 23 in “doc: fix small issues in SubmittingPatches”
  1. 1/2 doc: fix small issues in SubmittingPatchesKaartic Sivaraam, Jul 30, 2017
  2. 2/2 doc: add another way to identify if a patch has been mergedKaartic Sivaraam, Jul 30, 2017
  3. Philip OakleyJul 30, 2017
  4. Kaartic SivaraamJul 30, 2017
  5. 1/2 doc: fix small issues in SubmittingPatchesKaartic Sivaraam, Jul 30, 2017
  6. Stefan BellerJul 31, 2017
  7. Junio C HamanoJul 31, 2017
  8. Kaartic SivaraamAug 1, 2017
  9. Stefan BellerAug 1, 2017
  10. Kaartic SivaraamAug 2, 2017
  11. Junio C HamanoAug 2, 2017
  12. Stefan BellerAug 2, 2017
  13. Kaartic SivaraamAug 3, 2017
  14. 1/2 doc: fix small issues in SubmittingPatchesKaartic Sivaraam, Aug 1, 2017
  15. 2/2 doc: add another way to identify if a patch has been mergedKaartic Sivaraam, Aug 1, 2017
  16. Stefan BellerAug 1, 2017
  17. Kaartic SivaraamAug 2, 2017
  18. Junio C HamanoAug 2, 2017
  19. Junio C HamanoAug 2, 2017
  20. Stefan BellerAug 2, 2017
  21. Kaartic SivaraamAug 7, 2017
  22. Kaartic SivaraamAug 7, 2017
  23. Philip OakleyAug 1, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.