Welcome to the 56th edition of Git Rev News, a digest of all things Git. For our goals, the archives, the way we work, and how to contribute or to subscribe, see the Git Rev News page on git.github.io.
This edition covers what happened during the month of September 2019.
Derrick Stolee, who prefers to be called Stolee, emailed the mailing list after the Virtual Contributor Summit (see previous edition) saying he wanted to further discuss some ideas, that had been shared during the Summit, about “Inclusion & Diversity” with the goal of making the community more welcoming to new contributors of all kinds.
He listed some possible problems that could prevent new contributors entering the community:
Discovering how to contribute to Git is non-obvious.
Submitting to a mailing list is a new experience for most developers. This includes the full review and discussion process.
The high standards for patch quality are intimidating to new contributors.
Some people do not feel comfortable engaging in a community without a clear Code of Conduct. This discomfort is significant and based on real experiences throughout society.
Since Git development happens in a different place than where users acquire the end product, some are not aware that they can contribute.
Then Stolee proposed actions to address the problems:
Improve the documentation for contributing to Git.
Add more pointers to GitGitGadget.
Introduce a new “mentors” mailing list.
Add an official Code of Conduct.
Advertise that Git wants new contributors.
Each action was explained and justified, sometimes pointing to interesting research like the recent paper "”We Don’t Do That Here”: How Collaborative Editing With Mentors Improves Engagement in Social Q&A Communities”.
Stolee also proposed some metrics to be measured between releases to monitor how the community are doing:
How many first-time contributors sent a patch?
How many contributors had their first commit accepted into the release?
How many contributors started reviewing?
How many total patches/reviews did the list receive?
His email was very detailed with many suggestions about how to implement the actions, and he asked interesting questions to gather peoples’ opinion.
Denton Liu replied to Stolee sharing some thoughts as a “relatively new contributor (just less than a year)”. He said that from his experience to get more contributors, we should try to answer the “how do we make it more fun to contribute to Git?” question.
He recalled that most of his time learning to contribute to Git “stemmed from the fact that there’s a lot of tribal knowledge that’s not really written down anywhere”.
As Stolee had mentioned the “My First Contribution” document, which was recently contributed by Emily Shaffer, Denton said that it would have really helped him get started.
Denton also suggested improving transparency about what happens to patches sent to the mailing list.
Mike Hommey replied to Stolee suggesting an additional problem which is that newcomers don’t really have any idea what they could contribute.
Johannes Schindelin, alias Dscho, replied to Mike that newcomers need experienced developers to validate the ideas they would like to implement in Git, before they can be confident enough to work on them. And they also need to be shown ideas they could implement. Dscho then talked about the GitGitGadget issue list which is open and “intended to accumulate possible project ideas”. Dscho also acknowledged the Chromium Git issue list which is another issue tracker with a similar purpose.
Replying to Stolee, Jeff King, alias Peff, who is responsible for the main Git web site, suggested improving the community page to add more information for beginners. He said he was open to accepting patches or pull requests.
Elijah Newren mostly agreed with Stolee’s email, but suggested a less strongly worded tone when talking about goals and existing problems.
Junio Hamano, the Git maintainer, replied to Stolee about the goal of the project and the metrics that we could use with the following:
We first should make sure that we serve existing users and existing community members well. So well that other people who are not yet our “existing” users and members would want to become part of us, in order to join the fun and share the benefit. If we cannot serve even the existing members well, we shouldn’t be talking about acquiring new members.
He then proposed to measure “community-member happiness” with metrics like “This many percent of total community member population have been active this month”.
The discussion involved a number of other Git developers like Jakub Narębski, Emily Shaffer, Garima Singh, Pierre Tardy, Philip Oakley and Randall S. Becker.
A number of people commented especially on the subject of adding an official Code of Conduct, which will be reported on in a separate article below.
Otherwise it remains to be seen if many actions will be taken to make the project more welcoming to new contributors.
[PATCH] add a Code of Conduct document
Following the Virtual Contributor Summit (see previous edition) and the discussions about growing the Git community (see the article above), Jeff King, alias Peff, decided to send a patch to add a code of conduct.
In his patch he says that “it may be a good time to cement our expectations when things are quiet, since it gives everybody some distance rather than focusing on a current contentious issue”. Many people indeed agreed in the previous discussions with that point of view, and the idea of a Code of Conduct in the first place.
Peff says that his patch adapts the Contributor Covenant Code of Conduct from https://www.contributor-covenant.org/version/1/4/code-of-conduct.html and that “it’s also the same document used by the Git for Windows project”.
One of the changes is that for dealing with community issues, the document spreads the responsibility to the Project Leadership Committee (git@sfconservancy.org) instead of the only maintainer, Junio C Hamano.
Peff also mentioned a commit by Michael Haggerty from June 2013 that he found in a previous discussion and that has nice set of guidelines about how to review code.
A number of the replies were about the Project Leadership Committee as it’s not easy to know who is part of it. This was acknowledged by Peff who sent a follow-up patch to address the issue by listing the Project Leadership Committee members with their email addresses and by saying that they can also be contacted individually.
Even though there was some disagreement, in general most of the people taking part in the discussion agreed with Peff’s patches. Junio later sent a follow-up email with the subject “Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks” to get more developers to formally agree with the final patch, which then several did.
The commit adding the Code of Conduct has since been merged into the master branch.
Various
Light reading
Commit graph drawing algorithms by pvigier (Pierre Vigier), describes algorithms used by various tools including one in pvigier’s prototype git client called gitamine.
Git Pathspecs and How to Use Them by Adam Giese.
GitHub Actions, the missing notes: CMake, Qt and IFW by Michele ‘skypjack’ Caini, shows how he uses GitHub Actions in his project. (GitHub Actions, still in public beta, were first covered in Git Rev News #44)
An Unintentionally Comprehensive Introduction to GitHub Actions CI by Tierney Cyren – with example of an application build on top of Node.js.
Scheduling Jekyll posts with Netlify and GitHub Actions by Nicholas C. Zakas on his Human Who Codes blog: using a GitHub Action cron job to schedule Netlify builds for static site generated blog posts (which was previously done using Netlify and AWS Lambda).
“git request-pull” and confusing diffstats [LWN.net] by Jonathan Corbet talks about what to do if the history to be pulled includes merges from outside (e.g. to obtain the dependencies for a fix), and why it happens.
How Bash completion works and
Adding Bash completion to my tool
by Chris Patuzzo; Git’s Bash completion can be found in
contrib/completion/git-completion.bash.
Git tools and sites
This edition of Git Rev News was curated by Christian Couder <christian.couder@gmail.com>, Jakub Narębski <jnareb@gmail.com>, Markus Jansen <mja@jansen-preisler.de> and Gabriel Alcaras <gabriel.alcaras@telecom-paristech.fr> with help from Emily Shaffer, Luca Milanesio and George Espinoza.