Thomas Ferris Nicolaisen <tfnico@xxxxxxxxx> writes: > 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. I agree weekly would be too much for any hobbist, given how high-volume our list has, but I probably shouldn't have said "periodical". Surely, aiming for consistent update is a very good thing to gain reader trust if anything else, but it is OK if it were "we will see a new release when enough interesting things happen", too. The primary reason I suggested to explicitly state the beginning of coverage is to set and manage the expectation of the readers. I think the current draft roughly covers 1/4 - 1/3 of discussions that happened in the month of March 2015 and nothing earlier than that, so "This issue covers what happened in March" or something would be appropriate. I'll throw a pull-request. >> - 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. I took a stab at this myself, and threw another pull-request. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html