---- On Wed, 06 Jun 2018 06:43:42 +0100 Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote ----
> The only risk I can see in the situation is that Microsoft's usability team might well fix the peculiar and confusing nomenclature used. It is counter-intuitive to say the least to call comments on a version of a document a 'pull request' when no document is being pulled.
>
Below is my own opinion based on my own experience, you may find this input useful. One of the IT things I do is software development, I progressed from CVS to Subversion to git and have been using both externally-hosted and self-hosted repositories, bug trackers and similar services for quite a number of years.
"Pull request" is an established term in git workflow, GitHub before the sale had enough sense to use it properly. The simple reason for that was, git-based service was their only commercial business and GitHub had to get it right or to go home. They got it well enough back at the time, so when SourceForge dropped the ball really badly, its users had somewhere else to go, and the users did. So GitHub at a certain moment in time did their work much better than SourceForge, and SourceForge lost a significant user base to GitHub and other competitors, and that was fair and the change has been driven by a more or less normal feedback loop up to now.
Someone in Microsoft now may have an idea of their own, and suddenly claim pull requests on github.com are now not pull requests but "Microsoft collaboration review 2018 professional edition" or any other random string. However, given the established terminology such change would be an opposite of a fix. The problem is, Microsoft can make far more damage than this simple example, and had done that before so many times, and can do that again, because if Microsoft runs GitHub into the ground, they can just quickly drop it, grab the next toy and pretend nothing happened. The feedback loop is now broken for GitHub.
What it means for IETF depends on whether individual IETF contributors understood the properties of the two tools they used.
One tool is the git distributed version control system. It is a professional tool, it has its terminology, properties, implied workflow and intended use. Using a git repository for distributed version control is generally a good idea and provides (assuming proper use) a lot of redundancy, integrity and other good properties for long-term project survival.
github.com is (in plain technical language) a proprietary software made available online. It runs on top of git repositories and blends non-repository data with repository data very successfully. On one hand, it makes everyday work much easier to do. On the other, many users do not realize their projects, milestones, bug reports, comments and pull requests only exist on GitHub servers, and if suddenly that sole copy is gone (for whatever real world reason), the users can direct themselves to a copy of the EULA. When happens, this stops normal work and may even impact a project survival.
To sum it up, git is fine for its intended use, github.com is fine for its intended use, the fact GitHub is now about to lose its feedback loop is a perfect time for IETF GitHub users to check they have used each tool for its intended purpose, have committed all meaningful permanent bits of information into meaningful repositories and mirrored them on an IETF server. As a rule of thumb, if the list of meaningful git repositories does not exist, that's the first thing to put right.
--
Denis Ovsienko
