Hi Emily, On Tue, Aug 06, 2019 at 02:00:15PM -0700, Emily Shaffer wrote: > On Tue, Aug 06, 2019 at 08:19:15AM -0400, Derrick Stolee wrote: > > On 8/6/2019 12:52 AM, Andrew Ardill wrote: > > > On Tue, 6 Aug 2019 at 11:51, Emily Shaffer <emilyshaffer@xxxxxxxxxx> wrote: > > > > > >> Are folks interested in writing and reviewing this kind of content? > > > > I am interested in writing and reviewing! Here are some topics I am > > interested in writing: > > > > * Updates to the commit-graph feature > > * What is a multi-pack-index and what is it for? > > * Git at Scale: What makes a repo big, and how to avoid it? > > * Advanced Git config settings > > > > Here are some topics I'd be interested in seeing in the wild > > (and was considering writing them myself if I didn't see them elsewhere): > > > > * Partial clone: what, why, and how? > > * Life cycle of a patch series > > * Crafting perfect patches with interactive add and rebase > Oh, I'd love to write one on interactive add and rebase. Maybe it's > weird to have a favorite Git feature, but mine's add -p :) > > Since we're volunteering, my todo list for my personal blog also > contains: > > - How to use bisect > - How to use Git pathspecs > > I also have a couple pre-existing personal blog posts on > nasamuffin.github.io: > > - How to use git format-patch and git send-email for mailing list based > reviews > - Overview of Git object types > > > > > It would also be helpful to have a post for every major release > > highlighting new features and giving users examples of how to use them. > > Taylor has been writing these on the GitHub blog [1], but maybe he > > would be interested in writing them for this new venue? > > > > [1] https://github.blog/2019-06-07-highlights-from-git-2-22/ > > > > > The idea sounds great, and I would be happy to review content - even > > > if it's only for readability and spelling! > > > > > > In terms of collaborating, I've found the processes over at Git Rev > > > News[0] straightforward and sensible, if you're looking for ideas. > > > > I agree that the review process there is helpful, and users contributing > > edits via PRs to a feature branch works quite well. I would also suggest > > writing a "request for review" on the mailing list before merging any > > pull requests. > > > > One goal I think would be important is that this blog is that the posts > > come with some amount of blessing from "the Git Dev Community". That is, > > they should be service-agnostic and focused on helping _all_ Git users. > > By this do you mean "not about how to use Git with Github", or "not > about how to use Git for Windows"? I initially read it as the latter but > I think you mean the former, right? > > I believe there's a lot of value in the former - lately it seems to me > like the lines are really blurred between which parts are Git and which > parts are Github. It'd be nice to clear up some of that confusion and > writing pieces concerning "vanilla Git". Yeah, this is a concern of mine, too. I try and make quite clear that GitHub isn't the author of these features (we are for some, but obviously not all), and instead that we're merely summarizing the interesting work that's happening upstream, and that the project is, of course, open-source. The posts aren't really a "using Git with GitHub" guide, per-se, although we usually will have remotes with 'git@xxxxxxxxxx' in them when included in examples. > > That said, I also suggest that the authors can list their professional > > affiliation as some minimum amount of credit to their employers. Something > > as simple as "Author: Derrick Stolee, Microsoft" would go a long way to > > justifying the work it takes to write these on the community blog and not > > a company-owned blog. > > Yes, I agree - this seems to have a double win of lending credibility to > the author and giving good optics for the company. Plus, as mentioned > before, crossposting seems like a good fit here. Doubly agreed. I am considering proposing a blog post about some of the work around alternates that we have done upstream, and the impact it's had on GitHub. This sort of walks the line between talking about an upstream contribution and a more traditional corporate engineering blog post, so I think that type of content certainly belongs on a comapny blog. > > Thanks, > > -Stolee Thanks, Taylor
