docs: Change pronouns from one to you (#355)

docs/src/tutorials/tutorial-0.md

@@ -65,7 +65,7 @@ accounts, we skip this (important) detail.
 
 ## Building and Emitting an IDL
 
-After creating a program, one can use the `anchor` CLI to build and emit an IDL, from which clients
+After creating a program, you can use the `anchor` CLI to build and emit an IDL, from which clients
 can be generated.
 
 ```bash

docs/src/tutorials/tutorial-1.md

@@ -38,19 +38,19 @@ pick it up.
 :::
 
 Additionally,
-notice how we take a mutable reference to `my_account` and assign the `data` to it. This leads us
+notice how we take a mutable reference to `my_account` and assign the `data` to it. This leads us to
 the `Initialize` struct, deriving `Accounts`. There are three things to notice about `Initialize`.
 
 1. The `my_account` field is of type `ProgramAccount<'info, MyAccount>`, telling the program it *must*
 be **owned** by the currently executing program, and the deserialized data structure is `MyAccount`.
 2. The `my_account` field is marked with the `#[account(init)]` attribute. This should be used
 in one situation: when a given `ProgramAccount` is newly created and is being used by the program
-for the first time (and thus it's data field is all zero). If `#[account(init)]` is not used
+for the first time (and thus its data field is all zero). If `#[account(init)]` is not used
 when account data is zero initialized, the transaction will be rejected.
 3. The `Rent` **sysvar** is required for the rent exemption check, which the framework enforces
 by default for any account marked with `#[account(init)]`. To be more explicit about the check,
 one can specify `#[account(init, rent_exempt)]`. To skip this check, (and thus
-allowing one to omit the `Rent` acccount) one can specify
+allowing you to omit the `Rent` acccount), you can specify
 `#[account(init, rent_exempt = skip)]` on the account being initialized (here, `my_account`).
 
 ::: details
@@ -75,7 +75,7 @@ Marking an account as `mut` persists any changes made upon exiting the program.
 
 Here we've covered the basics of how to interact with accounts. In a later tutorial,
 we'll delve more deeply into deriving `Accounts`, but for now, just know
-one must mark their accounts `init` when using an account for the first time and `mut`
+you must mark an account `init` when using it for the first time and `mut`
 for persisting changes.
 
 ## Creating and Initializing Accounts

docs/src/tutorials/tutorial-2.md

@@ -5,7 +5,7 @@ somewhat unique to the parallel nature of Solana.
 
 On Solana, a transaction must specify all accounts required for execution. And because an untrusted client specifies those accounts, a program must responsibly validate all such accounts are what the client claims they are--in addition to any instruction specific access control the program needs to do.
 
-For example, one could imagine easily writing a faulty token program that forgets to check if the **signer** of a transaction claiming to be the **owner** of a Token `Account` actually matches the **owner** on that account. Furthermore, imagine what might happen if the program expects a `Mint` account but a malicious user gives a token `Account`.
+For example, you could imagine easily writing a faulty token program that forgets to check if the **signer** of a transaction claiming to be the **owner** of a Token `Account` actually matches the **owner** on that account. Furthermore, imagine what might happen if the program expects a `Mint` account but a malicious user gives a token `Account`.
 
 To address these problems, Anchor provides several types, traits, and macros. It's easiest to understand by seeing how they're used in an example, but a couple include
 

docs/src/tutorials/tutorial-3.md

@@ -26,7 +26,7 @@ We start with the program that will be called by another program, the puppet.
 If you've followed along the other tutorials, this should be straight forward. We have
 a program with two instructions, `initialize`, which does nothing other than the
 initialization of the account (remember, the program *transparently* prepends a unique 8
-byte discriminator the first time an account is used). and `set_data`, which takes a previously
+byte discriminator the first time an account is used), and `set_data`, which takes a previously
 initialized account, and sets its data field.
 
 Now, suppose we wanted to call `set_data` from another program.
@@ -65,7 +65,7 @@ For more background on signing with program derived addresses, see the official
 
 ## Return values
 
-Solana currently has no way to return values from CPI, alas. However, one can approximate this
+Solana currently has no way to return values from CPI, alas. However, you can approximate this
 by having the callee write return values to an account and the caller read that account to
 retrieve the return value. In future work, Anchor should do this transparently.
 

docs/src/tutorials/tutorial-4.md

@@ -43,7 +43,7 @@ to the full power of the lower level Solana accounts API. Of course, Anchor will
 
 ### Invoke the constructor
 
-To access the `#[state]` account and associated instructions, one can use the
+To access the `#[state]` account and associated instructions, you can use the
 `anchor.state` namespace on the client. For example, to invoke the constructor,
 
 <<< @/../examples/tutorial/basic-4/tests/basic-4.js#ctor
@@ -69,7 +69,7 @@ To invoke an instruction,
 Performing CPI from one Anchor program to another's state methods is very similar to performing CPI to normal Anchor instructions, except for two differences:
 
 1. All the generated instructions are located under the `<my_program>::cpi::state` module.
-2. One must use a [CpiStateContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiStateContext.html), instead of a `[CpiContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiContext.html).
+2. You must use a [CpiStateContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiStateContext.html), instead of a `[CpiContext](https://docs.rs/anchor-lang/latest/anchor_lang/struct.CpiContext.html).
 
 For a full example, see the `test_state_cpi` instruction, [here](https://github.com/project-serum/anchor/blob/master/examples/misc/programs/misc/src/lib.rs#L39).
 

docs/src/tutorials/tutorial-5.md

@@ -32,7 +32,7 @@ pub enum ErrorCode {
 
 Observe the [#[error]](https://docs.rs/anchor-lang/latest/anchor_lang/attr.error.html) attribute on the `ErrorCode` enum. This macro generates two types: an `Error` and a `Result`, both of which can be used when returning from your program.
 
-To use the `Error`, one can simply use the user defined `ErrorCode` with Rust's [From](https://doc.rust-lang.org/std/convert/trait.From.html) trait. If you're unfamiliar with `From`, no worries. Just know that you need to either call
+To use the `Error`, you can simply use the user defined `ErrorCode` with Rust's [From](https://doc.rust-lang.org/std/convert/trait.From.html) trait. If you're unfamiliar with `From`, no worries. Just know that you need to either call
 `.into()` when using your `ErrorCode`. Or use Rust's `?` operator, when returning an error.
 Both of these will automatically convert *into* the correct `Error`.
 

docs/src/tutorials/tutorial-6.md

@@ -16,10 +16,10 @@ address for every SPL token? Now generalize this. For every program you use, do
 want a single account, i.e. your SOL wallet, to define your application state? Or do
 you want to keep track of all your account addresses, separately, for every program in existance?
 
-Associated accounts allow your users to reason about a single address, their main SOL wallet,
+Associated accounts allow your users to reason about a single address, their main SOL wallet.  This is
 a huge improvement on the account model introduced thus far.
 
-Luckily, Anchor provides the ability to easily created associated program accounts for your program.
+Luckily, Anchor provides the ability to easily create associated program accounts for your program.
 
 ::: details
 If you've explored Solana, you may have come across the [Associated Token Account Program](https://spl.solana.com/associated-token-account) which uniquely and deterministically defines
@@ -31,7 +31,7 @@ Unfortunately, the SPL token program doesn't do this, strictly. It was built *be
 of associated token accounts (associated token accounts were built as an add-on).
 So in reality, there are non associated token accounts floating around Solanaland.
 However, for new programs, this isn't necessary, and it's recommend to only use associated
-accounts, when creating accounts on behalf of users, for example, a token account.
+accounts when creating accounts on behalf of users, such as a token account.
 :::
 
 ## Clone the Repo
@@ -62,7 +62,7 @@ Two new keywords are introduced to the `CreateToken` account context:
 * `associated = <target>`
 * `with = <target>`
 
-Both of these allow one to define input "seeds" that
+Both of these allow you to define input "seeds" that
 uniquely define the associated account. By convention, `associated` is used to define
 the main address to associate, i.e., the wallet, while `with` is used to define an
 auxilliary piece of metadata which has the effect of namespacing the associated account.
@@ -86,7 +86,7 @@ For more details on how to use `#[account(associated)]`, see [docs.rs](https://d
 ### Defining an Associated Account
 
 The new `#[acount(associated)]` attribute will allow you to create a new associated account similar to `#[account(init)]`, but
-to actually define an account as associated, one must use the `#[associated]` attribute *instead* of the `#[account]` attribute.
+to actually define an account as associated, you must use the `#[associated]` attribute *instead* of the `#[account]` attribute.
 
 This new `#[associated]` attribute extends `#[account]` to include two things
 

examples/lockup/docs/lockups.md

@@ -84,7 +84,7 @@ a single admin, or the zero address--in which case the authority ceases to exist
 program will reject transactions signing from that address. Although the **authority** can never
 move a **Vesting** account's funds, whoever controls the **authority** key
 controls the whitelist. So when using the **Lockup** program, one should always be
-cognizant of it's whitelist governance, which ultimately anchors one's trust in the program,
+cognizant of its whitelist governance, which ultimately anchors one's trust in the program,
 if any at all.
 
 ## Creating a Whitelisted Program

examples/lockup/docs/staking.md

@@ -89,7 +89,7 @@ from the stake pool is complete, and the funds are ready to be used again.
 Feel free to skip this section and jump to the **Reward Vendors** section if you want to
 just see how rewards work.
 
-One could imagine several ways to drop rewards onto a staking pool, each with their own downsides.
+One could imagine several ways to drop rewards onto a staking pool, each with there own downsides.
 Of course what you want is, for a given reward amount, to atomically snapshot the state
 of the staking pool and to distribute it proportionally to all stake holders. Effectively,
 an on chain program such as