Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
misspellings.diff
Index: appe.xml
===================================================================
--- appe.xml (revision 2813)
+++ appe.xml (working copy)
@@ -8,7 +8,7 @@
bugs. They're still good instructions, and are referenced from <xref
linkend="users-to-volunteers"/><phrase output="printed"> in <xref
linkend="managing-volunteers"/></phrase>. But as they are a living
-document, I felt it didn't make sense to include a frozen snaphot of
+document, I felt it didn't make sense to include a frozen snapshot of
them here, and so no longer maintain a copy in this appendix. You can
view them at <ulink
url="http://subversion.apache.org/reporting-issues.html"
Index: ch01.xml
===================================================================
--- ch01.xml (revision 2813)
+++ ch01.xml (working copy)
@@ -140,7 +140,7 @@
individually. Thus the goal of management is mostly to ensure that
they continue to believe this, by setting standards for
communications, by making sure useful developers don't get
-marginalized due to personal idiosyncracies, and in general by making
+marginalized due to personal idiosyncrasies, and in general by making
the project a place developers want to keep coming back to. Specific
techniques for doing this are discussed throughout the rest of this
book.</para>
@@ -447,7 +447,7 @@
<title>Accidental resistance</title>
<para>There were many other things going on in the nascent free
-software scene, however, and not all were as explictly ideological as
+software scene, however, and not all were as explicitly ideological as
Stallman's GNU Project. One of the most important was
the <firstterm>Berkeley Software Distribution</firstterm>
(<firstterm>BSD</firstterm>), a gradual re-implementation of the Unix
@@ -785,7 +785,7 @@
to their technical contributions, has the potential to harm the
project. That's reasonable: their behavior is relevant because in the
long run it will have a negative effect on the project. The varieties
-of human culture being what they are, I can give no single, succint
+of human culture being what they are, I can give no single, succinct
rule to cover all such cases, except to say that you should try to be
welcoming to all potential contributors and, if you must discriminate,
do so only on the basis of actual behavior, not on the basis of a
Index: ch02.xml
===================================================================
--- ch02.xml (revision 2813)
+++ ch02.xml (working copy)
@@ -268,7 +268,7 @@
around the fact that English has become the default
language of the Internet: "easy to remember" usually means
"easy for someone who can read English to remember." Names that
- are puns dependent on native-speaker pronounciation, for
+ are puns dependent on native-speaker pronunciation, for
example, will be opaque to the many non-native English
readers out there. If the pun is particularly compelling
and memorable, it may still be worth it; just keep in mind
@@ -618,7 +618,7 @@
software is to either become the official release, assuming no bugs
are found, or provide detailed feedback to the developers so they
can reach the official release quickly. The difference between
- alpha and beta is very much a matter of judgement.</para>
+ alpha and beta is very much a matter of judgment.</para>
</sidebar>
</sect3>
@@ -630,13 +630,13 @@
<title>Downloads</title>
<!-- This section probably needs to be rewritten, because there's so
- much software, especially Javascript, that is distributed
+ much software, especially JavaScript, that is distributed
straight from GitHub. To a first approximation, source packaging
is important for something you expect an OS packager to
repackage; otherwise, it may be a luxury. Not sure whether this
footnote for JS can be used or not:
- <footnote><para>This is still true even for Javascript packages
+ <footnote><para>This is still true even for JavaScript packages
that are deployed as minified, continuously available downloads
from a canonical URL. Minified JS downloads are equivalent to an
executable form. They're not what a developer would hack on to
@@ -783,7 +783,7 @@
the other authors of the project are subscribed to these mailing
lists, so people see there's a way to give feedback that will reach
the developers. Your presence on the lists does not imply a
-committment to answer all questions or implement all feature requests.
+commitment to answer all questions or implement all feature requests.
In the long run, probably only a fraction users will use the forums
anyway, but the others will be comforted to know that they
<emphasis>could</emphasis> if they ever needed to.</para>
@@ -1952,7 +1952,7 @@
who knew the software more or less equally well, who all received the
same pressures from the same management, and who all know each others'
strengths and weaknesses. Now you're asking them to expose their code
-to the scrutiny of random strangers, who will form judgements based
+to the scrutiny of random strangers, who will form judgments based
only on the code, with no awareness of what business pressures may
have forced certain decisions. These strangers will ask lots of
questions, questions that jolt the existing developers into realizing
@@ -2039,7 +2039,7 @@
page. While it's good news for your project if you can get mentioned
in a place like that, I hesitate to contribute to the marketing arms
race by suggesting any concrete steps to accomplish this. Use your
-judgement and try not to spam.)</para>
+judgment and try not to spam.)</para>
<para>The topic-specific forums are probably where you'll get the most
interest. Think about mailing lists or web forums where an
Index: ch03.xml
===================================================================
--- ch03.xml (revision 2813)
+++ ch03.xml (working copy)
@@ -113,7 +113,7 @@
happening to projects whose workflows were developed before the rise
of GitHub PRs (see <xref linkend="pull-requests"/>) as the canonical
way to package proposed contributions. Many infrastructure questions
-are matters of judgement, involving tradeoffs between the convenience
+are matters of judgment, involving tradeoffs between the convenience
of those producing information and the convenience of those consuming
it, or between the time required to configure information management
software and the benefit it brings to the project.</para>
@@ -456,7 +456,7 @@
hosting site. Your project itself should never require participants
to run proprietary collaboration software on their own
machines.<footnote><para>The exception to this is proprietary
-Javascript code that is received from the hosting site and run
+JavaScript code that is received from the hosting site and run
confined or "sandboxed" in one tab in the user's browser. The
question of whether such code is conceptually an extension of the
server, or should be thought of as running on the client machine even
@@ -1060,7 +1060,7 @@
such a person posts to a mailing list that he's not subscribed to, his
setting of Reply-to becomes essential information. If the list
software overwrites it<footnote><para>In theory, the list software
-could <emphasis>add</emphasis> the lists's address to whatever
+could <emphasis>add</emphasis> the list's address to whatever
Reply-to destination were already present, if any, instead of
overwriting. In practice, for reasons I don't know, most list
software overwrites instead of appending.</para></footnote>, he may
@@ -2499,7 +2499,7 @@
<para>Most ticket databases eventually suffer from the same problem: a
crushing load of duplicate or invalid tickets filed by well-meaning but
-inexperienced or ill-informed users. The first step in combatting
+inexperienced or ill-informed users. The first step in combating
this trend is usually to put a prominent notice on the front page of
the bug tracker, explaining how to tell if a bug is really a bug, how
to search to see if it's already been reported, and finally, how to
@@ -2654,7 +2654,7 @@
obvious choice is the name of your project&mdash;if that's available
at Freenode, then use it. If not, try to choose something as close to
your project's name, and as easy to remember, as possible. Advertise
-the channel's availabity from your project's web site, so a visitor
+the channel's availability from your project's web site, so a visitor
with a quick question will see it right away.<footnote><para>In fact,
you can even offer an IRC chat portal right on your web site. See
<ulink url="https://webchat.freenode.net/"
@@ -2888,7 +2888,7 @@
<para>All edits in your project's wiki must come from registered
users; if your wiki software doesn't already enforce this by default,
then configure it to enforce that. Even then you may need to keep
-watch for spam edits from users who registered under false pretences
+watch for spam edits from users who registered under false pretenses
for the purpose of spamming.</para>
</sect2>
Index: ch04.xml
===================================================================
--- ch04.xml (revision 2813)
+++ ch04.xml (working copy)
@@ -775,7 +775,7 @@
tax benefits available to donors under 501(c)(3) won't apply to
non-U.S. donors anyway.</para>
-<para>If your project joins or creats a non-profit organization, make
+<para>If your project joins or creates a non-profit organization, make
clear the separation between the legal infrastructure and the
day-to-day running of the project. The organization is there to
handle things the developers don't want to handle, not to interfere
Index: ch05.xml
===================================================================
--- ch05.xml (revision 2813)
+++ ch05.xml (working copy)
@@ -35,7 +35,7 @@
been formed. The consortium's funding comes from the sysadmins'
salaries, and its office space and network bandwidth are donated,
albeit unknowingly, by the organizations they work for. Those
-organizations benefitted from the investment, of course, although they
+organizations benefited from the investment, of course, although they
may not be institutionally aware of it at first.</para>
<para>Today these efforts tend to be more formalized. Corporations
@@ -620,7 +620,7 @@
Fixes path inconsistencies on Windows. More generally, actually
makes use of the "style" parameter passed to the path library
- functions to choose the right path delimeter ('/' or '\' at this
+ functions to choose the right path delimiter ('/' or '\' at this
time).
* config.hw (SVN_PATH_LOCAL_SEPARATOR):
@@ -824,7 +824,7 @@
<para>The project's community will always be important to the
long-term success of contract work. Their involvement in the design
-and review process for sizeable changes cannot be an afterthought; It
+and review process for sizable changes cannot be an afterthought; It
must be considered part of the work, and fully embraced by the
contractor. Don't think of community scrutiny as an obstacle to be
overcome&mdash;think of it as a free design board and QA department.
@@ -1206,7 +1206,7 @@
number of developers checking in changes, and other factors, running a
responsive build farm can cost more money than any individual
developer has at their disposal. A good way to help, and gain some
-goodwill in the process, is to donate the server space and bandwith
+goodwill in the process, is to donate the server space and bandwidth
<emphasis>and</emphasis> the technical expertise to set up the
continuous integration and automated testing. If you don't have the
technical expertise available on staff, you could hire someone from
@@ -1411,7 +1411,7 @@
<sidebar id="commercial-vs-proprietary">
<title>"Commercial" vs "Proprietary"</title>
-<para><emphasis>possv2 todo: write a sidebar here pointing out ohw
+<para><emphasis>possv2 todo: write a sidebar here pointing out how
many companies publish a proprietary version that they misleadingly
call "commercial" or "enterprise", which they contrast with their
"community" (meaning open source) edition. Then link to this sidebar
Index: ch06.xml
===================================================================
--- ch06.xml (revision 2813)
+++ ch06.xml (working copy)
@@ -719,7 +719,7 @@
before now, because it reminds everyone that even those who have been
silent thus far still have a stake in the thread's outcome. It
describes why the thread is going nowhere, but does so without
-pejoratives or judgements&mdash;it just dispassionately states
+pejoratives or judgments&mdash;it just dispassionately states
some facts. Most importantly, it offers a positive course of action,
so that instead of people feeling like discussion is being closed off
(a restriction against which they can only be tempted to rebel), they
@@ -1177,9 +1177,9 @@
classic case of abusing project procedures. He wasn't doing something
obvious like trying to filibuster a vote, but he was taking advantage
of the mailing list's policy of relying on self-moderation by its
-members. We left it to each individual's judgement when to post and
+members. We left it to each individual's judgment when to post and
on what topics. Thus, we had no procedural recourse for dealing with
-someone who either did not have, or would not exercise, such judgement.
+someone who either did not have, or would not exercise, such judgment.
There was no rule one could point to and say the fellow was violating
it, yet everyone except him knew that his frequent posting was getting
to be a serious problem.</para>
@@ -1192,8 +1192,8 @@
to him directly, and asked him to simply stop posting. He never
really did understand the reasons why; if he had been capable
of understanding, he probably would have exercised appropriate
-judgement in the first place. But he agreed to stop posting, and the
-mailing lists became useable again. Part of the reason this strategy
+judgment in the first place. But he agreed to stop posting, and the
+mailing lists became usable again. Part of the reason this strategy
worked was, perhaps, the implicit threat that we could start
restricting his posts via the moderation software normally used for
preventing spam (see
@@ -1241,7 +1241,7 @@
ominous: the usual open source model of massively parallelized support
simply does not scale to the levels needed for world
domination.<footnote><para>An interesting experiment would be a
-probablistic mailing list, that sends each new thread-originating post
+probabilistic mailing list, that sends each new thread-originating post
to a random subset of subscribers, based on the approximate traffic
level they signed up for, and keeps just that subset subscribed to the
rest of the thread; such a forum could in theory scale without limit.
@@ -1447,7 +1447,7 @@
additionally indicating that the HTML should be designed for
readability (i.e., you'll want some control over its look and feel),
and should have a table of contents. Point 4 means that each
-individual entry in the FAQ should be directly addresseable via a
+individual entry in the FAQ should be directly addressable via a
direct URL (e.g., using HTML IDs and named anchors, tags that allow
people to reach a particular location on the page). Point 5 means the
source files for the FAQ should be available in a convenient way (see
@@ -1633,7 +1633,7 @@
canonical referral methods for common entities, and that these
referral methods should be used consistently everywhere, the project
in effect exports certain standards. Those standards enable people to
-write tools that present the project's communications in more useable
+write tools that present the project's communications in more usable
ways&mdash;for example, a revision formatted as "r12828" could be
transformed into a live link into the repository browsing system.
This would be harder to do if the revision were written as "revision
@@ -1870,7 +1870,7 @@
>news.ycombinator.com</ulink>, submit it there. Unlike
Slashdot, Hacker News is audience-curated, so if enough
readers agree with you, your announcement will end up on
- the front page. Please use some judgement: if your
+ the front page. Please use some judgment: if your
project is not in wide usage yet and there is not some
specific reason why this announcement would be interesting
to that audience, don't waste their time with it. There's
Index: ch07.xml
===================================================================
--- ch07.xml (revision 2813)
+++ ch07.xml (working copy)
@@ -29,7 +29,7 @@
much more time and trouble for the repair crew (now they have to work
with fewer people and less equipment, in cramped conditions, with
flaggers to slow and direct traffic, etc.), but at least the road
-remains useable, albeit not at full capacity.</para>
+remains usable, albeit not at full capacity.</para>
<para>Open source projects tend to work the second way. In fact, for
a mature piece of software with several different release lines being
@@ -101,7 +101,7 @@
<listitem><para>Incompatible changes may have been introduced, for
example such
that the data formats used by older versions of the
- software are no longer useable without undergoing some
+ software are no longer usable without undergoing some
sort of (possibly manual) one-way conversion step.</para>
</listitem>
@@ -512,7 +512,7 @@
release is covered in <xref linkend="stabilizing-a-release"/><phrase
output="printed"> later in this chapter</phrase>. Here we are
concerned just with the high-level version control actions that relate
-tothe release process. When the release branch is stabilized and
+to the release process. When the release branch is stabilized and
ready, it is time to tag a snapshot from the branch (see <xref
linkend="vc-vocabulary-tag"/><phrase output="printed">in <xref
linkend="technical-infrastructure"/></phrase>) with a name like, e.g.,
@@ -578,7 +578,7 @@
part of the interface and must remain stable). Many projects also
allow certain kinds of low-risk or non-core changes to go in during
stabilization, and may have formal guidelines for measuring risk. But
-no amount of formalization can obviate the need for human judgement.
+no amount of formalization can obviate the need for human judgment.
There will always be cases where the project simply has to make a
decision about whether a given change can go into a release. The
danger is that since each person wants to see their own favorite
@@ -634,7 +634,7 @@
The skills that make a good development leader are not necessarily the
same as those that make a good release owner. In something as
important as the release process, it may be wise to have someone
-provide a counterbalance to the project leader's judgement. In that
+provide a counterbalance to the project leader's judgment. In that
case, the project leader needs to remember that overriding a decision
by the release owner will undermine the release owner's authority;
that alone may be enough reason, in most situations, to let the
Index: ch08.xml
===================================================================
--- ch08.xml (revision 2813)
+++ ch08.xml (working copy)
@@ -51,7 +51,7 @@
<para>Thus it is quite reasonable that one of the considerations
going into each person's decision-making process is the question of
how a given action might affect his own future influence in the
-project. After all, if you trust your own judgement and skills, as
+project. After all, if you trust your own judgment and skills, as
most programmers do, then the potential loss of future influence has
to be considered a technical result, in a sense. Similar reasoning
applies to other behaviors that might seem, on their face, like "pure"
@@ -151,7 +151,7 @@
volunteer for work that someone else doesn't want or have time to do,
you will gain her good will and respect. Delegation and
substitution are not just about getting individual tasks done; they're
-also about drawing people into a closer committment to the
+also about drawing people into a closer commitment to the
project.</para>
<sect3 id="delegation-assignment">
@@ -376,7 +376,7 @@
areas where they are more and less influential, and non-experts
frequently defer to experts in certain domains of the project. But
the key is that this is all voluntary: informal authority is granted
-based on competence and proven judgement, but it should never be
+based on competence and proven judgment, but it should never be
actively
<emphasis>taken</emphasis>. Even if the person desiring the authority
really is competent, it is still crucial that she hold that authority
@@ -471,7 +471,7 @@
circumstances, it may be preferable to put author names into the
source files, along with precise descriptions of what each author did,
since the majority of potential contributors will expect that style of
-acknowledgement.</para></footnote></para>
+acknowledgment.</para></footnote></para>
<para>If your project decides to ban individual names from source
files, make sure not to go overboard. For instance, many
@@ -774,7 +774,7 @@
belittling him for not knowing how to report a bug, it tells him how,
and in enough detail to be actually useful&mdash;for example, many
users don't realize that "show us the error" means "show us the exact
-text of the error, with no omissions or abridgements." The first time
+text of the error, with no omissions or abridgments." The first time
you work with such a user, you need to be specific about that.
Finally, it offers a pointer to much more detailed and complete
instructions for reporting bugs. If you have successfully engaged
@@ -1310,7 +1310,7 @@
a while longer, and then there might or might not be another flurry.
But there's rarely an unsolicited formal resignation. To resign
would mean openly acknowledging to himself that his circumstances have
-changed and that his ability to fulfill a committment has been
+changed and that his ability to fulfill a commitment has been
permanently reduced. People are often reluctant to admit that.</para>
<para>Therefore, it's up to you and the others in the project to
@@ -1364,7 +1364,7 @@
<para>Or, he may agree that there have been problems, but ask for a
little more time (or for one more chance, in the case of discrete-task
-roles like release manager). How you react to that is a judgement
+roles like release manager). How you react to that is a judgment
call, but whatever you do, don't agree to it just because you feel
like you can't refuse such a reasonable request. That would prolong
the agony, not lessen it. There is often a very good reason to refuse
@@ -1507,7 +1507,7 @@
could succeed without it. Quality control requires, well, control.
There are always many people who feel competent to make changes to a
program, and some smaller number who actually are. The project cannot
-rely on people's own judgement; it must impose standards and grant
+rely on people's own judgment; it must impose standards and grant
commit access only to those who meet them. On the other
hand, having people who can commit changes directly working
side-by-side with people who cannot sets up an obvious power dynamic.
@@ -1528,7 +1528,7 @@
<para>In the Subversion project, we choose committers primarily on the
Hippocratic Principle: <emphasis>first, do no harm</emphasis>. Our
main criterion is not technical skill or even knowledge of the code,
-but merely that the person show good judgement. Judgement includes
+but merely that the person show good judgment. Judgment includes
knowing what not to take on. Someone might post only small patches,
fixing fairly simple problems in the code, but if her patches apply
cleanly, do not contain bugs, and are mostly in accord with the
@@ -1540,7 +1540,7 @@
areas of the code base, but that is irrelevant: the person has made it
clear that she is capable of judging her own abilities, and that is
the important thing. Technical skills can be learned (and taught),
-but judgement, for the most part, cannot. Therefore, it is the one
+but judgment, for the most part, cannot. Therefore, it is the one
thing you want to make sure a person has before you give her commit
access.</para>
@@ -1682,12 +1682,12 @@
<para>First, it may tempt some people into committing acceptable but
unnecessary changes, just to prevent their commit access from
expiring. Second, it doesn't really serve any purpose. If the
-main criterion for granting commit access is good judgement, then why
-assume someone's judgement would deteriorate just because she's been away
+main criterion for granting commit access is good judgment, then why
+assume someone's judgment would deteriorate just because she's been away
from the project for a while? Even if she completely vanishes for
years, not looking at the code or following development discussions,
when she reappears she'll <emphasis>know</emphasis> how out of touch
-she is, and act accordingly. You trusted her judgement before, so
+she is, and act accordingly. You trusted her judgment before, so
why not trust it always? If high school diplomas do not expire, then
commit access certainly shouldn't.</para>
@@ -1917,7 +1917,7 @@
developers, knowing how to constructively initiate or react to a
social fork of your project is useful&nbsp;&mdash;&nbsp;useful even if
a fork never happens, as understanding what leads to social forks, and
-signalling clearly how you will behave in such an event, can sometimes
+signaling clearly how you will behave in such an event, can sometimes
prevent the fork from happening in the first place.</para>
<para>The rest of this section is about social forks, not short forks.
@@ -1992,7 +1992,7 @@
non-copyable assets: not just trademarks, but perhaps money in the
bank, hardware, that full-color conference banner sitting in a storage
locker somewhere, etc. Sometimes, those questions are resolved
-independently of the project's decision-making procdures, because
+independently of the project's decision-making procedures, because
those assets already had formal owners, and in each case the owner
will decide what happens to the asset. But in cases where the actual
ownership is in dispute, or the asset belongs in some way to the
@@ -2116,7 +2116,7 @@
the project!"&mdash;because everyone is aware that a fork that fails
to attract developers away from the original project is unlikely to
survive long. All observers&mdash;not just developers, but users and
-operating system packagers too&mdash;will make their own judgement about
+operating system packagers too&mdash;will make their own judgment about
which side to choose. You should therefore appear extremely reluctant
to fork, so that if you finally do it, you can credibly claim it was
the only route left.</para>
Index: ch09.xml
===================================================================
--- ch09.xml (revision 2813)
+++ ch09.xml (working copy)
@@ -176,7 +176,7 @@
true for decades if not centuries, and they're not going to change.
So if you're a government agency and you want to start a successful
open source project, certain adjustments will be necessary to
-compensate for the structural idiosyncracies above. The advice that
+compensate for the structural idiosyncrasies above. The advice that
follows is most applicable to the U.S. and countries with similar
systems of government and civil service.</para>
Index: ch10.xml
===================================================================
--- ch10.xml (revision 2813)
+++ ch10.xml (working copy)
@@ -1033,7 +1033,7 @@
version of the code and the proprietary version. While the
contributor will be comfortable helping the free version, since that's
the norm in open source projects, she may feel less enthusiastic about
-her contributions being useable in a monopolized proprietary product.
+her contributions being usable in a monopolized proprietary product.
That is, unlike a straight non-copyleft license by which anyone has
the right to use the code as part of a proprietary work, here only
<emphasis>one</emphasis> party has that right, and other participants
@@ -1122,7 +1122,7 @@
truth in labeling and, to some degree, endorsement. A trademarked
name or symbol is a way for an entity&nbsp;&mdash;&nbsp;the entity who
owns or controls that trademark&nbsp;&mdash;&nbsp;to signal, in an
-easily recognizeable way, that they approve of a particular product.
+easily recognizable way, that they approve of a particular product.
Often they are signaling their approval because they are the source of
the product, and purchases of that product provide a revenue stream
for them. But that is not the only circumstance under which someone
@@ -1328,7 +1328,7 @@
specifications needed to produce high-performance open source drivers
for their cards, thus making it impossible for free operating systems
to support those cards to their full potential. Why would the
-manufacturers withold these specs? It doesn't make sense for them to
+manufacturers withhold these specs? It doesn't make sense for them to
work <emphasis>against</emphasis> software support; after all,
compatibility with more operating systems can only mean more card
sales. But it turns out that, behind the design room door, these
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment