mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Emily Shaffer <>
Subject: Re: RFC - Git Developer Blog
Date: Tue, 6 Aug 2019 09:20:52 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Aug 05, 2019 at 06:49:35PM -0700, Emily Shaffer wrote:

> Are folks interested in writing and reviewing this kind of content? Any
> ideas for where we may be able to host (maybe git-scm)?

I think it would make sense to have (and .org) with
this content. I'd be happy to deal with the technical side of setting
the name up. I think it should live in a different repository than the
main site, though (which is an overly-messy Rails app).

There actually used to be a blog section on the site. It discussed
various high-level concepts that hadn't made it into the Pro Git book
(whose content makes up most of the site). But as most of those were
eventually added to the book, the blog posts became staler versions of
the same content, and we dropped them.

Just to play devil's advocate for a moment: another venue for topics
like these:

>  - Using `git worktree` Effectively
>  - Overview of the Git Object Store
>  - Finding Regressions with `git bisect`
>  - Life of a Git Remote Request

might be to actually add them to the book (which started as a
single-author publication, but is CC-licensed and has taken lots of
community content over the years). The advantage there is that the book
content would always represent the most up-to-date coverage of those
topics, whereas blog posts sometimes grow stale over the years as nobody
is interested in updating them.

One downside is that it may be more annoying to try to integrate content
into the existing structure of the book. Another is that a blog is
something people subscribe to, so a post may generate attention/interest
in a topic (but nobody wants to see a feed of book updates!). A prime
example is something like a highlight of features after a new release,
which is not book content at all, and just serves to generate attention.

So I don't think I'm really seriously suggesting this as an alternative,
but maybe something to ponder.

> It could make sense to review contributions like this on the mailing
> list, so that we get the attention of those who wrote the features
> that are being covered in the blog posts - are we okay with the
> additional traffic?

Additional traffic is fine. I do suspect that blog posts in particular
would benefit from a more integrated review system like GitHub (or

  - I'd expect there to be a lot of images, and those systems make
    image diffs easy to see

  - the formatted output is going to be important to review; a
    browser-based review system makes it easier to see the formatted
    output (especially if they're written in markdown)

  - we're more likely to get/want drive-by fixes like typo corrections,
    so reducing friction for non-regular contributors is more important

Obviously you can apply many of the same mailing list vs web review
arguments that we've already had for writing Git itself (e.g., is
reviewing formatted output much different than looking at the output of
a compiled program?). But I think the nature of blog posts pushes it a
bit further towards web-based review.


  parent reply	other threads:[~2019-08-06 13:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-06  1:49 RFC - Git Developer Blog Emily Shaffer
2019-08-06  3:33 ` Junio C Hamano
2019-08-06  4:59   ` Christian Couder
2019-08-06 13:27     ` Jeff King
2019-08-06 21:07       ` Emily Shaffer
2019-08-07 17:00       ` Taylor Blau
2019-08-06  4:52 ` Andrew Ardill
2019-08-06 12:19   ` Derrick Stolee
2019-08-06 21:00     ` Emily Shaffer
2019-08-07 17:12       ` Taylor Blau
2019-08-07 17:07     ` Taylor Blau
2019-08-07 17:15       ` Junio C Hamano
2019-08-07 17:44         ` Taylor Blau
2019-08-06 13:20 ` Jeff King [this message]
2019-08-06 20:49   ` Emily Shaffer
2019-09-13 13:29     ` James Ramsay
2019-09-13 14:05       ` pedro rijo
2019-09-17 19:22         ` James Ramsay
2019-09-17 19:32           ` Emily Shaffer
2019-09-17 19:39             ` pedro rijo
2019-10-23 22:36       ` James Ramsay
2019-10-23 23:48         ` Jeff King

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:

  List information:

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

  git send-email \ \ \ \ \

* 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

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).