Hi,
A draft of Git Rev News edition 1 is available here:
https://github.com/git/git.github.io/blob/master/rev_news/draft/edition-1.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue:
https://github.com/git/git.github.io/issues/17
You can also reply to this email.
I tried to cc the persons who appear in the edition but maybe I missed
some, sorry about that.
Thomas and myself plan to publish this edition on Wednesday the 25th of March.
We call it an "edition" instead of an "issue" to avoid confusion with
GitHub issues.
Thanks,
Christian
Thanks.
The most important question I would ask you is this:
Did you two enjoy writing it?
That ends up counting the most, as it affects the quality of the
end result (readers would enjoy reading it and feel the love you
put into its production), and also its longer term relevance (if it
gets to be more burden than enjoyment to you, it won't last).
And I hope the answer is a resounding yes ;-)
A few comments:
- Some might be a bit too detailed. Because each header is
a pointer to the list archive, picking only the points that you
found are the most thought-provoking may be a good way
to shorten it (and readers interested in the topic can follow
the link). Another would be to drop the mention like "Junio
also reviewed..." that does not say what was said in the
review. If a review did not have much thought-provoking
value to deserve a summary, perhaps it is enough only to
leave it to be discovered by readers who are so interested
to follow the link to find the full discussion.
- You do not list your own contribution to the discussions,
but you should. Of course it would take some discipline
to prevent the newsletter from appearing to have a self-
promoting agenda, but I think you two are adult enough
to be capable of handling that ;-)
- As a periodical, you would want to have "This edition covers
period between these two dates" at the beginning of each
and every edition. Publication date may serve as the upper
bound of the range, but for an inaugural one, it is essential
to have the date the coverage begins.
- As an inaugural edition, we may want to have a word on
the purpose of the publication. Perhaps a sentence or two
to declare what the publication is about in the "Welcome to"
section is good. I would imagine that the primary purpose
is to cover the discussions on the list (but don't call that
"the list" in this paragraph, but spell it out to help readers,
as "the Git mailing list") that is not visible in the "git log"
output from my tree.
- As an inaugural edition, we may want to have a word on
how it came in existence by covering the discussion that
led to its birth. Perhaps the discussion that led to the
publication should be made into as an item on its own,
next to "make git-pull a builtin", "Forbid log --graph..." etc.
Because it is neither a review nor a support discussion,
"Reviews & Support" heading may want to become
"Discussions". I think that is a better title for the section
anyway, if its purpose is "what happened on the list that
are not visible from "git log", as I expect future editions
to cover design discussions that advanced the shared
understanding of a problem but not quite solidified to
become a patch series.
Thomas and myself plan to publish this edition on Wednesday the 25th of March.
We call it an "edition" instead of an "issue" to avoid confusion with
GitHub issues.
Good thinking.
Thanks again.
On Sun, Mar 22, 2015 at 7:47 PM, Junio C Hamano [off-list ref] wrote:
Thanks.
The most important question I would ask you is this:
Did you two enjoy writing it?
To be clear, apart from some minor wording and nitpicking, I only
contributed the links from outside the list. This is an activity I
mostly do regardless, either on Twitter or at Google+. Gathering the
links in Git Rev News just means I collect them in a central place
instead of sporadically posting on social media. So I think I can keep
it up for an extended period, and if I ever get fed up, there are
hopefully others who can keep that part going.
Refining list activity into headlines, like Christian did, is a bigger
challenge in my eyes. I think this depends on having someone active on
the list, who also has time for producing this reader's digest.
I guess the long term success depends, as with any volunteer effort,
on how many others join in the fun, and how popular it gets outside
the list.
- As a periodical, you would want to have "This edition covers
period between these two dates" at the beginning of each
and every edition. Publication date may serve as the upper
bound of the range, but for an inaugural one, it is essential
to have the date the coverage begins.
Good point. There hasn't been a decision on frequency. Weekly is a
good rhythm for publications seeking readership, but that's a lot of
work. My vote is we should first aim for a monthly consistent release.
I'll try working this into the draft, and Christian may change as he
sees fit.
- As an inaugural edition, we may want to have a word on
the purpose of the publication. Perhaps a sentence or two
to declare what the publication is about in the "Welcome to"
section is good. I would imagine that the primary purpose
is to cover the discussions on the list (but don't call that
"the list" in this paragraph, but spell it out to help readers,
as "the Git mailing list") that is not visible in the "git log"
output from my tree.
Noted. I'l try working this in as well.
- As an inaugural edition, we may want to have a word on
how it came in existence by covering the discussion that
led to its birth. Perhaps the discussion that led to the
publication should be made into as an item on its own,
next to "make git-pull a builtin", "Forbid log --graph..." etc.
Because it is neither a review nor a support discussion,
"Reviews & Support" heading may want to become
"Discussions". I think that is a better title for the section
anyway, if its purpose is "what happened on the list that
are not visible from "git log", as I expect future editions
to cover design discussions that advanced the shared
understanding of a problem but not quite solidified to
become a patch series.
I hope it's OK that I leave this bit to Christian.
Thanks for the feedback!