mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Christian Couder <>
Cc: Junio C Hamano <>,
	Emily Shaffer <>,
	git <>, Jakub Narebski <>,
	Markus Jansen <>,
	Gabriel Alcaras <>
Subject: Re: RFC - Git Developer Blog
Date: Tue, 6 Aug 2019 09:27:30 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Aug 06, 2019 at 06:59:21AM +0200, Christian Couder wrote:

> When Git Rev News was started I thought that there could be such a
> group effort to encourage each other to publish articles in it, but I
> must say that outside the group of editors (currently Jakub, Markus,
> Gabriel and me) it hasn't happened much.
> Each month though there are a small number of people helping on
> smaller things like short news, typos, releases, etc. And people who
> are interviewed are doing a great job when they accept to be
> interviewed.
> Maybe it's also not clear that we could accept other kind of articles
> than just articles focused on what happens on the mailing list. I
> think we have generally tried to highlight articles by Git developers
> that were published on their blogs or their company's blog though.

I think the audience may be a bit different for Rev News versus a blog.
I'd expect the blog to be written for people who use Git, and want to
learn how to use new features, or maybe broaden their understanding of
it. Rev News seems a lot more technical to me, and mostly of interest to
people who are part of the development community.

Which isn't to say those two things can't co-exist on a site[1] or a
blog. But I think there needs to be some way for people to subscribe to
one but not the other. Because I suspect that too many posts about the
development process would drive away users who would be interested in
the less-technical posts.


[1] By the way, Rev News lives over at, but there's no
    reason it couldn't be integrated (from the user's perspective) with
    the site.

    I wouldn't want it in the same repo for technical reasons, but it
    could be or similar (and possibly styled in a
    similar way).

    If you're happy with it separate, I have no objections. I just
    wanted to make it clear it's an option.

  reply	other threads:[~2019-08-06 13:27 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 [this message]
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
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).