I could write a lot of things about the Github acquisition by Microsoft. About Github's embrace and extend of git, and how it passed unnoticed by people who now fear the same thing now that Microsoft is in the picture. About the stultifying effects of Github's centralization, and its retardant effect on general innovation in spaces around git and software development infrastructure.

Instead I'd rather highlight one simple criteria you can consider when you are evaluating any git hosting service, whether it's Gitlab or something self-hosted, or federated, or P2P[1], or whatever:

Consider all the data that's used to provide the value-added features on top of git. Issue tracking, wikis, notes in commits, lists of forks, pull requests, access controls, hooks, other configuration, etc.
Is that data stored in a git repository?

Github avoids doing that and there's a good reason why: By keeping this data in their own database, they lock you into the service. Consider if Github issues had been stored in a git repository next to the code. Anyone could quickly and easily clone the issue data, consume it, write alternative issue tracking interfaces, which then start accepting git pushes of issue updates and syncing all around. That would have quickly became the de-facto distributed issue tracking data format.

Instead, Github stuck it in a database, with a rate-limited API, and while this probably had as much to do with expediency, and a certain centralized mindset, as intentional lock-in at first, it's now become such good lock-in that Microsoft felt Github was worth $7 billion.

So, if whatever thing you're looking at instead of Github doesn't do this, it's at worst hoping to emulate that, or at best it's neglecting an opportunity to get us out of the trap we now find ourselves in.

[1] Although in the case of a P2P system which uses a distributed data structure, that can have many of the same benefits as using git. So, git-ssb, which stores issues etc as ssb messages, is just as good, for example.

The rethinkdb‘s website has (finally) been updated and Gentoo Linux is now listed on the installation page!

Meanwhile, we have bumped the ebuild to version 2.3.6 with fixes for building on gcc-6 thanks to Peter Levine who kindly proposed a nice PR on github.

The open source Git project has just released Git 2.8.0, featuring a variety of features, bugfixes, and other improvements from over 70 contributors. Here are some of the most useful new features:

Parallel fetches of submodules

Using "git submodules", one Git repository can include other Git repositories as subdirectories¹. This can be a useful way to include libraries or other external dependencies into your main project. The top-level repository specifies which submodules it wants to include, and which version of each submodule.

When you fetch into the top-level repository, you typically want to fetch into the submodule repositories as well:

git fetch --recurse-submodules

If you have a lot of submodules, all of these fetches can be time-consuming; git fetch is essentially run in each submodule in turn. But now you can speed things up by fetching from multiple submodules in parallel. For example,

git fetch --recurse-submodules --jobs=4

runs four submodule fetches at the same time. This should be a real time saver! [source]

Don't guess my identity!

If you use the same name and email address to commit to all of your Git projects, then you can configure those values once and for all in your global .gitconfig file:

git config --global user.name 'Me Myself'
git config --global user.email me@example.com

But if, say, you want Git to use one email address for your open source projects and a different one for your work projects, you've undoubtedly made the mistake of committing to a new Git repository without having first set your email address in that repository. In this situation, Git emits a warning, but it creates the commit anyway, using an email address that it guesses from the local system hostname. If you're trying to do something as complicated as different addresses for different projects, this is almost certainly not what you want.

Now you can tell Git not to guess, but rather to insist that you set user.name and user.email explicitly before it will let you commit:

git config --global user.useconfigonly true

[source]

Convergence with Git for Windows

There has recently been a big push to make Git feel as comfortable on Windows as it does on Linux and OS X. For example, it is relatively expensive to start processes on Windows, so many Git commands that were originally written as scripts have been rewritten in C to make them snappier.

In this release, a bunch of Windows-specific changes have been brought back from the Git for Windows project into the main Git project. This continuing effort will make it easier to keep the functionality of Git in sync across platforms as new features are added. [source, source, source, source]

Along the same lines, several Git commands that use text files as input have been made to accept both LF and CRLF line endings. That should reduce friction on Windows, where many tools may produce files with CRLF line endings. [source]

Security fixes

Git 2.8.0 includes the security fixes for CVE-2016-2324 that were first made available in Git 2.7.4. This vulnerability is not known to have any exploits in the wild, but could result in executing arbitrary code when cloning a malicious repository. We recommend that everybody upgrade to a version of Git with these fixes, namely 2.4.11+, 2.5.5+, 2.6.6+, 2.7.4+, or of course 2.8.0+.

In addition to these fixes, this release contains a number of cleanups designed to make it easier to avoid similar bugs in the future.

[source]

Brief mentions

• Git's clean and smudge filters can now be turned off by setting them to the empty string. This feature is notable mainly because it is used by the new git lfs clone command, which can dramatically reduce the time to clone a repository that uses Git LFS. [source]

• Git configuration values are read from several different places, including system-level, user-level, and repository-specific files. This can make it hard to figure out where a setting has to be changed. Now you can use git config --show-origin to show where a particular setting came from:

  $ git config --show-origin user.name
  file:/home/me/.gitconfig    Me Myself

  [source]

• You can use the new git ls-files --eol FILENAME to help diagnose end-of-line problems in a file:

  $ git ls-files --eol README.md screenshot.png
  i/lf    w/lf    attr/                   README.md
  i/-text w/-text attr/                   screenshot.png

  The output shows (i) the EOL style auto-detected from the file's contents in the index, (w) the EOL style detected from file's contents in the working copy, and (attr) the style that is configured for the file via gitattributes. [source]

• git ls-remote can now also tell you a remote repository's default branch:

  $ git ls-remote --symref origin HEAD
  ref: refs/heads/master  HEAD
  db6696f653b917509dac1ac13b922e12773a84ff        HEAD

  [source]

• Support for cloning via the rsync protocol, which was superseded long ago by better alternatives, has been dropped. [source]

The rest of the iceberg

That's just a sampling of the changes in Git 2.8.0. Check out the the full release notes for the complete list.

[1] Git submodules are analogous to Subversion's svn:externals.

One of the most important elements of creating a strong community is shaping the new contributor experience. The on-boarding experience for new participants plays a huge role in how quickly someone can get up and running on your project. The most successful projects make this experience simple and accessible.

Getting someone started with their first contribution in a community typically follows a linear path, from discovery through appreciation. The environmental factors surrounding your project play the largest role in making that experience comfortable, empowering, and worthwhile.

The new contributor on-ramp

The on-ramp is a framework for growing your community. From getting your project noticed through celebrating a new contributor, building out each area will help your community thrive.

At the beginning is a user that hasn't yet discovered your community. And at the end is a user that has made their first contribution to your project. Along their journey, the user usually goes through six steps of progress:

1. Discover that the community exists and welcomes contributions from new members.
2. Setup tools needed to build the project and create a contribution (e.g. editors, compilers, libraries, frameworks).
3. Learn skills and knowledge to understand the codebase, contribution guidelines, and understand how their contribution will be reviewed.
4. Identify tasks to work on, or know what kind of contributions would be welcome and worthwhile.
5. Get help with the questions, queries, and sticking points they may have with their first contribution.
6. Feel appreciated when they have successfully made their first contribution and at other key moments to know that the community is kind, supportive, and welcoming!

Within each of the six steps, there are many different things you could implement. This series will take a look at each step in turn, and for the rest of this post we'll delve into what you can do to help your project be discovered.

Discover

"If you build it, they will come" only works for Kevin Costner and baseball fields. For your project, the first step in building a community is making your project discoverable.

There are three goals for the discover step in the on-ramp:

1. Welcome and inform new visitors about the community
2. Establish your project as inclusive and welcoming of new contributors
3. Show people how they can begin to contribute to the community

There are plenty of options on how to achieve these goals, below are a few of the basics that every community can use.

Create a README.md file

Whenever you visit a GitHub repo, the contents of the README file is displayed underneath the file listing. It is a great opportunity to give a quick overview, including:

• What your project is and what it does
• How to build and run the project
• Ask for new contributors
• Provide details on how to get started, such as a CONTRIBUTING.md file

By using Markdown you'll be able to format the README for easier viewing and link to resources for new contributors. Plus it'll look great!

Create a project website

While a README.md is a good start, many projects can benefit from a comprehensive website. A full site gives the project a home for things like extensive guides, tutorials, and blogs.

Build the site from the perspective of a new user to your project:

• Highlight the features of the project (with screenshots, if applicable)
• How to install it
• How to use it
• Where to get in touch with the community
• How to get involved in the community

The front page should have the most important information, like what the project does, how to get it, and how new contributors can join. Check out Bootstrap, Jekyll, or Electron for some ideas for your project site.

A fast way to get started with this is with GitHub Pages, which provides free hosting for a project website. When you create this site it will be publicly hosted at http://<yourproject>.github.io.

Engage on social media

Social media is a powerful tool for raising awareness about your project. Many people will follow the social media accounts of projects to keep up-to-date on news and announcements, it is also a great place to engage new contributors. Though tread lightly at first as social media can be time-consuming to maintain.

Twitter and Facebook are the best places to start. After registering the accounts, take some time to spruce up the profiles. Match the account design to your project website, and link back to it.

You can grow your community on social media by providing valuable and interesting content. Images and video are great additions to social posts. Be careful not to over-saturate your audience with too much content though. You should stick to:

• Links to blog posts with updates, news, and other material
• Videos with demos, screenshots of new features, and other visual content
• Invitations for users to participate in issues, surveys, or other ways of getting engaged
• News about growth of the project, partnerships with companies/organizations, and interesting use cases

A useful tool to simplify social media is Buffer. You can prepare your posts and content ahead of time, and it'll publish it on a schedule. By dedicating time to your social media strategy, you can free up your time for the week ahead.

Promote the community

There are many other ways to get the word out and highlight the work happening in your community. A few places you can start:

• Organize Google Hangouts on Air to host an interactive show that gets the community involved. A bi-monthly show could be used to demonstrate new features, answer questions, or feature a new contributor.
• Do interviews on podcasts, news website, and blogs to talk about the vision of the project and get people involved. It is often as simple as asking the site or podcast if they'd be interested in featuring your project.
• Speak at conferences to show the great work going on in the project and provide simple steps for how people can get involved.

The new contributor on-ramp is a valuable framework to make the new user experience simple, empowering, and effective. These basic building blocks will setup your project to have a healthy and thriving community of contributors. We'll dive into the Setup Tools and Learn Skills steps in the next installment of the series.

It's hard to solve a problem when important details are missing. Now project maintainers can add templates for Issues and Pull Requests to projects, helping contributors add the right details at the start of a thread. This is the first of many improvements to Issues and Pull Requests that we're working on based on feedback from the community.

To add an Issue template to a repository create a file called ISSUE_TEMPLATE in the root directory. A file extension is optional, but Markdown files (.md) are supported. Markdown support makes it easy to add things like headings, links, @-mentions, and task lists to your templates.

Pull Request templates follows the same pattern: add a file called PULL_REQUEST_TEMPLATE to the root directory of your repository.

If you're worried about the added clutter in the root directory of your project, we also added support for a .github/ folder. You can put CONTRIBUTING.md, ISSUE_TEMPLATE.md, and PULL_REQUEST_TEMPLATE.md files in .github/ and everything will work as expected.

Check out the documentation for additional information on the feature.

We are glad to announce that PhpStorm 10.0.3 build 143.1770 is available for download.

This build includes new features, bug fixes and improvements from the PHP, web and IntelliJ platform sides. From the PHP side, this build delivers:

• Fix of scalar types in namespaced classes for PHP 7 (WI-28283)
• Copyright plugin for PhpStorm
• Symfony 3 support for Command Line Tools

Please see our issue tracker for the full list of PHP-related issues fixed and release notes.

Download PhpStorm 10.0.3 build 143.1770 for your platform and please report any bugs or feature request to our Issue Tracker.

The Drive to Develop!
-JetBrains PhpStorm Team