It also automates the most burdensome step of incorporating new code, merging it in, which can in most cases be done from the GitHub site on a Pull Request page via a mere button click.
Managing Pull Requests
A successful project on GitHub has a queue of Pull Requests (Figure 21-15) to manage. Anyone that is a collaborator on this core instance of the project can manage and process pull requests. It is useful to note that pull requests do not necessarily have to come from forks. Disciplined contributors that have the collaborator privilege on the core project may still decide to use pull requests as a means of soliciting code feedback before merging it in.
Figure 21-15. Project pull request queue
Pull requests are such an important part of the GitHub ecosystem that each user has his own custom dashboard to display pull requests across all the projects he is associated with as a contributor (Figure 21-16).

Following this process to file a bug report is a learning experience in itself in how to find out what is wrong with the markup, style, or script that you wrote.
Pull requests
If you have ideas on how to improve HTML5 Boilerplate, patches to fix some existing issues, improvements or new features, you would submit what is known as a pull request. A pull request is a set of changes you can submit for review to the HTML5 Boilerplate GitHub repository, so it can be reviewed by the core contributors and merged into HTML5 Boilerplate if found to be useful.
A good way to start contributing would be to find a small issue that you think you can fix, fork the GitHub project (learn more on what this means at help.github.com/articles/fork-a-repo), work on your changes and submit a pull request.
If your contribution changes a lot of lines of code and alters the nature of the project drastically, consider opening an issue on the GitHub project first.

…

Commit your changes in logical chunks; use Git's interactive rebase feature (more about this feature at help.github.com/articles/interactive-rebase) to tidy up your commits before making them public. Please adhere to these Git commit message guidelines at tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html or your pull request is unlikely be merged into the main project.
Locally merge (or rebase) the upstream branch into your topic branch.
Push your topic branch up to your fork (git push origin <topic-branch-name>).
Open a pull request with a clear title and description. Please mention which browsers you tested in.
This may seem like a lot of work, but it makes your pull requests significantly easier to understand and faster to merge. Moreover, your code becomes the documentation of the work you have done and anyone who wants to know why that section looks the way it does can go back to your commits and understand exactly why it is the case.

Committing the code, I pushed the patch to my forked repository (the “origin”):
Git commit -a -m "Fixed issue #443" Git push origin master
Switching to the GitHub web interface, I went to my libzmq fork and pressed the big “Pull Request” button at the top. GitHub asked me for a title, so I entered “Added ZMQ_XPUB_VERBOSE option.” I’m not sure why it asks this as I made a neat commit message, but hey, let’s go with the flow here.
This made a nice little pull request with two commits: the one I’d made a month ago on the release notes, to prepare for the 3.2.1 release (a month passes so quickly when you spend most of it in airports), and my fix for issue #443 (37 new lines of code). GitHub lets you continue to make commits after you’ve kicked off a pull request. They get queued up and merged in one go. That simplifies things, but the maintainer may refuse the whole bundle based on one patch that doesn’t look valid.

…

If one puts the issue number in each commit, and if one uses the GitHub issue tracker—which we sadly don’t yet do for ØMQ—this release history is easier to produce mechanically.
To work on an issue, a Contributor SHALL fork the project repository and then work on their forked repository.
Here we explain the GitHub fork + pull request model so that newcomers only have to learn one process (C4) in order to contribute.
To submit a patch, a Contributor SHALL create a Platform pull request back to the project.
GitHub has made this so simple that we don’t need to learn Git commands to do it, for which I’m deeply grateful. Sometimes, I’ll tell people whom I don’t particularly like that command-line Git is awesome and all they need to do is learn Git’s internal model in detail before trying to use it on real work.

…

No special privileges to the original authors, because otherwise we’re not building a community, only boosting our egos.
To discuss a patch, people MAY comment on the Platform pull request, on the commit, or elsewhere.
Randomly distributed discussions may be confusing if you’re walking up for the first time, but GitHub solves this for all current participants by sending emails to those who need to follow what’s going on. We had the same experience and the same solution in Wikidot, and it works. There’s no evidence that discussing in different places has any negative effect.
To accept or reject a patch, a Maintainer SHALL use the Platform interface.
Working via the GitHub web user interface means pull requests are logged as issues, with workflow and discussion. I’m sure there are more complex ways to work. Complexity is easy; it’s simplicity that’s incredibly hard.

integration manager model
This is where each developer has a public repository, but one is
considered the ‘official’ repository – it is used to create the pack-
103
ages and binaries. A person or core team has commit rights to it, but
many other developers have public forks of that repository. When
they have changes, they issue a pull request to an integration manager, who adds them as a remote if they haven’t already – then
merges, tests, accepts and pushes.
blessed
repository
developer
public
developer
public
developer
public
integration
manager
developer
private
developer
private
developer
private
Fig. M Private and public repositories driven by read-only pull requests
This is largely how community-based git repositories like GitHub
were built to work and how many smaller open source projects operate.
In the end, there is really no single right way to do it – being a
decentralized system, you can have a model with all of these aspects
to it, or any combination you can think of.

…

You can then
delete your fork and revert to the original project head.
This will also really change patch submission for large projects.
Instead of emailing patches around, you can fork the project, add
your patch and submit a pull request for your branch with the fix to
one of the core members or through the ticketing system. A member of the core team can add you as a remote easily, create a new
testing branch, merge in or rebase your branch, test and accept or
reject. If your patch is ignored or the team doesn’t have time to deal
with it yet, it’s easy to keep up to date by continually rebasing and
re-sending the pull requests until it’s either rejected or accepted. It
doesn’t just go stale until it’s difficult to apply the patch anymore.
Services like GitHub and an increased adoption of distributed SCM
systems will dramatically change open source development workflows on teams of all sizes, in addition to changing the way individual
developers work.
110
Commands Overview
chapter 4
This section is meant to be a really quick reference to the commands
we have reviewed in Git and a quick description of what they do,
where we have talked about them and where to find out more information on them.

…

Searching is built in and we can edit the wiki offline.
The other cool feature we could use is the distributed nature of Git.
We could add other people on the project as remote repositories and
push to and fetch from them, merging changes to write a book or
documentation collaboratively. We could branch to try out a re-write
and then either merge it in or throw it away if we don’t like it. We
could send a pull request to our colleagues for them to try out the
branch to preview it before we decide whether to merge it in or not.
It’s possible the entire wiki project could even live in a bare branch
(that is, a branch with no common ancestors with any existing
branch) in the same repository as our project, so clones can get the
51
documentation as well, without it muddying up our code tree.
See the git-wiki (http://github.com/al3x/git-wiki/tree/master) project for an
example of this.

We’ve chosen to use Python for this book because it seems like a reasonable lingua franca for programmers. If Python isn’t your style, you should be able to translate our Python code into your favorite programming language fairly easily.
Assuming you are happy using Python or Julia, you can find the code for the book on GitHub at https://github.com/johnmyleswhite/BanditsBook. If you find mistakes or would like to submit an implementation in another language, please make a pull request.
Dealing with Jargon: A Glossary
While this book isn’t meant to introduce you to the theoretical study of the Multiarmed Bandit Problem or to prepare you to develop novel algorithms for solving the problem, we want you to leave this book with enough understanding of existing work to be able to follow the literature on the Multiarmed Bandit Problem. In order to do that, we have to introduce quite a large number of jargon words.

…

My thanks go to them, as well as to the three technical reviewers—Matt Gershoff at Conductrics, Roberto Medri at Esty, and Tim Hopper at RTI—all of whom read through this book and found countless ways to improve it. Their comments were invaluable and I’m deeply appreciative for all of the little errors that they kept from creeping into the final release of this book. Finally, I’d like to thank the various people who’ve contributed to the codebase on bandit algorithms that complements this book. Receiving pull requests contributing supplemental code for a book that wasn’t even released has been among my favorite experiences ever as an author.
Chapter 1. Two Characters: Exploration and Exploitation
To set the stage for this book, I’m going to tell you a short story about a web developer, Deborah Knull, who ran a small web business that provided most of her income. Deb Knull’s story will introduce the core concepts that come up when studying bandit algorithms, which are called exploration and exploitation.

If the maintainers merge, rebase, or cherry-pick your work, you’ll eventually get it back via pulling from their repository anyhow:
$ git push myfork featureA
When your work has been pushed up to your fork, you need to notify the maintainer. This is often called a pull request, and you can either generate it via the website — GitHub has a “pull request” button that automatically messages the maintainer — or run the git request-pull command and e-mail the output to the project maintainer manually.
The request-pull command takes the base branch into which you want your topic branch pulled and the Git repository URL you want them to pull from, and outputs a summary of all the changes you’re asking to be pulled in. For instance, if Jessica wants to send John a pull request, and she’s done two commits on the topic branch she just pushed up, she can run this:
$ git request-pull origin/master myfork The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40: John Smith (1): added a new function are available in the git repository at: git://githost/simplegit.git featureA Jessica Smith (2): add limit to log function change log output to 30 from 25 lib/simplegit.rb | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)
The output can be sent to the maintainer—it tells them where the work was branched from, summarizes the commits, and tells where to pull this work from.

…

You can tell gitolite:
repo foo RW = @junior_devs @senior_devs RW NAME/ = @senior_devs - NAME/Makefile = @junior_devs RW NAME/ = @junior_devs
This powerful feature is documented in conf/example.conf.
Personal Branches
Gitolite also has a feature called “personal branches” (or rather, “personal branch namespace”) that can be very useful in a corporate environment.
A lot of code exchange in the git world happens by “please pull” requests. In a corporate environment, however, unauthenticated access is a no-no, and a developer workstation cannot do authentication, so you have to push to the central server and ask someone to pull from there.
This would normally cause the same branch name clutter as in a centralised VCS, plus setting up permissions for this becomes a chore for the admin.
Gitolite lets you define a “personal” or “scratch” namespace prefix for each developer (for example, refs/personal/<devname>/*); see the “personal branches” section in doc/3-faq-tips-etc.mkd for details.

If you want a change to an open source project, you either ask one of the committers to make the change for you, or else you make the change yourself and send them a pull request. The core committers are still in charge of the codebase; they are the owners.
Inside the organization, this pattern can work well too. Perhaps the people who worked on the service originally are no longer on a team together; perhaps they are now scattered across the organization. Well, if they still have commit rights, you can find them and ask for their help, perhaps pairing up with them, or if you have the right tooling you can send them a pull request.
Role of the Custodians
We still want our services to be sensible. We want the code to be of decent quality, and the service itself to exhibit some sort of consistency in how it is put together.

…

Following a similar model for your own organizations makes sense. If a service is pretty mature, and is rarely changed — for example, our cart service — then perhaps that is the time to open it up for other contributions.
Tooling
To best support an internal open source model, you’ll need some tooling in place. The use of a distributed version control tool with the ability for people to submit pull requests (or something similar) is important. Depending on the size of the organization, you may also need tooling to allow for a discussion and evolution of patch requests; this may or may not mean a full-blown code review system, but the ability to comment inline on patches is very useful. Finally, you’ll need to make it very easy for a committer to build and deploy your software, and make it available for others.

If your primary interest is to get started building Bootstrap websites, the online documentation will likely suit you perfectly. The authors, Jacob Thornton and Mark Otto, have been meticulous in providing examples of the codebase, HTML code samples, and more to kickstart your project. It is top notch, and I’ve used it to gather the structure for this book.
If you want to contribute to the work of the open source project, you can submit pull requests or use the issue tracker on the GitHub project for updates, downloads, documentation, and more.
Are You Sure You Want Bootstrap?
If you are looking for JavaScript plugins, or a CSS reset, Bootstrap may be overkill. If you aren’t in love with some of the default interface elements, they can be overwritten easily or you can just strip out the associated tags. If you are looking for an easy way to build fast, responsive websites, Bootstrap is a great way to get going.

Prior to GitHub, developers who wanted to contribute code to an open source project were forced to download the source code, create their changes locally, and compile a list of those changes called a patch. This would then be emailed to the project’s maintainer for approval or rejection.
On GitHub, developers can “fork” or copy any code repository that has been made public and modify it within their own account. They then share the changes with the repository’s owner with a “pull request.” If the owner likes the changes, they’re merged into the original repository.
All of the friction that was once standard to software collaboration is removed with a solution that is manageable, seamless, and completely scalable.
GitHub customers can have free access, but if they subscribe to a private account, they have more freedom to leverage GitHub’s resources within their development teams.

Note
Do not remove any of the existing directories, as you will be removing plugins that provide core Ansible features such as the ones we have mentioned earlier in this book.
When writing plugins to Ansible, you should focus on making them flexible and reusable where possible. This way you end up removing some complexity from your playbooks and templates into a few complex Python files. Focusing on re-usability of your plugins also means it is possible to submit them back to the Ansible project using a GitHub pull request. If you submit your plugins back to Ansible, then everybody will be able to take advantage of your plugin, and you would have played a part in the development of Ansible itself. More information on contributing to Ansible can be found in the CONTRIBUTORS.md file in the Ansible source code.
Connection plugins
Connection plugins are responsible for relaying files to and from the remote machine, and executing modules.

This presents a challenge for administrators who should update job
descriptions to reflect the changes, develop work priorities, and contribute to staff
evaluations. This type of shared responsibility can also happen within the same
physical location, but with different departments participating in the process. In
some libraries, circulation desk workers may engage in scanning or searching for
management of interlibrary loan
interlibrary services, or shelving staff may be responsible for pulling requests for
interlibrary loan.
In some libraries, people who do interlibrary services may hold joint positions
in other units like circulation, reference, or cataloging. Because much of the interlibrary loan workflow is location-independent, it’s not surprising to see someone working on ILL requests at another service desk. Many reference desks have
slow times, so working on other projects is an efficient use of staff time.

If you are running a crowdfunding campaign (such as on Kickstarter), you are also required to link your bank account. At the completion of a successful campaign, your earnings are automatically deposited into that account.
When you link your ApplePay account to checkout and pay for items in seconds, the money is actually coming directly from one of your bank or credit card accounts.
When you take an Uber ride, Uber makes a pull request to charge your credit card, automatically.
A Venmo account that lets you receive money instantly from a friend, also lets you push that balance back to your bank account (or vice-versa).
These examples are few but significant. The point and reality of all these situations is that we, as consumers, are doing more interesting things with these new ancillary services than we can directly from our bank accounts.

The results of standard tests
and community feedback will be added to the page when they are available.
If this process has changed since this book was published, the revised process should
be documented at Publishing Modules on the Puppet Forge.
206
|
Chapter 16: Publishing Modules
www.it-ebooks.info
Publishing a Module on GitHub
It is common and expected for you to have a place to accept bug reports and pull
requests for your module. GitHub is by far the most common location to do this. The
following steps will create a GitHub repository for your module.
If you haven’t installed git already, you should do that now.
[vagrant@client ~]$ sudo yum install -y git
...snip...
Installed:
git.x86_64 0:1.8.3.1-4.el7
Dependency Installed:
libgnome-keyring.x86_64 0:3.8.0-3.el7
perl-Error.noarch 1:0.17020-2.el7
Complete!

I regularly use it and hope that you find it as useful an addition to your toolbelt as I have.
Setting Expectations
The goal of this book is to create an authoritative and centralized repository of information that can help those developing real-world apps with Backbone. If you come across a section or topic which you think could be improved or expanded on, please feel free to submit an issue (or better yet, a pull-request) on the book’s GitHub site. It won’t take long and you’ll be helping other developers avoid the problems you ran into.
Topics will include MVC theory and how to build applications using Backbone’s Models, Views, Collections, and Routers. I’ll also be taking you through advanced topics like modular development with Backbone.js and AMD (via RequireJS), solutions to common problems like nested views, how to solve routing problems with Backbone and jQuery Mobile, and much more.

This assumes that customers could tell us what products to build and that this would act as the pull signal to product development to make them.9
As was mentioned earlier, this is not the way the Lean Startup model works, because customers often don’t know what they want. Our goal in building products is to be able to run experiments that will help us learn how to build a sustainable business. Thus, the right way to think about the product development process in a Lean Startup is that it is responding to pull requests in the form of experiments that need to be run.
As soon as we formulate a hypothesis that we want to test, the product development team should be engineered to design and run this experiment as quickly as possible, using the smallest batch size that will get the job done. Remember that although we write the feedback loop as Build-Measure-Learn because the activities happen in that order, our planning really works in the reverse order: we figure out what we need to learn and then work backwards to see what product will work as an experiment to get that learning.

The volumes_from parameter does not work with recent versions of Docker.
It does not support Boot2Docker, a commonly used tool for running Docker on OS X.
It does not support the wait parameter that I use in some examples in this section.
There are proposed fixes for all of these issues awaiting review in the Ansible project. Hopefully by the time you read this, these issues all will have been fixed. There is also a pending pull request to support detach=no, which has the same behavior as wait=yes in the examples here. In the meantime, I have included a custom version of the docker module in the code sample repository that has fixes for these issues. The file is ch13/playbooks/library/docker.py.
Example 13-10 shows the entire playbook that orchestrates the Docker containers in our Mezzanine deployment. The sensitive data is in a separate file, shown in Example 13-11.

I would view that online and say: ‘Hey, I have few points I would like to add.’ In the old days, I would probably write up the changes I wanted to make and pitch them in the abstract to the community. Now I actually take your code into my sandbox. That is called a ‘fork.’ I work on it and now my changes are totally in the open—it’s my version. If I want to submit the changes back to you, the original author, I make a pull request. You look at the new way I have laid out ‘How to Write a Column’; you can see all the changes. And if you like it, you press the ‘merge’ button. And then the next viewer sees the aggregate version. If you don’t like all of it, we have a way to discuss, comment, and review each line of code. It is curated crowdsourcing. But ultimately you have an expert—the person who wrote the original program—‘How to Write a Column’—who gets to decide what to accept and what to reject.